I'm trying to figure out how to search for other devices logged into a wifi network that are hosting the application on a specific port.
How can I detect the presence of these other devices without knowing their address or even necessarily the port they are hosting on?
Once discovered, I should be able to contact the device and establish a client-server connection with it using SocketChannels.
Note: This application is meant to work with Android devices pre-ICS. So no Wifi-Direct.
You can definitely send a probe packet to broadcast (255.255.255.255) on a well-known port on which all peers listen. This is a good old technique for easy discovery. Others incluse SSDP or UPnP.
Be aware that 255.255.255.255 works only for UDP broadcasts
[Add]
I prefer expanding my answer rather than commenting.
1. Who should initiate a broadcast?
You can choose your favourite broadcast model. They are all interchangeable.
Model 1 is "job offering" and in my opinion is my favourite. You open a listening socket on your server application and then periodically send an advertising or better announcement broadcast message telling everyone that an open service is available at a certain IP/port (the port is not required to be static). Any peer interested in communication simply connects to the specified endpoint to use the service.
Model 2 is "job seeking", in which the server remains silent. When a client wants to connect, it broadcasts a generic seek message. Any server available receives the message and either replies (unicast) or else broadcasts the above mentioned announcement message.
Model 2a is "reverse job seeking" where a client broadcasts a request for service not as a generic message but including its endpoint. The server then connects to the client endpoint but the protocol continues as the client node is requesting a service from the server node. They act as reverse-roles TCP peers.
2. How often?
It depends on several factors. I'm not able to help you choose the final number of milliseconds, but I can show you all of the factors. First, how long should a client wait to tell the user that the scan for available services is "finished"? You may think "instantly", or "1 second", but bear in mind that broadcast packets tend to overload the network according to the number of servers available in a community.
If you choose model 1, start listening for available services ASAP (ie when application starts) and then periodically remove from the list those services whose heartbeat (another technical name for the broadcast packet) is not received within T*2 or T*3 timeframe where T is your timeout. A manual scan is generally supposed to be completed within T*1.5 or T*1.2 depeding on how large is T
Related
just want to know is there any methods to allow 2 different apps to communicate. Both of the apps are installed on different devices as well. I had gone throught quite a lot of research, but seem that INTENT, BROADCAST RECEIVER failed to meet my scenario. INTENT, BROADCAST RECEIVER can be work if both of the apps installed on the same device.
Here i can say you can use to make your things work :-
Sockets are typically used to accomplish this between Android devices (or between any peer devices).
When two devices desire to interact, you configure one or both of them to "listen" for connections on a socket and accept a connection from the other when that happens (or you can have a dedicated client and server and the client always initiates the connections).
You can exchange messages after the link has been made.
Android client server socket applications come in a variety of forms, but one that I found handy was:
Example of Android Server/Client using Socket on the client side (and its companion server side blog article - link included in the client blog)
It should be noted that you might need to add your own "protocol" on top of this. For instance, if you are sending a file that is unknown in length without a special "end" character, you might want to add a byte (or several bytes to represent an int, long, etc.) at the beginning to indicate the length of the transmission so the receiving side can tell when it has received everything (or that it has not received everything in case of an error).
connecting via networks (such as most 3G/4G) that forbid inbound connections
Even though there is nothing theoretically blocking sockets from functioning in these situations, many mobile operators will not permit inbound socket connections in practise. You would also need to determine the mobile's public IP address, which is doable but adds complexity. Whether your solution will only ever operate on a single operator's network, you can test it out to see if it works; but, if it doesn't, you could discover that using a server in the "middle" is preferable and easier: Devices A and B establish connections with servers Device A "discovers" device B after requesting the addresses of connected devices from the server. Device A sends device B a message.
Actually, it indicates that the messages should be forwarded to device B while sending them to the server. Device B is informed by the server that a message is available for it (using some sort of message notification like Google Cloud Messaging for example, or simply by the devices polling regularly to see if they have any messages). Device B accesses the server and downloads the messages. The aforementioned will function on pretty much any network that permits internet connectivity. It does have the drawback of having a server, but for the majority of mobile networks, it is probably a necessary approach.
You make one app a server using ServerSocket.
You make the other app a client using a Socket.
With both devices in the same network the client can connect to the server knowing its local ip.
After connection established they can communicate.
I decided to build an android app to implement a chatting mechanism. this mechanism is a bit different of the usual chat systems.
It is not peer to peer messaging system rather we have a message sender and multiple repetitions. every reception after getting the message from source, repeats and resend it to others. the below image shows our broadcasting system:
in this system every message has an unique id so very client broadcasts the message just once.
i know socket programming and also UDP based solutions but in implementation phase the networking foundation is challenge. we don't have any centralized server so every clients should do listen a particular port and resend the given message.
I guess the reception need UDP to announce its listening open. also sender lists the its neighbors receptions over UDP protocol. then connect with them and sends the message. BUT here we don't have any access point or connectivity among sender and receptions.
Should I use hot spot? I am completely confused.
Please give me help or suggestions to implementing the network.
Try this, it seems to fit your specification.
The Wi-Fi peer-to-peer (P2P) APIs allow applications to connect to nearby devices without needing to connect to a network or hotspot (Android's Wi-Fi P2P framework complies with the Wi-Fi Direct™ certification program). Wi-Fi P2P allows your application to quickly find and interact with nearby devices, at a range beyond the capabilities of Bluetooth.
I need to be able to discover the services on the local network (so say I am running a chat application and I want to discover other devices on local network running this chat), but sadly I need to be able to use it on devices with API < 16 (so I cannot use android.net.nsd) I am sure this can be done without using NSD API. Question is how. Any help?
There are at least three or four options.
You can use
TCP or UDP
Broadcast address
Multicast address
Iterate over all adresses in your network
HTTP
4 Make use of external server or something like GCM (Google Cloud Messaging)
ad.1 and 2
Pros:
+Easy to implement, server is sending predefined "hello" message on broadcast/multicast address of your subnet/network on specific port, client is listening on that port and when "hello" message arrives, he automatically knows server IP address (contained in packet)
+Connection to the Internet is not needed
Cons:
Some public networks blocks this addresses to avoid attacks (e.g flooding ).
ad 3.
Pros:
When Multicast and Broadcast is blocked what you can do is simply iterate over whole subnet. It is " brute force " method, but works, especially on typical home/small networks where mask is /24 - there are only 255 addresses to iterate through.
Connection to the Internet also is not needed
Cons
When mask is let say /16 it will take pretty much time to iterate all IPs
can cause battery drain
and will flood network.
ad. 4
Another approach is to make some external server that will be "orientation point" for devices. Each of them sends up its own Address, and looks if there are some entries from another devices from the same network.
Of course Internet connection is needed.
So, I think it is good idea to start with broadcast and multicast since it is very simply and will work in many places, but keep in mind that there are networks where it is not allowed to use.
Good reference can be found here http://docs.oracle.com/javase/tutorial/networking/datagrams/broadcasting.html
You should also check this one http://home.heeere.com/tech-androidjmdns.html
I'm in the early stages of writing an app that will need to broadcast data to several other devices.
My first thought was using an UDP broadcast, however according to both
http://code.google.com/p/boxeeremote/wiki/AndroidUDP and
Android 3G UDP Broadcast
he UDP will not be able to push through the NAT when on the mobile network
(which is essential for my app).
I know that i could either use a server to broadcast however i'd rather avoid generating to much traffic on my home server.
The last alternative that i can think of is having several tcp/ip connections and looping through all connected clients and sending the broadcast. But since I'm counting on having at least 30 listeners I believe this will be to expensive.
I do not have any broadcast associated code yet, that's why I haven't posted any;)
Is there a way to break through the NAT? Will the phone be able to handle 30 simultaneous tcp/ip connections? Or should i look into some other method of broadcasting?
Any hint would be greatly appreciated!
Kind regards
Johan Risch
:::::::::::::::::::::::::ADDED::::::::::::::::::::::::::::::::
I will be sending strings of length 10-20 characters once every 30-360 seconds
(will be controllable by the user) containing geo points in string format. The order in which the data will be sent is not important, that's why I thought of udp first.
I've set up my server so that when a user logs in he/she updates my database with his/her current ip.
Preferably i'd like it to work globally, but as long as it would work within the mobile networks in the same country.
That's about all the relevant information i can think of, hope this clears some things up!
:::::::::::::::::::::::::/ADDED:::::::::::::::::::::::::::::::::
The NAT doesn't pass UDP through because UDP has no destination address, so technically UDP has to be sent to all subnetworks of the network. When the network is your home LAN, it's no big deal, but when the network is your ISP or university backbone or cellular provider, the UDP could be replicated to hundreds of thousands of subnets. That's a packet storm that will degrade network performance for everyone, and it's massive overkill for your particular app since you really only want to talk to a small number of clients.
This problem has been solved many times already. Instant Messaging clients have a similar situation as yours: want to do direct P2P messaging when possible, through firewalls. How do they do it? The original NAT traversal / firewall traversal solution was to set up a message relay server. All clients talk to the server, and the server echos messages from one client to the others as appropriate. It works with NATs and firewalls because the client initiates the outgoing connection to the server.
If the clients are able to establish a peer to peer connection, then the relay server can just give the clients each other's IP addresses and stop relaying messages.
UPNP is a protocol that enables clients to request a firewall to open a port for incoming traffic. BitTorrent clients use UPNP to enable clients to connect P2P for file sharing. Clients find each other via the torrent server. Most home LAN firewall routers support UPNP now, but it seems doubtful to me that a cellular network provider would provide UPNP support for over the air connections.
Another (remote) possibility is multicast TCP/IP, but as I recall this is really optimized for "push" content flowing from the server to clients rather than client-originated peer to peer.
Your best bet is to take a look at the open source IM clients out there, particularly ones with Android implementations, and see how they're doing IM. Jabber is one that comes to mind, I'm sure there are others. You could even use an IM system's messaging API as your data transport layer and more or less stay out of the wire level details completely.
I'm currently in the process of developing an app which has some very demanding needs.
The Project
An application which can communicate with a server is needed.
Small messages has to be send to the app which could display a notification or start an activity.
The Demands
Client needs to be sure that the phone is 'connected' at all times.
The client expects that the app can tell when it's no longer connected (or able to connect) to the server it tells the user.
Client needs to be able to send a message to individual devices
If the client needs to broadcast a message to the connected devices and to the individual devices.
My thougts (or problems)
Currently, the app is polling the server with a http request once a minute - if the app isn't able to connect to the server the user gets notified. The polling is able to tell which device is calling and telling it if it has a message for it.
But...
IMO this is a terrible design - it generates a lot of excess traffic, uses resources which probably wasn't necessary and it offers a lot of issues with connectivity (which I'm not sure I'll ever get past no matter which method is used).
I need your experience to select the right solution for my project.
I've been thinking of C2DM, but I'm not sure this could cover my needs?
Is polling for my only real solution?
Is there a third option I haven't thought about?
I stumbled upon a new service called Parse.com they seem to offer functionality for easy push-implementation for Android using their backend. It's commercial but they have a free plan too.
If you want to do your own implementation there seems to be a lot of articles about using MQTT which is designed for low-power devices. But I haven't seen any ready-to-use implementations of this yet.
I'd consider MQTT as a good solution, although it is what I'm most familiar with. Disclaimer - I write an Open Source MQTT broker. You could achieve what I think you want like this:
Have an MQTT broker running somewhere. The service on the phone connects to the broker and subscribe to a unique topic, e.g. device/23412364, where 23412364 is the per device unique id and referred to as <phone id> below. When your client wants to send a message to a specific phone, the message goes to device/<phone id>. If you want messages to go to all phones, then the phones could also subscribe to device/all for example.
If you make your subscriptions and messages have Quality of Service of 1 or 2 and set the "clean session" option for the clients to false, then messages will be queued up on the broker if the phone disconnects for whatever reason. QoS=1 means "at least once" and QoS=2 means "exactly once". When the phone reconnects, those messages will be delivered.
You could also have the phone send a message like "register <phone id>" to a fixed topic just after it connected (topic of "register" for example). A feature of MQTT that is very useful is the "Last Will and Testament". When you connect a client, you have the option of specifying a Will message and the topic that it should be delivered on, in the case that the client disconnects unexpectedly (ie. without telling the broker that it is going to disconnect). So you could set the will message to be "unregister <phone id>" and to be delivered to the same fixed topic as above ("register" in this example). You could then have another MQTT client at the server end sitting subscribed to "register". When a phone connects, it sends a "register <phone id>" message, when it gets disconnected the broker sends "unregister <phone id>". The MQTT client can therefore keep track of the connected clients at the server side.
At the phone end of things, you can get notified if the TCP connection goes down through normal network code.
Some relevant links:
Using MQTT in Android mobile applications: http://dalelane.co.uk/blog/?p=1599
Trivial MQTT Android project based on above: http://mosquitto.org/2011/11/android-mqtt-example-project/
MQTT Power Profiling: http://stephendnicholas.com/archives/219
MQTT features: http://mosquitto.org/man/mqtt-7.html
Facebook using MQTT: http://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920