can someone confirm, that it is possible to create a web server on android device ( which uses 3G or 4G internet ) and access it via internet ( from the remote PC connected to the internet, not from the same local network ).
I know there already are some web servers for android ( iJetty, nanohttpd ) and the programms like ksweb, so it seems, that it should be possible.
However, I've done some searching in the internet and some people warn, that mobile devices work using NAT protocol, so it would be impossible.
Can somebody resolve the ambiguity?
Thank you in advance.
No, it is generally not possible. The dealbreaker problem is not with Android, but rather that just about any mobile network provider is going to block incoming connections.
For special purposes, you can do things like have the phone contact a publicly visible remote machine and create a tunnel with something like ssh through which inbound connections can then be sent if there is a server program listening on the loopback interface of the Android device. But this tends to be only useful for things like remote testing.
Were you using wifi you could do this, but you'd need to accept that Android is not designed to promise a high availability of any 3rd-party program. You would need a wakelock to keep the processor running. And you may even need to do things like periodically initiate outbound traffic from the device in order to keep the wifi stack/radio in a fully active mode so that it can accept connections.
Generally speaking, data you want to make remotely available from the device should be proactively uploaded to a mutually visible server. If you want to send requests to the device, look at using something like Google Cloud Messaging which is designed to wake up the device and a recipient application on it in order to deliver a brief message.
Related
I have a situation where I want my computer in my local network to send a notification (push notification, SMS or whatever) to either an IOS of Android device that is on this same LAN. The trick is that I want to send this notification only when the LAN connection to the internet goes down. This means of course that my LAN cannot communicate with email servers, it cannot communicate with any APNs or GCMs, etc.
Is there any way to do this? My computer (the sender) is a Linux box and it will know the local IP addresses for any IOS or Android devices locally.
Yes this is possible.
You either need:
A) A server on the LAN to connect to, that the app knows about (compile-time or runtime configurable). The apps can connect to the server to exchange data, including messages. The server might be HTTPS, and the clients might poll every 5 seconds, or something more refined - using WebSockets.
OR
B) A peer-to-peer scheme. This can get quite complex, particularly given the varying nature of networking for mobile operating systems. As an extreme, you could use UDP for multicasting to multiple devices.
These are just two general examples, and you would need to research how to implement them for your needs. You should start with [A] for prototyping.
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.
I want to transfer messages/file from desktop application to the Android device. My question is that can I connect desktop Wifi device with the Android WiFi device without any use of internet connection. I want to use it just like Bluetooth. Is this possible/feasible or not? If it is possible then how can I implement it? And what is the message limit to transfer message/file?
Note : I wanted to use it as real time application.
Kindly suggest me any good approach and if possible then how to do that.
Thanks and Regards Dhaval
Wifi Direct will solve your problem, but there are no public API's available yet for developers. You will have to wait until Google releases it (hopefully soon). Some more reading:
http://www.sfonge.com/forum/topic/when-will-android-open-wi-fi-direct-api
http://groups.google.com/group/android-developers/browse_thread/thread/eb62f0aa0eccf161
Have a look at the Android Notifier application and it's sourcecode.
If you either convince your PC to function as a wireless access point, or obtain a wireless access point, you can set up a network connection between the PC and an unmodified android device. Note that it is not necessary for their to be an upstream Internet connection feeding the PC or access point.
You would then need to write a server running on the phone which listens for inbound TCP connections from the PC. Any android application with internet permission can do this, provided that you use a port number in the unprivileged range. You may have problems with the wifi timing out and shutting down, so you may need to use a timer to periodically trigger a small network operation (ping the access point, etc) to keep it awake. Note that this will use up your battery (what android wants to shut down an idle wifi to prevent).
If you can get both the device and the PC to work with an "ad-hoc" wireless connection you would not need the access point or PC to function as one, however last I heard this required root-level mods to the android device.
I want to connect a web service to android phone i.e. a request is to be made from web service to android phone. All i can find is article about android to web service but in it (as far as i know..may be wrong) a request is sent to server from android but i want vice versa.
Most carriers give you an IP address inside their networks, so you can't access the devices through any standard method. If the device is online via WiFi then you may have a chance (depending on your ISP and router policies, and given the case you have a web server or a permanent socket listening for requests). Nevertheless, it's still a very bad idea.
I would recommend you to use a different approach: make your android device call a Web Service that recognizes it (either via IMEI, IMSI, both, or a user parameter, depending on your app) and see if it has some "news" for him. If it does, then it should take an action depending on the received data. If you're familiar to Java, it's roughly like the MDB (EJB) idea.