I have a simple app idea in my mind and I need to know how to connect from an Android application (client) to a Windows application (Delphi, server).
There is no need to be specific about the platform, I am familiar with networks in Delphi using winsock or Indy and I'm sure I will be able to figure out the appropriate mechanism in Android.
What I need to know is how to connect to a server (computer), which doesn't have its own public IP and is not in the same network as the client (one can be behind a local router, while the other might be connecting to the internet through 3G, for instance). This should be possible, as many programs work like that (remote desktop programs, TeamViewer, for instance: one computer is assigned an ID and using this ID other computer can connect to it.) I will not have access to the routers behind which the app will be running, so port forwarding is not an option.
I have a working network app, but that only works in LAN, so I'm guessing somewhat another approach is needed.
Thanks for answers
Many of the programs that work that way still use a server with a public IP. Each side of the client connections to the server to say "here I am". The public server can then shuffle data between the two clients.
That still leaves a lot of questions regarding the communication between the public server and each client - i.e. pull vs. push for taking data that was sent to the server and getting it back down to the second client.
You may want to read the specification for Copilot (originally named Project Aardvark). Joel Spolsky published the specification when the started the project. It talks about their use of a reflector service.
The Reflector
A Windows Service which we run on our servers, used to
allow any helper to help any victim even when both of them are behind
firewalls. Both helper and victim connect to the reflector. The
reflector checks that they are authorized and relays messages between
helper and victim until the paid-up time runs out
you could put an intermediate server which they can both route for "nat traversal".
otherwise you will have to put port forwarding on one of those computer's local router to allow incoming connections to be forwarded to the computer.
Related
I am trying to develop an Android (server) app that will accept TCP connections directly from the Internet. I tried this a couple of years ago with no joy. Is this even possible?
I asked this question differently way back then, on StackOverflow and elsewhere, and never got a satisfactory answer. The answers fell into two categories:
No, you can't
Most authoritative answer given: Most carriers won't route connection requests to mobile devices.
Yes, you can
These answers did not provide details or examples to help me.
What I Tried
I can successfully get my mobile device's external IP through various means. But this is only part of the puzzle. See Note 1 below.
I created a ServerSocket that listened on a port (e.g., 2000). But the app would not accept connections from the Internet on this socket. Apparently, this socket was listening on the local (internal) network of the device (i.e., 192.168.1.0).
I was able to connect from other apps on the device (which are on the same subnet).
I was also able to connect through a NAT router in my shop that translated Internet addresses to my device's local net. But this doesn't help me in the field (where no router is available). See Note 2 below.
I tried asking AT&T customer-support-type people but I don't think they understood my question.
Notes:
Yes, the device's IP address can vary with time or location, but I can always get the correct and current IP through various means (e,g., whatmyip.com, etc.). Nontheless using the current device IP doesn't work either. BTW - my public IP has never changed. Thus, for all intents and purposes, my IP is static. In any case, the IP issue is a well-flogged horse, I am fairly sure that this is a ROUTING issue, not an IP address issue.
I can connect via WiFi because my Internet modem/router offers DHCP connections on the back side via Wifi on the device's local subnet (192.168.1.). My device has address 192.168.1.65, therefore I can connect to it without ever going through my carrier.
AT&T tells me that I cannot buy a static IP for a mobile device (update 9/23/19).
My Current Theory (9/23/19)
It is my current humble belief that there is a NAT-like entity at play here. Either:
The public IP actually points to a NAT router at AT&T HQ.
The device has a built-in NAT-like router
In either case, under this theory, inbound TCP connections are not forwarded to the device's local net, but outbound connections pass through just fine.
Summary
Maybe the answer's still the same, but I thought I'd ask again in case things have changed or somebody's got some better insight nowadays,
It's true that you can't establish any TCP or UDP connection which is listening behind the main network (i.e. behind the NAT). Nowadays all the ISP allocate a private IP to every device (due to shortage of IP) connected to it hence creating a private network of devices behind NAT. (After the complete adoption of IPv6 the situation will change with every device becoming the part of main network)
Since NAT doesn't allow an inbound connection, the problem is solved using some of the NAT traversal technique such as:
Port forwarding
TCP/UDP Hole punching
In the Port forwarding process, we need to deal with the router setting which will forward the connection on a specific port to the same port on the internal network node. It is mainly used in gaming, VoIP, and p2p application.
In Hole punching technique (no need to deal with the router setting) we use an external server which is not behind any NAT to get the IP address (both public and private) of the devices which are behind NAT. Further, the two hosts create there own outbound session among each other in their respective NAT devices. Since the NAT devices allow the outbound session, the session is stored, and this same session is used for further two-way communication.
More information about Hole punching.
(UPDATED 9/26/19)
I am posting this "answer" not so much as an answer per se but rather to solicit constructive criticism and/or affirmation. Any statements I make below should definitely be implicitly prefixed by "I humbly believe that...".
Yesterday, I had a personal epiphany. I finally got it through my thick skull what some responders were saying. I present my new understanding below.
Heretofore I believed that AT&T's Mobile Data Network was just a direct extension to the Internet implemented with cell sites and trunk lines. Now I realize that it is a closed, private data transport mechanism. Since it is owned by AT&T, they can implement whatever protocols they choose to, including "private" data connections from their head-end to my registered phone. These connections are analogous to the LAN-side ports on a typical desktop NAT router. The head-end (i.e., their NAT router) is the only entity that can be accessed from the Internet.
The head-end connections between the Internet and my phone are over these AT&T-private connections. The "public IP" reported for my device (and, I believe, nearby devices) actually points to the AT&T head-end, in my case a 150 miles away in Miami). The head-end fowards outbound connections from my phone to the Internet, but does not forward inbound connection request.
About my "Public IP"
I believe that this doesn't exist and is, in fact, a meaningless concept. What would be the point of such an address if you cannot connect to it.
Summary
I now believe that the answer to my original question is "No way, Jose". This is not due to an addressing issue, but rather AT&T will not route incoming connections to devices. They also do not offer static IPs for devices over their private network (this wouldn't make much sense anyway given the above).
IF ANY STATEMENTS IN THIS PROTO-ANSWER ARE INCORRECT, PLEASE PLEASE LET ME KNOW WHICH ONE AND WHY IT IS INCORRECT
It depends on what type of IP your mobile phone provider assigns you
For your mobile device to accept TCP connections from the outside, it is only possible if your provider assigns you a public IP, but this is increasingly unlikely since given the shortage of available IPs many providers assign a private IP, like if your phone were inside a LAN, in this case your TCP port is unreachable from the outside.
Websites like whatsmyip tells you the public IP with which your provider finally connects you to the internet but it may be different from the one your provider assigns to your phone.
To know if you are in a private network install from Play Store an app called "PingTools Network Utilities".
When you start it you will see the IP of your phone, if it is different from the whatsmyip IP or is an IPV6 one that means that your provider assigns you a private IP, an unreachable one.
... always talking about connections through the cellular network and not through WiFi
Write a simple client for DynDNS or alike, in order to provide it with name resolution. Then you can serve pages with NanoHTP - or raw sockets. If you're behind a DSL router, you may need to read the external IP with TR-604 (unless DynDNS might eventually return the source IP) and setup a NAT port-forward for the incoming traffic on port :80. At home this is easier to setup than through UMTS, because some UMTS networks don't have public IP addresses, but may have private IP addresses.
I want to give a non - technical answer as I myself am not very proficient with network theory.
One thing is that Internetproviders usually expect extra cash if you want to run a server - hence the forced disconnects on consumer subscriptions like DSL(changing IP in the process).
Next thing is that establish a connection and send data out to a server is very unreliable on a mobile device. You can have android check if you have network. If it says no you don't need to try it - no means no. But yes doesn't mean a thing!
I write software for asset tracking using android. Usualy I want to send like one location per minute to that server. So I try to open a port. Android blocks on new Socket and it can go for like 2 Minutes until a timeout occurs even if I checked with ConnectivityManager right beforehand and it got me isConnected() == true.
And if I have a socket and even received something a second ago: I can write to that socket and get no error but get no answer, write again, no error no anser again and again.. And after like 2 minutes I get a whole bunch of errors in the log all at the same time.
When sitting in the bus visiting my mother is like driving through a 3rd world country judging by the internet connection. It might say 4g and 3 bars but chrome won't load page OR it says 2g and only 2 bars yet browser has no problems at all..
The whole android network-os (and I guess apple has to do it quite the same) is programmed more like: "here android I want to send this" and android saying "Ok" but thinking "I will send it as soon I feel fit to do so" :D
you need a static ip(public ip) address for that .
Mobile device ip address are not static so u cant .
To make it work .
Run a web server on a static ip & route the queries to your app (tunnelling).
When android app starts ,you android app needs to register with web server .
Now server knows your android device availablity ,the queries from other end will be be rediredcted.
I would like to connect to a client application running on Android devices which are running on NAT'd networks. Basically, I would like to run my own WebKey server (www.androidwebkey.com) which runs a web server on the Android phone.
I would prefer not to run SSH tunnels or VPNs if I can avoid it. So my question is, how do people like 'Log Me In', 'Web Key' etc work?
I have the following topology :
Android \
Android --- ISP/MNO NAT -- My Public Web Server ----My ISP NAT --- Me (Using a web browser)
Android /
Each Android is running a web server in effect, although this could just be a VNC server. I just need to be able to get onto them remotely.
I have googled and googled but I am struggling to find information on it. Obviously it is possible because it is exactly how Web Key and Log Me In work.
I believe I have to intiate a HTTP connection to a my public server from the Android devices and use 'Keep Alive' headers, but I am not sure how I then connect through my public web server to the end client. Can I just connect to the port on the web server that is assigned to this particular Android handset?
Can anybody point me in the right direction?
I realize this is old, but I'll contribute an answer since I didn't see one. They usually have a component on a public server which marries the client and the server. So basically the client connects to the component, the server also connects to the component, and the component proxies the communication between the client and the server.
I won't go into details for now since the question is old, but that should give the basic idea. In some instances the connection from the client to that component is initiated on demand through a request on another channel, in other cases it's constantly maintained.
So in these cases, it's really not a point-to-point connection, it passes through a central location.
This question already exists:
How to remotely access a LAN network (embedded) device without port forwarding? [closed]
Closed 9 years ago.
I've looked around SO and haven't found exactly the answer I'm looking for, so please forgive me if this is a duplicate. If so, please direct me to the answer. Thanks.
I've got an embedded sensor/actuator system with wifi connectivity to my LAN.
What are possible software/protocol solutions so i can communicate with and control it remotely, from outside my network with an iPhone/Android (i.e. via 3G/4G) and/or a remote PC?
i don't want to have to configure my router for port forwarding.
Here are a few other considerations:
embedded processing platform is pretty limited (i.e. it's not an ARM)
security is important (i.e. don't want others to be able to gain access easily)
scalability - if this project goes commercial, scalability of this model to many, many users is important
user simplicity (i.e. no messy configuration reqs for the end user)
I've heard a little about MQTT, which looks like it might be a solution, but I'm not sure about security. Any thoughts on that?
Any other options that are free?
Thanks a lot, Brian
To use MQTT you will need a broker that is accessible from both inside the network and outside.
So assuming you host your own broker you will need to set up port forwarding to allow access to it from the mobile device. The other option would be host the broker on a cloud service.
Security can be handled by doing MQTT over SSL and using client side certificate authentication so only your client application can connect to broker.
If you have the system working inside LAN, you could use a package such as wamp running on a networked PC to act as a server and set up an external facing network interface which can handle security. Then use the wamp server to forward to the embedded device when required through PHP etc. That would save working out how to directly communicate securely with an embedded device.
I can't suggest anything more useful on the amount of information given
I'm building a multi-OS mirroring system which I would like to implement using a hybrid client-server and p2p communication method (at least that's the best way I have of describing it).
My issue is that at some point I have a central server (appengine, so there are limitations to what I could do because of time and networking capability constraints) that would need to get a message to a host of different devices which are not necessarily running the same OS (Windows, Android, iOS, Linux, etc...).
Android and iOS (or any other mobile platform) are the main problems it looks like I will be having on 2 levels.
1 - They are both limited by battery power (more so than a laptop and desktops shouldn't have that issue at all), so whichever method I use needs to take that into account.
2 - NAT (harder because the user has relatively less control over their firewall than on a network that they are running). My central server will maintain a table of which device has what IP address, but from what I understand if there is NAT or a firewall it won't be able to get to it if the port was not forwarded.
Since I will be writing a specific client for each OS I prefer a solution that is more universal. I have been leaning towards writing an extremely simple HTTP server that sits on each client and takes requests (which appengine is able to send) and treats them as messages that alert the client to perform an action (either with the server or another client). However, I run into the issue of NAT/firewall. For instance if appengine needs to send a message to AndroidDevice1 it would grab its IP address from a table and make a request to it. However this doesn't work if the ports aren't forwarded correctly, and if the user is on 3g/4g the firewall is controlled by the data provider.
Because of this, I started thinking about using Android C2DM but I want a solution I could implement across platforms.
The only other method I could think of is to just have the client poll the server for messages. This has the battery and network consumption issue though.
Would there be any other way to implement this, and if not, which one of the above methods are best in terms of balancing usability, power and data consumption and user input (the less the user has to do to get the client set up (ie port forwarding, etc...) the better)? Please note that I do not intend for this to become a discussion/flame war but a logical presentation of facts.
Thanks in advance!
You can create a persistent TCP connection from the device to the server and then communicate over this open connection. This would be a very simple connection with keepalive packets for the most part.
In theory this would consume some battery through the radio, but in practice I have experienced that the battery is not affected much at all. Key is to keep the communication over this line to a minimum.
If AppEngine does not allow this approach, you can run your own socket server and then communicate between this server and the appengine server using REST. A socket server I have used is Apache MINA and had no issues with scalability.
Another problem you will have with this approach or any other approach is that on iOS (afaik) you cannot keep a tcp socket open when the App goes into background. The only thing to communicate with the iOS device is Apple Push Notification Service
I would prefer rather than having HTTP Connection you should create TCP/IP tunnel and make communication fast and reliable. I have one Chat application which runs perfact for me using TCP/IP. If you use this you will have same logic for multiple platforms. Only thing you need to write is different code for iOS and android.
What is the general communication architecture for two android applications?
Case 1:
I have two android applications,
a) One is a server that waits for client request, process the request( read data from some sqlite db) and return the results to the client. This server application runs on its own independent android phone.
b) The second is the client that sends the request to the server application in (a) and it too runs on its own independent android phone.
Question is, do the two applications have to go through the Mobile Service Provider to enable communication? or they can just talk to each other directly via some public IP/WIFi etc. What is the communication structure/architecture for this applications?
Case 2:
I have an android application running on an independent android phone, and i want it to talk to some server application (Web Server / Application Server) running in some machine somewhere on the internet, sends request and get some feed back.
Again, do the two applications have to go through the Mobile Service Provider to facilitate communication? or they just establish a straight TCP/IP communication via some public IP?
Any reference articles would really help.
Thanks
Gath
Question is, do the two applications
have to go through the Mobile Service
Provider to enable communication?
If you want to use 3G, yes. If you want to use WiFi, no. Generally, Android applications do not care where the Internet connection comes from.
or they can just talk to each other
directly via some public IP/WIFi etc.
If they have a WiFi connection, they have a WiFi connection. What you do with that WiFi connection is up to you, using Java sockets, and respecting all the normal problems with Internet access (e.g., NATs).
Again, do the two applications have to
go through the Mobile Service Provider
to facilitate communication? or they
just establish a straight TCP/IP
communication via some public IP?
You ask for a Java socket. You get a Java socket. You do something with the Java socket. Where that Java socket comes from and how its connection works is generally under the covers: 3G, WiFi, a squadron of very tiny passenger pigeons, etc.
I'd suggest Android – IPC, aidl and IBinder and Grasping Android's IPC mechanism for a start. After that just hunt on Google for 'Android IPC'
Something about sync is here Synchronization in Android