socket.close no really resulting in disconnect...

[b4a2z]

Socket.close not really resulting in disconnect...

Hello,
I have used the tutorials and forum examples to play around with Networking, and like others, I've noticed that socket.close and/or socketio.close does not kill the connection to my server (...which is running on a PC). The only way to receive a FD_CLOSE message from WinSock is to kill the android app, and I believe I've read a post that describes the same experience. I don't think a solution was presented, but I did find an article (Tal's tech recipes » Closing Android socket and quoted below) that talks about this issue in Java, and the solution is to call Socket.shutdownInput. Can this be implemented in Basic4Android? What are your thoughts on the subject, and does it represent a solution?

"Closing Android socket

Assume we have a Socket that is connected to a server. Usually, we will use a secondary thread to read from the socket in a blocking connection.

If the user want to terminate the connection, in Java, we can call socket.close(). But not in Android (well, we can, but it will do nothing). While the thread is still alive and waiting, close() will not be executed and the connection will remain active. So, what can be done?

One way is to terminate the thread. This is obviously not a very good way, and denied the thread from executing its final code correctly.

The second and the right one, is simply to call Socket.shutdownInput() method. This will create a disconnection for the waiting thread, the thread will die according to plan and your application will run just fine!"

 

[mc73]

What I do is sending a 'closeSocket' command to the server. After all, usually it's the server that opens the listening socket, so why not letting it to close?
Here's my notices: if we close the socket this way, whenever we try reconnecting, we can get back the free socket. If we didn't close this socket, the service gives us a new socket. This makes me suppose that indeed freeing the socket at the server side, leads to a real close.
Anyway, earlier I used to close the socket at the client's side. This was leading to a aStreams_terminated at the server's side, thus, we could easily close the socket there. Later I've noticed (still don't know whether it's some sort of bug, or it was a fault in my code) that not every time we got the stream termination event. This cycled me back to my first notice.
Another approach, one suggested by Erel, is to get to use a heartbeat mechanism. This is cool, but mostly it has to do with ability or lack of communication, at least so I see it.
To me, freeing up the socket at the server side, tends to work without problems, but certainly if I notice any misbehavior I will give a feedback immediately.

 

[Erel]

Socket.shutDownInput and shutDownOutput were added to Close method. Will be available in the next update.

 

[mc73]

Socket.shutDownInput and shutDownOutput were added to Close method. Will be available in the next update.

Ideally, this shutDown will fire the streams terminated event at the server's side?

By the way, will the next update contain a fix for the long compile time in debugging mode? I recall you mentioned something in a previous post

 

[Erel]

Ideally, this shutDown will fire the streams terminated event at the server's side?

Either Terminated or Error events will fire.

By the way, will the next update contain a fix for the long compile time in debugging mode? I recall you mentioned something in a previous post

No. This will be in the version after 2.30.

 

[b4a2z]

While we're on the subject of Networking, and since I'm just starting out with it, is there a proper way to handle a username and password between my Android client and my PC server? This wasn't mentioned in the simple Network tutorial, so I'm not sure how to proceed. Suggestions would be greatly appreciated.

 

[mc73]

Using the php tutorial? If so, you can post userName and password, then let the php decide if they are correct and proceed. Except if you mean something else, like for e.g. the security involved in sending data OTA.