I have an Android app that needs to let multiple socket communication. here is the basic work around:
My application( Say Server) is a service which will run as a sever socket. other application can connect to it on predefined port. There can be a multiple connection say client 1, client 2.
So when client 1 send hello, server will process this and should send reply back to client 1.
Currently I am able to connect server for client 1 and client 2. I have created input , output buffer for same. But I am not sure how server will detect from which it has received "hello".
I was referring this example , but still not clear how to use that solution:
How can I handle multiple clients connected to a server using sockets?
The ServerSocket.accept() call, which creates a connection on the server side, returns a socket. Each call to accept will create a new Socket for communication with that particular client. So whatever Socket sends you input is the Socket that needs a response.
First I tried to check thread ID whenever A new connection is established, but it was same as it is Server Id.
Whenever the request received from a specific thread it has a ID. you will get it by
Thread.currentThread().getId();
This is unique for each client. So I save this and use this to detect to which thread I should reply back.
Thanks all for your support.
Related
As shown above, I have a socket server (in UDP) running on my Raspberry Pi. I also have a socket client running on my Android app.
Currently, the app client always initiates communication and the RasPi always responds.
The RasPi can even initiate communication and send socket packet to anyone if it knows the IP address.
The problem is my app has to wait for a Thread to receive data forever (basically polling). Like below:
uniSocket.receive(receivePacket);
Should both RasPi and Android run clients and servers or is there something like Datagram_Socket_Callback or some asynchronous method to receive and send data.
The receive call will block until there is something to receive. That isn't polling; it's just waiting. It could wait in the receive call for days at a time if there's no notification to be sent. And that occupies no more resources than a server threading running on the android side (waiting for a connection) would occupy.
You probably will need some kind of periodic keep-alive to ensure the other side hasn't disappeared. You can do that yourself at the application layer, or TCP provides a keep-alive mechanism you can activate with setsockopt for this purpose.
In other words, create a socket, enable TCP keep-alives, send an "I'm waiting for notifications" message to the server, and then call receive to wait. The server then maintains a list of client connections waiting for notifications, and can then send data through a connection whenever there is something to be sent.
For your normal client-server communications, you could use the same socket, but it might be more complicated to synchronize that way, so alternatively, you could just create another socket in parallel.
I don't know a lot about android/app development but obviously your client will need to be prepared to re-create the connection if it's broken. I can think of many reasons why that might happen in normal usage. For example, the initial connection might be created from an IP address obtained on your home network. Then you walk out of your house and lose that IP address. You may now need to recreate the connection with a different IP address on the cell network (or the wifi at the coffee shop or whatever). If the phone goes into Airplane mode, you might lose all IP addresses for a time.
I'm sure it's possible to create a server that runs in android as well, but then you have the problem of the RPi needing to know the android's IP address which may change frequently. I would say it's better to keep the client role on the android side.
I'm using node.js and WebSocket-Node to build a simple chat websocket server.
The client is an Android app.
The server have to communicate with the clients in two way:
websocket message when the client is connected (app open in foreground)
Push notification using Google GCM else
But there is a little problem that i need to figure out..
When the client is connected to the server and the internet connection drops, the server is not notified about that because the client did not send the closing frame.. So for like 10 seconds, the server thinks that the connection is still alive.
If in those 10 seconds the server send the message over the socket.. the message can never reach the client.
I need to detect when the connection is closed, or another way to send the message using GCM when the connection it's closed.
Is there a way?
From the side of the server an unclean disconnect (no disconnect messages sent) is indistinguishable from a very slow connection.
What you need to do is have some sort of heartbeat. WebSockets has pings on the protocol level for this. If your library exposes this, then set the ping to a delay you are willing to accept, and add a handler for when this fails/doesn't complete after a timeout.
Answering my own question, because: It is not possibile, and I have found another better way to handle my specific case.
When the server send a message to the client, the client reply to the server, to let the server know that the message has been delivered to the client.
If the server do not receive the response from the client after a timeout, the connection is considered closed.
Proceed to send the message over GCM (or store it to be sent again when the client reconnect).
In my app I have functionality like server-side some updates is done. When every updates is happen in server-side I need send those data to app without using push notifications.
Take example of Ola Cabs. Whenever user open the app it will show all cabs information nearby user. At the same time it will send data to the cab drivers telling that a customer needs cab like that. How to implement this functionality with out push notifications?
By using this things we can do that
1) push notifications
2) explicitly calling the server from client with given time (its bad process)
Is there any solution other than these things?
How could client get response without request? Please read OSI Model and TCP/IP protocol. Because server cannot send response without request. So client have to initialize request first and wait for response from server.
If you want to do same thing without GCM then i will suggest you to use socket programming. In that you can be open client port continuously to receive messages (response) without any request initiated by client.
But again, continuously opening socket port, drains device batteries, and this is bad process. In case of GCM it only open port for while when client send request to server and close after response. So I suggest you to use GCM but still you have problem with GCM then use socket programming like chat applications (e.g WhatsApp)
I'm working for an App Android and I need my phone was always connected to my server MQTT...
But my phone can lost his connection(Tel :[FIN;ACK]; Serv:[FIN;ACK];Tel:[ACK]); after that, when he send a [SYN] message for connect it to the server MQTT, the serveur send an [RST,ACK]... And this while the service of my app is in activity.
In my case , i MUST to re-launch my server if i want my phone can be reconnect, but, i can't reboot my server (multi-phone possible, and i need real-time performence).
There is there a possibility to connect my phone without reboot my server?
Thank's for time.
Best regard
Guillaume
I think your problem is similar to the one I had. The connection was half closed. See http://www.codeproject.com/Articles/37490/Detection-of-Half-Open-Dropped-TCP-IP-Socket-Conne for details.
The way I solved this was to i) add keep alive msgs, every 5 secs. from the phone to the server and ii) have the server close the connection if there was no incomming data for 15sec. See http://www.forward.com.au/pfod/CheapWifiShield/index.html and www.pfod.com.au
MQTT includes keepAlives (PING request msgs) so you only need to modify your client to specify a short keepAlive interval
see http://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over
to have the MQTT server to more quickly close the connection once it stops getting your data or keepAlive msgs.
Although the above link states
"The broker will close the previous connection to the same client (determined by the same client identifier) and establishes the connection with the newly connected client. This behavior makes sure that half-open connection won’t stand in the way of a new connection establishment of the same client."
So you should not be having this problem at all !!!
I am working on Android project which communicates over TCP/IP. Communication works on specific protocol - this protocol is message oriented.
android device sends message to server via socket
server sends answer message to android device
It is not problem but I have a few parlous questions.
I don't have any idea how to solve connection interrupts (wifi, edge, change wifi to edge over open socket, ...) and connection timeouts? If android device sends 1 message and in this moment are connection problems - then android device sends different message (other request) - it is guaranteed that answers will be delivered in correct sequence?
I tried set timeout for socket object but it didn't work. I dont know why but if I set timeout to 5 seconds and I turned off the server before I sent message - it took more than 5 second before she came exciption.
I didn't found any articles on internet about this problems.
Thank you very much.
For TCP sockets the way you can get timeouts is by using select() or poll(),in Android you have to use SocketChannel() (java.nio) class to deal with non-blocking sockets. They both can query a socket for a specific period (10 or 20 seconds for example) and can tell you if it is writeable (you can use send()) or readable (there is data to be read recv()). Also the select() command will tell you if the socket has an error, most probably a broken connection. When you get such an error (except an interrupted signal, this one should be ignored and reissue the select), all you can do is close the socket and reopen a new one with the server, there is no way, as far as I know, to recover a broken connection, although, if you've implemented in the protocol, you can resume where you left off when the socket was broken. I don't know how you've implemented the protocol, but most of them will required a positive ACK (acknowledge) from the receiver before going on with another message. Also, when establishing a connection the client should specified if it a brand new connection or a broken one and act accordingly.
The idea is:
The sender sends a header specifying the command to process and the length of the data it's going to send after the header, the receiver receives the header and the data, once it process it, it sends a response ACK packet to the sender with a positive value to acknowledge the message, optionally with some data in case it's necessary. If after a reasonable period of time you don't receive the ACK packet then you may resend the same data again until you receive the positive ACK.
There could be the situation where the client sends a message, the server receives it and processes it, but when the server sends the positive ACK packet the connections breaks and the client never receives the packet, so it will resend the same message again once the connections is reestablished. To avoid this situation, it's necessary to send a message ID (an int which increments for every message sent) in the header to identity it.
I know it sounds difficult and it's in fact. If the connection is on the same network (intranet) it works nicely but, when the communication is on the internet, you may face a lot of problems and situations which you can't control, so it's necessary a well defined protocol where you can recover from broken connections and the transactions/messages won't be duplicated.