Here is my scenario.
I have my device (android phone).
And I know the IP address of another device (which is some remote device in the Internet)
So how do I send data to the other device?
Do I use protocols like Tcp or Udp?
EDIT : And I know there are public IP addresses and private IP addresses (like when a device connects via WiFi). In such a case is it even possible to use Tcp or Udp???
What you're looking to do is a common task with a common problem (but also with a common solution). You want to send data from one device (computer/phone/etc..) to another. Here's how it works behind the scenes:
There are a lot of computers in the world. Each computer is given an identity - a name, if you will, which is called the computer's IP address. There are many versions/standards of the IP address, and the current standard names an IP address as such: "111.222.333.444". There are only so many permutations with 12 digits of numbers - and entire ranges of IP addresses are reserved. In other words, there aren't enough IP addresses to go around for computers.
Now, routers were invented, among other reasons, to combat this problem. Routers give all computers within its local area network (LAN) one public (WAN) IP address. With an average of one router per household, this saves many IP addresses. Unfortunately, it also breaks direct communication between computers, because how does one communicate with three computers all using the same name? How does one identify computer A from computer B from computer C when they all share the same WAN IP address?
First, let's clarify that - just like there are a few versions and standards of IP addresses, so there are a few types of routers. By the way, it's not the router that is to blame for the problems of direct communication between computers - it's actually the router's underlying technology of network address translation (NAT). Anyways, there are a few types of NAT, and although information on the internet is relatively scarce on these types, you can still Wikipedia it and read a few university research papers. The types are Full Cone NAT, Restricted NAT, Port Restricted NAT, and Symmetric NAT.
So, computers in a LAN share the same WAN IP. This is a problem. What's one solution? What if we instructed the router to route all incoming traffic directed to a certain port, to a certain computer in our local area network? For example, if three LAN computers share the WAN IP of 1.1.1.1, we can setup a procedure called port forwarding to instruct the router to route all packets arriving on port 6000 to 192.168.1.101:3500.
uPnP is just a fancy technology (not always present in routers - or more importantly, hardly ever enabled by default) that allows you to port forward using code.
If we can't use uPnP to port forward because not all devices have it enabled, there must be another solution - and there is: hole punching.
Hole punching comes in two flavors: UDP and TCP, although TCP hole punching is a bit more complicated because TCP is inherently first a connection-oriented protocol. UDP hole punching is easier because you can send packets without a connection (in fact, is there really such a thing as a connection?)
You can read the procedure on UDP hole punching on Wikipedia and other sites. The concept works like this, though. Any computer sending an outbound packet will expect a reply, meaning the router will allow the inbound packet's reply. At first, two computers will not expect a reply from each other, so the first packet each computer sends will be rejected by the router. If we continue sending packets, however, the router will allow the rest of the packets to come through, because a reply is expected from each computer. As long as this hole-punched connection is maintained active by occasional keep-alive packets, it will stay alive. Unfortunately, this method of UDP hole punching is unsuccessful for Symmetric NATs (explained in the links below). That's why the end-all solution is to simply proxy the connection and traffic through your own server. This requires a farm of computers, so it's quite costly. But this end-all solution is called TURN. STUN is a web service you can query to determine your NAT type and public IP (as opposed to parsing cmyip.com). Just some terms you'll encounter along your personal research.
Playing around with these concepts help. Here are some resources to get your started:
Types of NATs: http://think-like-a-computer.com/2011/09/16/types-of-nat/
A Method for Symmetric NAT Traversal (basically by spamming a lot more packets to a lot more ports): http://www.goto.info.waseda.ac.jp/~wei/file/wei-apan-v10.pdf
Lidgren Networking Library (which has NAT traversal built-in, this is a C# library): http://code.google.com/p/lidgren-network-gen3/w/list
In most realistic cases, you send data to the other device by sending the data to an intermediate device from which the other phone picks it up. Can can use protocols like TCP or UDP directly between the two devices, and that may or may not work depending on the protocols and how the devices are getting Internet access.
For example, one device can send an email and the other device can retrieve that email. You can generalize that model to other types of communication.
Related
I created a UDP server on android app, and this UDP server is reachable via wifi (Local network). I can receive and send data. However when I change to 4G network. The UDP server on Android not able to receive anything. I use ip chicken to check my cell phone IP address and my UDP server port is 2004. Is there anything wrong? or my public ip is not correct?
Assuming that your phone IP address is correct, and it looks like you have checks this, it is important to know that mobile network providers may not support UDP inbound connections on their networks.
While it's not true to say that all don't, it is true to say that not all do so if you want your solution to be portable across networks you may need to look at alternatives anyway.
There are examples and guides on traversing network address translation boundaries on networks - one good example, which is looking at peer to peer applications, is here: http://bford.info/pub/net/p2pnat/
I have two Android KitKat phones, both are running WiFi-Direct groups as Group Owners, let's call them GO1 and GO2
I managed to connect GO1 as a legacy client to GO2 without breaking any of the (previously set) wifi-direct groups.
The problem is that, as you might know, the GO IP address is hardcoded in Android source, and is set to 192.168.49.1
Therefore, both of my devices, GO1 and GO2 have the same IP address (**)... each on his local network.
My app is both client and server at the same time. But both networks are using the same IP range (192.168.49.XXX), which, apparently, I cannot change.
As a result I cannot create a TCP connection between them if they are both hosting a WiFi-Direct Group, since any device will connect to itself when trying to connect to 192.168.49.1
So the questions are:
Is there a way to change the IP range used in Wifi-Direct?
Is there a way to use IPv6 instead of IPv4 in Wifi-Direct?
Can any of this be done without rooting the phone?
Any other suggestion?
** : Actually, because GO1 is connecting as a legacy client to GO2, then GO1 is known as 192.168.49.227 (for example) to GO2 and GO2 is known as 192.168.49.1 to GO1. But because GO1 is ALSO a GO, it also known as 192.168.49.1 to his clients (and itself).
A way to get around this without rooting the phone is to send your packets via multicast UDP*. These packets will make it from GO1 to GO2.
There are some side effects to this:
To use this for networking you must perform encapsulation and routing at the OSI Application level (not efficient).
You will also need to route based on MAC addresses since every device has the same 192.168.49.1 address.
"It is important to note that the multicast socket encapsulates a one-to-many unicast communication and, as a result of this, cannot fully utilize the total available WiFi and WiFi Direct bandwidth" *
Something else worth noting:
As you scale up the number of GOs, you will run into a problem of all nodes operating on the same wifi channel. This isn't a problem with a few devices, but with hundreds of devices, it will be a huge problem.
*This method was mentioned in Colin Funai, Cristiano Tapparello, and Wendi Heinzelman paper titled "Supporting Multi-hop Device-to-Device Networks Through WiFi Direct Multi-group Networking" found here: https://arxiv.org/pdf/1601.00028.pdf
There is no way to change the IP range because as you have correctly pointed out, it is hardcoded in the Android Wi-Fi Direct system service. Personally, I am not aware of IPv6 being enabled on the Wi-Fi P2P interface, and even if it was, it would likely be a hardcoded IPv6 address.
If GO1 and GO2, must be connected to each other whilst both in GO mode, then perhaps look at using Bluetooth or some other transport to allow them to communicate. If communication between GO1 and GO2 can be delayed, then cache whatever information is to be exchanged, and send it between these two devices when one can be the client of the other, e.g. when GO1 can stop being a GO and can be a client of GO2.
I followed a chat app tutorial that connects devices using TCP sockets.
For simplicity, I split the app into 2, so that one is the server and the other is the client.
The app works fine when I am using the same wifi network, but it does not when one of my devices jumps into a different network.
This is where I get confused on the concepts.
Because they are different networks, I cannot use the local IP as I have been doing. I did find using the public IP is possible, but I'm still new to coding so am not sure if that's the right method. Should I look into VPS? Or GCM?
Do I need to rewrite my app such that I have 2 clients (that talk to each other) and that they go through the server with a static IP (like a middle man)? But then I get confused because in that case, Client would start first and then talk to Server. But I always thought Server was to start first and wait for an accepting socket??
Not sure if this is the right place to ask these questions, I'm just really confused on the concepts. Thanks!
For socket programming in your apps, the only info you need is IP address and port number. After switching to another network, the only modification to your source code is IP address.
When devices are not in the same local area network, you need routers to locate each other, in theory. If you don't own control to routers, using a public and static IP is the right solution. The app acting as a server should have this static IP and should always be alive, and listen to connections. The app acting as a client starts later and connects to the server with its IP address and the port number you've defined.
Normally when you get access to Internet, you get a public IP from your ISP, and it keeps static if you keep online, in most cases. So just find out the IP address on your server, and connect to this IP address from your client app. If your internet access is gained from a wireless router, you should set up port forwarding on the router, and use the IP address of this router at client.
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.
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.