I am implementing Java server-side of socket communication and my colleague is implementing client-side in C language.
When the communication is over my program should sent "disconnect" message to client and then the connection is closed.
I think that the proper sequence of statements is
But my colleague states that such code can lead to message loss: I send "disconnect" message and then immediately close the socket. He states that instead I should send "disconnect" message and keep waiting for some signal indicating that the socket is closed - using reading from input stream or something. This way insures that the client gets "disconnect" message in my colleague's opinion.
Who is right and who is wrong?
I know that TCP guarantees the delivery of packets, waiting for delivery of acknowledgement. So it seems to me that in case of some delay while delivering message, my writer object will wait for the acknowledgement in his flush() method and not allow execution of subsequent statements. Am I right?
This simple question boils my brains, as I'm not sure in my arguments.
Thanks for the replies. println notice is very useful!
But the question is still open =) Maybe I have explained it too bad. So here is another attempt.
The question is: whether my program (in my first post) will wait for "disconnect" bytes to be received by the client in case of some delay while delivering (say, 5 seconds) caused by technical reasons? And is it safe for my server to send "disconnect" and then close the streams and socket or should my server send "disconnect" and then wait for socket close?
As I understand TCP protocol, connection termination initiated by some endpoint (doesn't matter whether it is server or client) is performed by sending FIN packet and waiting for ACK from the other endpoint.
So I wonder if my program will not continue with FIN in case "disconnect" is not delivered yet. In fact "disconnect' may be even lost as we use wireless connection (GPRS). Will my program wait for TCP to insure "disconnect" is delivered?
posted 10 years ago
In my humble opinion ,I would let the server wait for the disconnect message and then close all open streams. It doesn't have to reply to the client as the client is the one that asking for the connection to end and the client should close the connections on its side after it sends the disconnect message.
You can write out to the socket, call flush, and then close the socket and the bytes will get to their destination. You don't have to acknowledge anything at the application level (the protocols take care of that). In fact you don't even need a "disconnect" message in your application's messaging protocol, you could just call disconnect on the socket and the client could detect a peer disconnect.
posted 10 years ago
Thank you, Michael. This is the thing I was looking for =)
It would give a normal human mental abilities to rival mine. To think it is just a tiny ad:
Devious Experiments for a Truly Passive Greenhouse!