I'm interested in the viability of implementing an Android application that interacts with a UDP service. I'm sure Android supports UDP:
http://www.helloandroid.com/tutorials/simple-udp-communication-example
What I'm less clear about is whether or not such an application would actually work on an Android phone on a typical tariff - for bidirectional communication. I want the Android client to contact a remotely hosted service by UDP (announcing itself) and for the server to subsequently notify the Android device about real-time events.
I'm concerned that a mobile device on a commercial network might be forced to change IP address - for example - when moving in/out of a Wi-Fi zone... and I'm unclear if NAT would be a problem on a typical 3G network.
Is it really viable to use UDP for bi-directional (best-effort) communications both to and from an Android phone?
There are a few issues for you to look at here. First, UDP is perfectly useable by Android. It can send and receive UDP packets just fine. The larger issue is really that the phone cannot receive incoming UDP connections that it did not open the initial connection for, unless it is on WiFi and rhe connection is coming from the same LAN.
On 3G/4G the phone is not addressable from the outside because the Wireless carrier has in place a firewall with a proxy server. So, incoming connections are not passed over that firewall. If, instead the phone opens the connection from behind the firewall, then bidirectional traffic can flow over that link.
Now, the problem you will have will be
1) Keeping the link alive when the phone goes from network (3G) to network (Wifi)
2) Battery life from the constantly open connection
Most likely, you really want C2DM for what you are looking at.
Related
I am writing a p2p messaging Android app, and I'm trying to solve the problem of NAT on mobile networks. I cannot currently find a way for a device to connect to another listening device on a 3G/4G network due to the carrier's NAT service.
I have heard of a few NAT punch-through methods, but a lot of those involve using some sort of centralized server as a mediator. I am trying to use a completely decentralized p2p approach to accomplish this task.
Are there any feasible ways of allowing a device on a mobile network to be publicly addressable?
Thanks!
No, it is not possible. Most of the time, subscribers with IP addresses NATed are behind NAT444 and many subscribers are anycasted ( subscribers have the same IP on their mobile phone, but nated behind a different NAT devices). And 2 anycasted suscribers cannot communicate together.
The only way left you is to open a VPN to get a real IP of Internet Public.
My suggestion would be: Do not use VPN for IPv4 ! Use VPN to get a real IPV6 to your mobile phone application, and build your p2p application over IPv6.
You are fighting with very old problem that drove IETF to build IPv6.
So, go to IPv6, and forget ipv4.
The ONLY good solution for your problem is to build your app over IPv6, and your app has to bring the ipv6 tunnel to the phone.
I'm just confused about how SIP works but mine doesn't.
I made a simple android server which open up a server socket and listen to incoming connection on 3G/4G network. Then I made a client that connect to the server, the connection was blocked by my carrier's firewall(AT&T).
After this, I downloaded an open source VOIP app based on SIP, and register these 2 phones on SIP proxy, let them call each other, this works perfectly.
I'm just so confused about how SIP works on cellular network, SIP is a p2p protocol, SIP proxy is just for redirecting. How does these 2 phones connect to each other in VOIP session? Why is this connection not blocked by carrier? Can someone explain to me? Thank you in advance!
update: I just tried sending a UDP packet between AT&T and SPRINT network, it does not work ;(
In basic SIP the endpoints media traffic generally communicate directly between each other in a P2P fashion like you said. They do this be giving each others address/port in the SIP SDP negotiation.
In a "perfect" network world this works fine as all endpoints can talk directly between each other.
As we know, this is not the case.
In most cases, the main barrier in the IPv4 world is NAT.
The first solution people came up with is STUN. STUN will give you your "public" IP address that you are using from behind a NAT and the SIP stack will use that IP address in the SIP/SDP packets. This works as long as hole punching works.
The next solution people came up with is TURN. TURN is a UDP proxy and allows a client (e.g. a SIP client) to allocate and use a IP address/port on a private network from a public network (i.e. the internet). It should work in all cases but can put a lot of network overhead on the TURN server. It will not be as efficient as P2P connections tho. The upside of using TURN is that not both sides need to support it for it to work. So it's good when you are talking between a softphone on the internet to a hardware SIP device on a internal network.
The next solution people came up with is ICE. ICE needs to be supported on both SIP endpoints. It works by extending the SDP protocol to allow it to add all possible connections in the SDP negotiation (all local network adapters, public addresses provided by STUN and TURN allocated addresses in priority order). Then one side goes through the listed connections and tries to make a connection. This allows both connections to be "try" to connect P2P and fallback to a TURN connection if nothing else works. It should also work in any networked environment to any networked environment and find the most efficient network path between the SIP endpoints. The downside of ICE is that both SIP endpoints need to support ICE for it to work. (As a aside, ICE/TURN/STUN is now a requirement for the WEBRTC protocol for web browsers to talk between each other for the same reason)
Other possible solutions would be for you to have some sort of "smart" sip proxy in the middle that maybe fakes ICE on one side if the other side doesn't support it. Another is to have some sort of media gateway or B2BUA if transcoding is required, this would have the same problems as TURN tho.
I would suggest that you setup your SIP client with STUN, TURN and ICE if possible and that will increase the likelihood of the SIP call actually working.
As to why your case doesn't work now, it would require network and/or SIP logs to understand what the exact impediment is.
I have read these Getting Started with WiFi on Android. Implemented Marakana's tutorial for basic wifi functionalities.
But my question is: Is there a way to find the number of users connected to a wifi network?
If it can be done, kindly share a link or resources.
If it cant be done, kindly provide some detail, why not?
Thank you,
Getting a list of computers on a network is inherently an unreliable proposition, wifi or wired.
There are three common approaches: a discovery protocol, scanning, and passive listening.
Discovery protocols (such as LLDP from the UPnP framework) work very well for devices that support them. Occasionally also for devices that don't. They don't work at all if firewalls block them, or if switches or wifi access points are configured not to allow traffic between devices.
Scanning means, sending a probe (such as a ping) to each possible IP address. This is something many intrusion detection devices block, and many wifi access points will also prevent you from sending a ping to another device. Also, scanning is entirely unfeasible in IPv6 because each network has billions of IP addresses to probe, rather than the usual 254 in IPv4.
Passive listening means, simply paying attention to the layer-2 traffic on the network, and building a table of MAC addresses based on the ARP traffic (or all traffic). That only works reliably if you have a wired network with a hub - switches don't forward all layer 2 traffic everywhere (although the ARP messages you need most are usually broadcast and available). WiFi isolation may also prevent you from getting enough layer 2 traffic.
I'm trying to develop an Android application which have to be able to transfer data/message between two Android mobiles, as a client server connection using their own Wifi, which having no network or routers nearby. I just tried using Tcp program to do this but it fails, its not connecting, I'm getting ConnectException and connection refused.
[Edited] Is it possible to achieve this using Android Portable Hotspot integrated with application? Is there any tutorial regarding this approach?
Any Ideas, how to do this?
Thanks.
You need to get the two devices networked to each other before you can worry about tcp usage of that network connection.
If one device is willing to perform access-point like functionality as part of a portable hotspot, and you select that as a wirelss network on the other, you may achieve a network connection between the two that can be used for custom traffic. Though there are ways the hotspot could be implemented where that would not work. Also of concern, the "client" device will now be sending all of its network traffic through the hotspot device, including not just foreground apps but anything it decides to do in the background.
We want to establish TCP/IP connection between two android devices.
For now we thought that it would be simpler if we make the connection device to device. So there is no server that is between the two phones.
Most of the time (if not always) one has no real IP address (NAT and so on). Is this a problem for creating a TCP socket?
I didn't manage to find any exact information for this. Any advice and opinion will be highly appreciated.
Thanks
Is this a problem for creating a TCP
socket?
Answer is no, it does not make it impossible (unless NAT's have an unpredictable way of mapping IP addresses). However, it is not simple to accomplish.
The short answer is you'll always need a server-like peer with a public IP address to facilitate initial communication between peers located behind NATs. The peers connect to it. A tells server it wants to TCP connect with B. Server notifies B. NAT behavior analysis is performed and if possible, A and B attempt to open TCP communications with each other by predicting the next mapping of the other NAT. If all goes fine (and usually it does) A touches base with B or vice-versa. They close the other connection attempts and communicate with the operational TCP connection. This technique is called STUN for TCP.
Now, there are more complicated reason why things can go wrong. If you want to know more, I have written a book called Practical JXTA II which available for reading online at Scribd. There is a chapter dedicated to NAT traversal.
Hope this helps.
One device behind a NAT is not a problem. The requirement is: the server must be reachable by the client.
I'm using Apache Mina to handle TCP connections. It have really made my life easier. It can be used on both client and server. Give it a try...
Well to make a TCP socket one device must be listening and the other connecting. However in a real world scenario what you describe is sort of hard.
Like if you are going to communicate over a cell network between two phones, I wouldn't be surprised if the network did not allow inbound connections to a phone like that and just sandboxed each phone's IP. So while two phones might be on the same subnet IP range, they might not be on the same physical network which just makes the whole routing problem almost impossible.
If you are in control of the network and are using Wifi and natting the IPs yourself with both devices within your network, you should be able to do this just like any other client server TCP socket.
If both nodes does't have global IPs,, and are not physically in the same network,, then its impossible to communicate over TCP without a server, unless you created a controlling server that act as a relay to tell the nodes about any changes occurring on the other side
It is possible but you can experience some problems.
First of all you have to know the public address of the host you want to contact, and if your two host are in different NATTED networks you should do it using some server (like you do in SIP telephony).
Then you have to hope that the contacted host is behind a 'good' NAT like 'full cone' or similar and not behind a 'bad' NAT like 'symmetric' that not allow incoming connection. The fact you use a TCP connection instead of UDP datagram can help you because of the three-way-handshake. In fact most NAT routers accept incoming TCP connection, but not incoming UDP packets.