I'd like to know how a central server works in connecting two devices. I'm assuming that when the device application starts up, it should register its IP address and other pertinent information (username) with the server. When it wants to connect to another device, it should look to find the address of another device on the server, maybe with a get request. Then set up a to connect to a socket. If the device application closes, it should unregister from the server. Is this correct?
That's pretty much correct.
Because one or both devices are probably behind firewalls (including NAT), you have to assume they won't actually be able to connect directly to each other, so it won't be as simple as opening a socket to the other device once you find out its registered address. You will either have to try firewall-traversal techniques (which will usually be successful with UDP but not with TCP) or have a helper that isn't behind a firewall (which could be the same as the registration server or something else) carry all the data between the devices that wish to communicate.
Also, you will want to have the registration server time out registrations and the clients periodically refresh them, because clients won't always have a chance to deregister themselves on the server when they terminate or lose access to the network.
Related
We are working on a Android project with the below requirements.
The application should be able to send data to all the devices which are running our application which exists in the WiFi LAN.
Some payloads are expected to be of size >= 5MB.
The data shouldn't be lost and if lost the client should know the failure.
All the devices should be able to communicate with all other. There will be no message targeted to a specific device instead all the messages should be reached all the devices in the N/W.
No internet hence no remote server.
Study we have done:-
UDP Broadcasting - UDP doesn't guarantee the message delivery but this is a prime requirement in our case. Hence not an option.
TCP - TCP guarantees the message delivery but requires the receiver IP address to be known before hand and in our case we need to send the message to all the devices inside the LAN. Hence not a straight option.
Solutions we are looking into:-
A Hybrid approach - Name one of the devices in the N/W as Server. Post all the messages to a local Server. The Server keeps a open socket to all the devices(which have our application) & when there is a message from a device then it routes the message to all the devices. The disadvantages of this approach are,
Server having multiple sockets open each per device. But in our case we are expecting devices <=5 in LAN.
Server discovery using continuous UDP broadcast.
We want to have all the data in all the devices. So if we newly introduce any device into the LAN then that device needs to get all the data from the server.
So my question, have you any time worked on these kind of hybrid approaches? Or can you suggest any other approaches?
Your hybrid approach is the way to go.
Cleanly split your problem into parts and solve them independently:
Discovery: Devices need to be able to discover the server, if there is any.
Select server: Decide which of your devices assumes the server role.
Server implementation: The server distributes all data to all devices and sends notifications as necessary. Push or pull with notifications does not matter.
Client implementation: Clients only talk to the server. The device which contains the server should also contain a normal client, potentially passing data to the server directly, but using the same abstract protocol.
You could use mDNS (aka Bonjour or zeroconf) for the discovery, but I would not even recommend that. It often createsmore problems than it solves, and it does not solve your 'I need one server' problem. I would suggest you handcraft a simple UDP broadcast protocol for the discovery, which already tells you who the server is, if there is any.
Select server: One approach is to use network meta data which you have anyway, for example 'use the device with the highest IP address'. This often works better than fancy arbitration algorithms. Once you established a server new devices would use this, rather than switching the server role.
Use UDP broadcast for the discovery, with manual heuristic repeats. No fancy logic, just make your protocol resilient against repeated packets and repeat your packets. (Your WLAN router may repeat your packets without your knowledge anyway.)
You may want to use two TCP connections per client, potentially to two different server ports, but that does not matter much: One control connection (always very responsive, no big amounts of data, just a few hundred bytes per message) and one data connection (for the bulk of the data, your > 5 MB chunks). This is so that everything stays responsive.
I am doing an android app allowing users to play online.
Currently, I use a TCP server: when two persons are connected, the server takes care of forwarding the packets between the two clients.
I would like to replace my server by a java servlet with google app engine. This new server will just be used to connect the two players.
It would work in that way:
Player A opens a server socket and then post to the server the connection details.
When a player B wants to play against A, he asks to the server the port number of A and he connects directly to A.
The problem is that I am not sure that it will work if player A is behind a NAT. When player A opens a server socket, that opens one port of its 192.168.x.y address, but does it ask to the box a port forwarding? I assume it doesn't...
So two questions:
Is it possible to make a direct connection TCP between two devices even when there is a NAT or a firewall (I don't know how firewalls work on Android...)
If it isn't possible, what is the best solution: Is it possible to make a TCP server to ensure the exchange of the messages with app engine?
Thank you by advance.
game
Creating direct TCP connection between users under different NAT is mostly possible. There are 4 types of NAT. FC, ARC, PRC, Symmetric. If one of player A or B has symmetric NAT then it is impossible to create TCP P2P connection. In this case you will have to use a server in the middle for exchanging data between two players.
For other types of NAT combinations it is very much possible but not guaranteed. The technique that is used to create TCP P2P connection is called TCP hole punching. Read this answer to know in details about this technique.
Also creating TCP P2P connection is not related to any platform.
First, the device itself is probably not going to be the main problem. If they are at home and using WiFi, you will probably have to deal with a cable modem/DSL modem, which typically includes a firewall. Also if they are at work (or a hotel, conference center, etc.), there may be a corporate firewall to deal with.
I believe most home cable/DSL modems support uPnP (Universal Plug and Play), which includes the Internet Gateway Device Protocol (IGD) designed to let devices determine the external IP address and set up port mappings. In general you can look up NAT traversal for ways to handle connections through a home modem/firewall. I will note that corporate firewalls are a different matter and many of these techniques won't work.
So probably I would recommend you be ready for at least the following four scenarios
Direct connection with nothing creating problems. You can test this by having the server do a test connection when the player first contacts the server. If this works, things are simple.
Home NAT device that understands uPnP. If you have a 10.x.x.x, 172.16.x.x-172.31.x.x, or 192.168.x.x number (typical home WiFi), then you can try to set up the NAT traversal and if that works you can send the appropriate information to your server. It probably would be worthwhile for the server to do a test connection just to be sure that things work.
If you have a firewall that you can't get around, then make a note on the server regarding player A, and when B tries to join A's game, look and see if B will accept connections, and if so then arrange for A to connect to B instead.
If none of the above work, then have A and B both connect to the server and have the server relay messages between A and B.
If you don't want to program all those possibilities, then option 4 is the one that is most likely to work, even if it does mean extra traffic going to/from your server. But note that for corporate networks, they may simply have a rule blocking unknown connections, and there may not be much you can do.
Edit: I was able to get a simple TCP server working on Android without anything special regarding Android itself, so removed a comment saying I didn't know about that.
I would like to know if it is possible to make a TCP connection between my mobile app and a site on a shared hosting server. Instead of checking the server every interval of time (30 seconds), I would like to make it more professional, getting the message to my mobile without refreshing. Is it possible on a shared hosting or should I have a dedicated server?
I cannot provide codes. I just need an idea on how to start, I'm searching for the first key.
As long as you can get a dedicated IP address in the shared hosting, you should be able to float a TCP server there. Please note that, you can float a TCP server even when you IP is shared, but then there is no guarantee on the port number -- some other tenant on that shared IP can also end up using the same port number and that might be an issue. Can your provider allocate you a specific port (or ports) -- if so, then you can do without having a dedicated IP address. Here is a good read: https://my.bluehost.com/cgi/help/426
Once you have a connection, it is a matter of sending updates periodically via the socket to refresh it instead of a manual refresh.
Using sockets in java, is it possible to send information at the same time as connecting?
For example I want a remote device to control another device (such as a virtual appliance) using 'Client Server'. So the remote will switch the appliance on. When I connect to the Server I would like to allow the server to be able to determine what type of device it is, either a remote or appliance without sending a messages after connecting.
Is this possible? Or would there be a better way to implement this?
Thanks
You could set up different ports on the server, and have different kinds of devices connect to different ports. That way, the port number of the incoming connection would identify the device before the first byte of payload data has been transferred.
I working on one project which Android device is act like a Server. I mean, when I send any requests to my device, then I will get a response.
If any one have any idea so please tell me. I am waiting for the reply.
A server usually accepts request on a certain IP and Port. This is a problem for mobile devices, because usually they're on a private network (behind a router) and one can not address IP and port of a special device.
So, practically spoken, I really doubt that a mobile device can act as a server.
A reliable solution would require some sort of extra proxy server. Basically your mobile will connect with this "ground-based" server and the system of proxy and handheld is the server you're looking for. It is operational once the handheld is connected. Client establish connection with the proxy and send their requests, the proxy forwards the request to the mobile device to get a service response for the client.
A nice architecture for this approach is XMPP, the implementation of the proxy server would be a standard xmpp server (like openfire).