I working on one project which Android device is act like a Server. I mean, when I send any requests to my device, then I will get a response.
If any one have any idea so please tell me. I am waiting for the reply.
A server usually accepts request on a certain IP and Port. This is a problem for mobile devices, because usually they're on a private network (behind a router) and one can not address IP and port of a special device.
So, practically spoken, I really doubt that a mobile device can act as a server.
A reliable solution would require some sort of extra proxy server. Basically your mobile will connect with this "ground-based" server and the system of proxy and handheld is the server you're looking for. It is operational once the handheld is connected. Client establish connection with the proxy and send their requests, the proxy forwards the request to the mobile device to get a service response for the client.
A nice architecture for this approach is XMPP, the implementation of the proxy server would be a standard xmpp server (like openfire).
Related
I am currently working on an Android app that needs to transmit data from one device to an other. I want to implement the data transmission without any server. I can handle the handshake to exchange the dynamic IPs on my own (Session Initiation) but I am struggling for weeks now how to send the data to the other device when knowing their public and private IP.
For now my app can just send data with TCP Sockets to devices within the same WiFi (so just using private IP). But they will get lost once I try to send to public IPs. Probably they can't pass the router's firewall. Turning off the firewall manually is no option. So I guess TCP is the wrong protocol. I think of something like "Voice over IP" but with sending any binary data instead of just video and audio.
My Ideas were:
something like Magic-Wormhole because it works like a charm on PC but unfortunately I did not find any way to use it in Android
RTP (Protocol used for Voice over IP)
"UDP hole punching" to handle the NAT.
One of those might be the solution. The problem is that I don't know how to implement such things in Java/Android
(my Project on GitHub)
Currently the internet is really complicated, basically you cannot reach another device by send data to its public IP because most PC or mobile device are behind a NAT.
What you need in such cases is a STUN server, the server can help two devices to communicate to each other in complicated networks. You can create your own STUN server by using open source implementation like STUNTMAN, but its really complicated, so my suggestion is just try a commercial STUN service.
You can check out the Google STUN server for RTP/UDP packet transmission to the network.
STUN servers: A Quick Start Guide
Port URI
STUN Server (Main LB) 19302 stun.l.google.com
STUN Server 19302 stun1.l.google.com
STUN Server 19302 stun2.l.google.com
STUN Server 19302 stun3.l.google.com
STUN Server 19302 stun4.l.google.com
I'm working on a server-client project. I hosted server on Google app engine so there is no problem with IP there, all the clients can connect to the server easily. Yet the problem occurs when I try to connect to a client, which is quite complex because I don't have static IP for the clients. Can anyone suggest me a good way for server-client coomucication in this case, without requiring that clients must have static IP address?
Thank you very much.
Well, obviously the client should register itself with the server and update it's IP when it changes.
There is, for example, a program which does exactly that and then publishes the IP with a DNS.
But you should be aware that the IPv4 address space is not that big and a lot of internet clients do not own an IP (and work thru the ISP's NAT). If you have clients that do not own an IP then you might want to stick to the usual Pull: the clients should periodically issue a request to the server to check if there are new messages for them. With a Keep-Alive connection and an efficient server implementation the price of such checks might actually be low, although that kind of communication might not work very well with the GAE pricing.
I'd like to know how a central server works in connecting two devices. I'm assuming that when the device application starts up, it should register its IP address and other pertinent information (username) with the server. When it wants to connect to another device, it should look to find the address of another device on the server, maybe with a get request. Then set up a to connect to a socket. If the device application closes, it should unregister from the server. Is this correct?
That's pretty much correct.
Because one or both devices are probably behind firewalls (including NAT), you have to assume they won't actually be able to connect directly to each other, so it won't be as simple as opening a socket to the other device once you find out its registered address. You will either have to try firewall-traversal techniques (which will usually be successful with UDP but not with TCP) or have a helper that isn't behind a firewall (which could be the same as the registration server or something else) carry all the data between the devices that wish to communicate.
Also, you will want to have the registration server time out registrations and the clients periodically refresh them, because clients won't always have a chance to deregister themselves on the server when they terminate or lose access to the network.
I have something like a proxy server (written in java) running between my clients and the actual video server (made in c++). Everything the clients send goes through this proxy and is then redirected to the server.
It is working fine, but I have some issues and think it would be better if I could make this proxy server only to listen to the clients requests and then somehow tell the server that a request has been made from the client side, and that it is supposed to create a connection with the client directly.
Basically in the TCP level what I want to happen is something like this:
1- whenever a client sends a SYN to my proxy, the proxy just sends a message to the real server telling the ip and port of the client.
2- The server would then send the corresponding SYN-ACK to the specified client creating a direct connection between client and server.
The proxy would then be just relaying the initial requests (but not the later data transfer) to the actual server. I just don't know if that is possible.
Thank you very much
Nelson R. Perez
That's very much the way some games (and Fog Creek CoPilot) do it, but it requires support on both the server and the client. Basically the proxy has to say to the client and server "try communicating with the directly on this ip and this port" and if they can't get through (because one or both is behind a NAT or firewall), they fall back to going through the proxy.
I found this good description of "peer to peer tcp hole punching" at http://www.brynosaurus.com/pub/net/p2pnat/
Does the proxy and server lives on the same machine? If so, you can pass the connection to the server using Socket Transfer or File Descriptor Passing. You can find examples in C here,
http://www.wsinnovations.com/softeng/articles/uds.html
If they are on the different machines, there is no way to pass connection to the server. However, it's possible to proxy the IP packets to server using VIP (Virtual IP). This is below socket so you have to use Link layer interface, like DLPI.
You don't have control of TCP handshake in userland like that. This is what firewalls/routers do but it all happens in the kernel. Take a look at the firewalling software for your platform - you might not even have to code anything.
Can a J2ME app be triggered by a message from a remote web server. I want to perform a task at the client mobile phone as soon as the J2ME app running on it receives this message.
I have read of HTTP connection, however what I understand about it is a client based protocol and the server will only reply to client requests.
Any idea if there is any protocol where the server can send a command to the client without client initiating any request?. How about Socket/Stream based(TCP) or UDP interfaces?.
If the mobile device doesnt allow you to make TCP connections, and you are limited to HTTP requests, then you're looking at implementing "long polling".
One POST a http request and the web-server will wait as long time as possible (before things time out) to answer. If something arrives while the connection is idling it can receive it directly, if something arrives between long-polling requests it is queued until a request comes in.
If you can make TCP connections, then just set up a connection and let it stay idle. I have icq and irc applications that essentially just sit there waiting for the server to send it something.
You should see PushRegistry feature where you can send out an SMS to a specific number have the application started when the phone receives that SMS and then make the required HTTP connection or whatever. However, the downside of it is that you might have to sign the application to have it working on devices and you also need an SMS aggregator like SMSLib or Kannel
You can open socket connection and implement "Hide" (or "Minimize") functionality in your app. Call this to hide:
Display.getDisplay(MyMIDlet.instance).setCurrent(null);
Listen to the server in a loop, and if you receive some message, popup the applicaion by calling this from canvas:
Display.getDisplay(MyMIDlet.instance).setCurrent(this);
But it dosen't work on all devices.
Socket push are supported by j2me. But it could work only if your server could deliver data to your mobile phone. Most likely that operator gateway don't allow to do this.
Maybe it would be possible if your mobile has static external IP address - some operators could provide this for $$.