Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Saying "goodbye" correctly with sockets  RSS feed

 
Pavel Kazlou
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.
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.
 
Colm Dickson
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi.

In any smalll projects I've tried like this , my server has remained up and waiting for client connections
until the disconnect message has been received from the client





and the client should also do something similar on its side

 
Rob Spoor
Sheriff
Posts: 21047
85
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never use != and == for String comparison - always use equals and !equals.
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should also read this: Don't println to a Socket - I suspect you might be falling into that trap.
 
Pavel Kazlou
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Colm Dickson
Ranch Hand
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Michael Parmeley
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Pavel Kazlou
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Michael. This is the thing I was looking for =)
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!