I'm essentially trying to take a stream of UDP packets created on my local network, and get an android phone to receive them whether on that network, or cellular data as if it was on the source's local network.
I don't have tons of network experience so bear with me.. I have spent the last week researching this problem and found bits and pieces of ideas to make it happen, but I have no idea how to implement any of it.
It seems a sort of multicast with PIM sparse mode seems to be the best option. If I can have the packets routed to the rendezvous point and the phones subscribe I should be set. Looked at VPN a bit too, however Android apis would make it an annoyance to the user.
So I guess my questions in a nutshell for anyone will to put me on the right path would be:
1:How do I route local UDP packets to a rendezvous point? A special router and a port forward?
2:How can I make Android subscribe to a rendezvous point
3:Lastly, when the phone is subscribed does it act as if those packets are from its local network? Or is there more required?
Multicast is not a good solution for your problem. Multicast packets do not usually get past routers. This post's answer explains why multicasting is not a good choice.
Instead write your own client/server application using standard sockets (not multicast) where the server streams the data to each client individually.
Related
I have to exchange data between two bluetooth devices, one of them will be an Android device. For simplicity's sake you can assume the other device will be a generic linux device running bluez producing data similar to the data a fitness tracker would produce.
The scenario seems a straightforward use case for Bluetooth Low Energy. The problem i am currently running into comes from the fact that communication has to be reliable (reliable in the way TCP is reliable). This means:
no losses
no corruption of data
order needs to be preserved
no duplicates
no phantom packets
While losses are prevented at link layer level, the order for instance seems not to be explicitly preserved when working with Low Energy (using indications would probably achieve this).
Not having done a lot of work with Bluetooth I am currently overwhelmed quite a bit with the amount of options while at the same time no option seems to fit the bill nicely.
Is there a "best-practice" for setting up reliable communication between two bluetooth devices? A Bluetooth Low Energy solution would be preferable, but is not mandatory.
Once your Bluetooth connection is setup its reliable. So you don't have to be worried about data loss or corruption.
So the things you're worried about can be easily handled in your side. You'll get proper connection and disconnection callback while setting up a BroadcastReceiver for your BluetoothAdapter.
In case of any disconnection you may have to restart the procedure for connection again and once its established properly you may resend the data.
I don't know about your purpose yet, but one thing I need to mention here is, I would not recommend Bluetooth communication if you're holding the connection for long time. Some devices disconnects the connection automatically after some time if there's no continuos transmission.
Android has Bluetooth support, but it only allow to send ot receive data from stream. There is a very good sample project from Google: https://github.com/googlesamples/android-BluetoothChat . The only drawback of this sample is that it use Handler to nitify about Bluetooth events. I changed it a bit so it use another Thread and from it calls methods of interface you set, take a look at project: https://github.com/AlexShutov/LEDLights . This is ordinary Bluetooth, not BLE, hope it will help
Android's BLE stack is as good as the link layer specification. So you can use "write without response" in one direction and notifications for the other direction. Just make sure your peripheral side does not drop incoming writes.
BLE uses 24-bit CRC. for the amount of data transmitted using BLE the CRC is quite robust and the possibility of corruption is very low ( note that TCP CRC is 16bit and the Ethernet CRC is 32bit, please see http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html).
The ordering issues in wired network is a result of routing packets through different routes to the same destination ( plese see If TCP is connection oriented why do packets follow different paths?) . This is partially due to the use of sliding window acknowledgement protocol, which allows a number of packets to be transmitted before being acknowledged.In BLE there is no routing and the acknowledgement scheme is a variation of stop and wait ARQ scheme(2-bit lazy acknowledgement), this means that it is not possible to send a new packet without being acknowledged. These two factors makes the possibility of having an out of order transmission highly unlikely.
first of all thanks alot for the big help you have been in my past. I looked for alot of problems since i began android programming, but now I have a problem, i cannot find an answer.
I wrote a little program where are a number of CountDownTimers, which are correctable(adding or subtracting seconds and minutes), they can be paused and resetted to a time i setted in SharedPreferences.
Now my boss want to expand this.
he wants this app to connect via W-Lan (intranet, not internet), to a wlan-to-rs232 converter, to set states like "pause" and "end" to a machine, which displays the time.
Now my Problem:
I do not even know how to begin with that ^_^
I dont know, how to connect to the converter,
I dont know, how to send the needed bits/datas/whatevers to the converter,
I, if i can manage it to connect to the converter anytime, dont know how to tell the converter which commands/bits/whatevers he has to send to the machine.
Second:
the machine also send bits to the converter, which has to be received by my app, same thing as above, but inverted.
Maybe someone is here who can help me?
Just a little introduction to this will be helpful, i got the beginnings of programming by "Try-and-Error", but to do that, i need a point where i can begin.
Thanks alot
Mina
Nobody can really help you with this, as you didn't mention which RS-232 host you have. There is no standard... they all work a bit differently.
That being said, most of them will send/receive data over a regular TCP connection.
Configure your converter with an IP address.
Connect it to whatever RS-232 device you are using.
Make a TCP connection to your converter via its configured IP address and port.
Send/receive data over this TCP connection as if you were sending/receiving over RS-232.
Other converters implement their own protocol to facilitate emulating the port status lines, such as carrier detect and clear-to-send. For those, you will have to read the protocol documentation provided by the manufacturer.
I need to make a peer-to-peer connection between two android phones running i-jetty web server through gprs channel.But many mobile operators block the inbound connections to the phones.Is there any way around it?
NAT penetration is complex enough that you really shouldn't mess with it until you're quite familiar with the internals of networking. The autonomous NAT traversal used by pwnat is pretty much the state of the art these days.
The basic idea is to use the fact that a router might have any IP address and as far as a NAT knows, any source IP address is valid for an ICMP error message, which the NAT will forward to its client.
Note that you can usually only get UDP through. So you'll have to implement your own byte-stream protocol.
In general, the most reliable way of getting two phones talking to each other is using C2DM (or GCM, now). Perhaps you can have the devices exchange their IP addresses using C2DM (which may get you nothing at all, btw, if its an address behind a router or firewall with blocked ports). You could also use SMS depending on the needs of your apps.
Usually there'd be a server of yours involved--additional development--but for short messages, I don't see why one device cannot directly post via C2DM to another device. (This is an untested statement, beware.)
This is sort of an odd question, but I know it is possible.
I am trying to broadcast packets over a specific frequency and I want a phone running an application to pick up on these packets. The phone will not need a connection to any network to do this, but simply have it's wifi turned on. The broadcasting device does not need to get any information back from the phone and delivery of every packet to the phone does not need to be guaranteed, much like UDP.
Where do I start? Is this possible for phones without rooting them. Is there some kind of FCC regulation against doing this (over the standard wifi spectrum).
I know this is possible because it's exactly how routers tell a phone they are available to connect. Thanks in advance for any input.
I'm not familiar with iOS development although similar techniques may exist.
Without root
But requires coarse- and/or fine-grained location permission on Android
You can use WifiManager.getScanResults() to scan for wireless router broadcasts.
The network "name" (SSID) and router MAC address (BSSID) are included in the results. You could broadcast these packets and encode data into these fields.
That said, I hope your messages are short as you'll be getting 38 bytes per packet (32 SSID bytes + 6 MAC address bytes).
Yes, some MAC addresses are special or invalid, but if you're just broadcasting and not actually using them, they can still transmit the data.
With root
Depending on the wireless chipset and driver support, you may be able to put the device into "monitor mode" which gives you access to the raw packet data.
The main drawback is that there is no official support for it.
You might find some hacky ways to do this from a Google search but I wasn't able to find any universal solution that works on all (or even most) devices.
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.