I am working on an app that uses peer-to-peer communication between Android devices. It receives and delivers JSON data and the data never goes through the server ever. The server is only used to keep track of user IDs, login times, IP changes, and other stuff. This app will use sockets for communication.
Requirements
JSON data goes directly to an Android device from another Android device without going through server.
The android devices can be connected to any kind network like 3G or Wi-Fi (here I assume I have to use NAT).
Server is used to keep track of IP changes of the Android devices as they may be connected to any kind of network.
Challenges
The main problems I am facing are:
I don't know how to connect two devices if they are behind a Wi-Fi network.
What approach I can use if I am going to use P2P for delivering JSON data.
Update
For this I have to use hole punching. The idea I got is that no one can connect to a device from the outside. It must start communication from inside the device. So if A request server S for address of B, then server gives the address of B to A and vice versa. Now what? What occurs next?
Any suggestion would be greatly appreciated.
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 am trying to obtain information with the usage of UDP protocol on my Android device. I have to consider two cases - connection via access point, and router.
Sadly, in case of access point, I am loosing 95% of data - even though the sending process works properly (I can easily receive that information on my laptop). Somehow Android just can not cope with high traffic sent from one source.
Such problem does not exist when the connection works via router, because then the data is broadcasted from multiple sources, and it works reliably.
I would really appreciate any information about the cause of such behavior.
I have solved this issue - the access point did not detect any device in his network, even though there were few android devices connected. I had to write a pinging service, that keeps the constant outbound traffic.
I want to connect multiple devices to a single bluetooth server. My application currently makes the server discoverable, and then, the client application lists the discovered devices and tries to connect to one of them. The problem is, I don't know which of the discovered devices is the server.
The way I am dealing with the problem envolves a try-catch mechanism, where I try to connect to each device and, upon connection, there is a brief message swapping between client and server, where the client asks if the connected device is a server for my application.
The main problem here is that the socket connection and message swapping takes too long, if there are multiple discoverable devices nearby I am forced to probe each one of them asking "are you a server for this app?". Is there any alternative to this system?
Note: There is a little "catch" in this application, there may be multiple servers, so I really need a fast way to go around my device list checking which ones I can connect to.
I'm trying to figure out what the solution is to having multiple android devices on one network share data.
Assuming all of them are running the same app, and a user "registers", I'd like to figure out (without any user input) what other devices on the network are available to be talked to and then to send them this registration data, so that when the user goes to the next device, their info is already there.
I'm able to ping the 255 connected devices in the x.x.x.0-255 range to see which respond, but am not clear on how I can write an app resident server (using the term loosely) that I could then send the data to.
I can't be the first person to need to solve this problem, but am unable to find anything useful on this front.
One caveat is that this is for devices that have no 3G (or other means) of getting to the internet, and the wifi network they're on won't have access to the internet either, so the solution has to be 100% internal network and can't include any additional devices (like a box running apache that all the device can use as a server).
TIA
but am not clear on how I can write an app resident server (using the term loosely) that I could then send the data to.
Create a Service that has code that opens a ServerSocket and listens on incoming requests, such as an HTTP server.
On the whole, this is dangerous, but for constrained circumstances -- such as your "100% internal network" -- it should be safe.
Actually i am developing tracking app and want to send Location updates between two Android phones so that both can track one another over the Map. My application must get real time updates from other android device for better tracking.
I Have searched couple of techniques but don't know which one is best
Using Sockets: making one device as Server while other as Client
Possible Limitation:
What if IP address of Server is changed (because WIFI don't have a
static IP)
Cannot access if the IP address of server is private
Only client can connect to Server and Server cannot connect to Client
Using Intermediate Server: create an intermediate server and make a communication via that server.
Possible Limitation:
Slow because each Android device first send these updates to server
and then server push these updates to other android device
Please provide me your suggestion about which one is the best way to do this.
Since you didn't state the Device API level you want to support I'll provide you with an option for Android v4 (API level 14) devices. It's called Wi-Fi Direct and allows p2p connections between phones. It's essentially your socket approach, but allows easy neighbour discovery and allows transfers in both directions.
Well wifi is out.. Not for your stated purpose at least. Unless your map is quite small. Wifi is for say 100 meters (on a really good day)
Not knowing as much about android as I do of other mobiles, I'd say you're in for some pain.
I'd suspect connecting to your phone with a peer to peer might be a real slog.. some providers won't let it happen.
I have an approach more than an answer..
From an android phone, see if you can get your ip address.
From a desk, ping that ip address.
If it works, you're well on your way..
Id even say given the size of your info, you could use pinging as your main data carrier.
Pings can contain more than just random bytes. You could include an ID, and GPS in the contents you send in your ping. --- perhaps include a check sum ---
Do most of the work desk to phone, because development would be faster.. Then when your phone is capable of catching the pings.. Well then sending the ping should be easy as.