January 19, 2017 - 12:14pm, 10168 views
How to check state of a SocketConnection with Java API?
After a SocketConnection opened, if other party closes the socket or if it drops due to network conditions how to be aware of that? Is there a notification to catch?
This might be quite problematic - without writing or reading attempt it might not be possible to discover that the socket was closed by the other party. Reading or writing attempts could also take some significant time to discover closed socket especially if it was closed non-gracefully.
So if the socket ***** to be open for a long time without data transfer then some custom keep-alive with timeout mechanism could be helpful on the application layer to be able to discover the other party disconnection as fast as possible.
If you would like to track the bearer state changes or errors, for example if you have a server connection open on the nodule and want to be sure that there was any disconnection of the bearer initiated by the network and the socket is still available form the outside, you could use the BearerControl class with BearerControlListener or BearerControlListenerEx interfaces to achieve that.
Thanks for the answer.
Write or read attemp to discover if socket is alive does not seem a proper way. Writing cannot be done because it effects the remote side. It can disrupt the remote party. Read attempt may be used but it seems to me a kind of workaround.
When using at interface, there is a URC named ^SIS. It is explained in section 10.14 of at command manual. As far as I understand, this URC is sent when a problem occured regarding an internet service.
At java side, it could be useful a listener implementation of this URC for example. Isn't there a Listener for this purpose?
Internet services over AT interface is a different story. This URC is only related to connections established with AT commands. You can't use both Java and AT commands for the same connections.
This problem with detecting a broken connection is rather related to the TCP specifics than particular interface (AT or Java).
Probably the only reliable way to detect a broken connection might be to write to it. After enough writes to a broken connection, TCP will have done enough retries and timeouts to know that it's broken.
The good way could be to implement some keep-alive mechanism with timeouts on the application layer. If the keep-alive packet is not bounced back in a reasonable timeout the connection may be assumed as broken. But if you already have a fixed communication protocol this may not be possible.
I wrote the ^SIS URC to state that service state (TCP Socket here) can be monitored by the module. If it can be monitored, state changes can be sent to up layer application protocol. Such a mechanism could be implemented at java side. As far as I understand, some implementations lacks at java side whereas it is iplemented at at-interface side.
Keep alive mechanism is a good way to check the connection state, but unfortunately we are using a fixed protocole at application level.
There is a KEEPALIVE parameter for SocketConnection interface. Can I use it for this purpose?
Java network interface's functionality differs from the AT interface functionality of course. To be sure that in this particular case in the same situation there is a notification about lost connection while there is nothing while Java is used you would need to do a comparison test. The problem with detection of broken connections is more general and you can find such problems on many internet forums. However we cannot exclude that it might happen that in some cases the behavior of AT interface would be different.
There is indeed a KEEPALIVE socket option parameter in javax.microedition.io.SocketConnection interface API but this mechanism is not available in our implementation and generally other platforms does not always support it also.
At this point, it seems there are 2 ways to detect if a tcp socket is alive or broken.
1. Using outputstream.write (It sends data if alive, throws IOException if broken)
2. Using keep alive messages at application level.
One more question. Not directly related to this issue. When using ServerSocketConnection, is it possible to reject a client connection request without accepting it first? Suppose, I want to allow 2 client connection at the same time, if a third one tries to connect, I will reject it automatically.
I'd say that the keepalive could be the fastest way because you could fix some own timeout to decide that the connection is broken. But if you generally open the connection just for communication so if there is no reply from the other party in the reasonable time you could also assume the connection as broken. That would not work if you would like to keep the connection open for a longer period for sporadic transmissions. Reading and writing on the socket could take time due to all the TCP retransmissions and timeouts.
As the acceptAndOpen() method of the ServerSocketConnection blocks until there is a new connection and returns this new connection I can't see a straight way of rejecting the incoming connection. You could close such new connection without opening the streams or not call acceptAndOpen() when there are already 2 connections open. But in the second case the client would probably get the information that the server is not reachable which could be misleading.
Thank you very much.
What is the limit for SocketConnection ***** which BGS5 module supports?
if ServerSocketConnection always accepts and open new connection requests, after how many tcp sessions it cannot accept?
Or if module connects to different servers at the same time, maximum how many socket connections it can open to remote servers?
There's no fixed limit described in the documentation. It's rather a matter of overall performance. There is only a note about the time needed for the socket connection to be cleaned by the garbage collector: "If a user rapidly closes and opens TCP/IP connections (e.g. SocketConnection, HTTPConnection), a ConnectionNotFoundException reading "No buffer space available" may be thrown, explaining that all TCP/IP socket resources are exhausted. In the worst case, opening further TCP/IP connections is locked for up to 60 seconds."
Do you think of any particular solution that would require a big amount of open sockets?
© 2013-2022 THALES DIS AIS Deutschland GmbH