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.
Related
I'm having the following scenario:
On the PC i will have a program running: java or .net, haven't decided yet.
When a certain event happens on PC i want to notify the android device.
I want a solution as independent and reliable as possible.
Opening a server on the PC/Android i think is out of the question because the user might be behind a router or on GSM internet (as far as i know it can't open ports as server)
The solution i have at this moment is to have a web server on the internet and have it handle the job, but i'd like not to use this because the delay between checks should be around 5 seconds, and i expect to have about 2-3k users simultaneously, and that will probably know down a regular web server.
So, any ideas how this communication can be made?
You may consider the option of Bluetooth client server application since PC and Android device usually have Bluetooth. You will have a Java server running on the PC and an Android client on the device. Check out this post: Send text through Bluetooth from Java Server to Android Client
You can handle the situation where Bluetooth is not available by creating a failover mechanism using REST API & JSON.
If you're already a web developer, I think creating a light HTTP based REST or JSON service would be a great solution. You've already said you don't want to do that which leaves the option of rolling your own client/server set up.
On the Android side of things, one way to do it would be to use TCP sockets. You can learn more about them here: http://developer.android.com/reference/java/net/Socket.html
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.
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.
My question is how to create a web service on android device & host it on the mobile device.
I don't want to access an already created webservice deployed on a server; I want to create a webservice that returns json/xml & host it on mobile.
RESTful Web Services Implementations in Mobile Devices says it's doable for Java-based mobile devices, so I think it can be done for Android too.
There is one problem with your setup and mobile devices: mobile networks (wifi and 3g) mostly use NAT, which prevents inbound connections. This makes mobile devices inaccessible from the internet (inbound) while they can still initiate outbound connections. For this reason mobile devices mostly do not host servers.
What you can do is make an Android service which pings a server ( a web-server) every 30 minutes or so simply send a bit from client to server and back to check the availability of request from another phone. This way you can upload media files to server and download them to your another device.
I am trying to solve the same problem and I am leaning towards https://github.com/NanoHttpd/nanohttpd.
It is a tiny webserver without any REST or MVC functionality, thus you would have to write it yourself (MVC, content negotiation, etc).
I would like to write an Android application that can be activated by sending it a command from a web site. Is this possible? Actually, the app would be running on the phone and I would be sending it a command via HTTP.
As of Android 2.2, you can start playing with the cloud to phone messaging system (more information here)
You could have your application maintain a connection to the webserver waiting for a command. This kind of technique is often used in AJAXy websites that update in real time, and is called the "comet" pattern or "long polling".
Basically, your client (the app on the phone in this case) requests a certain page. Your webserver (or PHP or whatever you're using) checks to see if there are any outstanding messages or commands to be sent to the client, if not it keeps the connection open and waits either until a message for the client is received, or until a certain timeout.
There are a couple of obvious drawbacks to doing this:
Your webserver needs to maintain 1 open connection per user of the application. Depending on the server, this can tie up resources fairly quickly if you have lots of users
Your application will be using resources constantly as it will also have to maintain an open connection and re-establish it periodically
This is all assuming you need near-realtime responses to your commands. If they can be delayed, normal polling should suffice.
You could have the server send an SMS message to Android. On the Android side, your app listen can listen for the SMS message and execute the appropriate command. Here is a question about sending SMS from a server. Here is some help on using sms in android.
I'm not sure if you can keep your SMS messages private to your app. Ideally you wouldn't want the user to see these SMS messages as a text message. Perhaps you could just delete the message as soon as it is processed.
This is completely possible. Just start a webserver on your phone. For instance: http://l00g33k.wikispaces.com/micro+HTTP+application+server
A bit of tooting my own horn:) Now with that addressed...
This will not work over many 3G networks (no public IP address)
If no general public access is required, you can use two SSH connections to an SSH server. I have done it many times and is as secure as your SSH setup.
and has all the security ramifications of running a Web server on an actual server without most of the tools (e.g., firewalls) to manage them
If general public access is desired, you can do it with one SSH connection from the phone to the SSH server. You need to open a port on the SSH server but you don't need firewalls management because you can run another Perl script to filter the source address and forward to the phone through the SSH connection. There is another thing that is good/bad about it depending on your view. Since it requires an active SSH/Android ConnectBot connection, you know when it is active and it drops off when you close the SSH connection. To me this is added security. And I have done this to send KML files to Google Maps' Google server (KML file must be publicly accessible without password to the Google server even though the file is on your phone; I filter by Google's IP address.)