Re: Implementing a network protocol

On Thu, 27 Mar 2008 02:40:31 -0700 (PDT), Erik wrote:
The protocol itself will mostly consist of alternating question/
answer, but a client can send a disconnect message at any time, so
the client must be able to send and receive messages at any time.

If your protocol is strictly request-response with the single
exception of the disconnect message, then I would say that you can
ignore that one exception and design for the other, simpler cases. I
presume that you don't need to stop what you're doing to reply to the
disconnect, or even reply at all.

Also, what do you gain by having a special disconnect message? Both
client and server need to gracefully handle any unexpected disconnect
by the remote party anyway, even if it isn't preceded by a cheery
"goodbye". As soon as you attempt to read from or write to the socket
you'll discover that the remote has closed.

/gordon

--
.

Relevant Pages

  • Re: Implementing a network protocol
    ... answer, but a client can send a disconnect message at any time, so ... the client must be able to send and receive messages at any time. ... by the remote party anyway, even if it isn't preceded by a cheery ... You disconnect the socket but you can resume the client/server "discussion" on a new socket, but this means that this means that client and the server must implement a saveStateand resumeFromStatekind of logic... ...
    (comp.lang.java.programmer)
  • Re: Implementing a network protocol
    ... answer, but a client can send a disconnect message at any time, so ... the client must be able to send and receive messages at any time. ... ignore that one exception and design for the other, ... by the remote party anyway, even if it isn't preceded by a cheery ...
    (comp.lang.java.programmer)