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