Re: Implementing a network protocol

Erik wrote:
On 27 mrt, 10:33, Gordon Beaton <n....@xxxxxxxxx> wrote:
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

--

Actually I not only a disconnect message can be send at any time, but
for example also a pause and resume message. How do you handle these
kind
of messages?

Erik
hi
IMHO for the resuming and pausing part of the protocol, i think of the way FTP does it. 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 saveState() and resumeFromState() kind of logic...
hope that it helps
sorry for my english...:-)
.

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. ... 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)
  • 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)