Re: Implementing a network protocol
- From: CHAFIK Wassime <wassimec@xxxxxxxx>
- Date: Thu, 27 Mar 2008 19:19:41 +0100
On 27 mrt, 10:33, Gordon Beaton <n....@xxxxxxxxx> wrote:hiOn Thu, 27 Mar 2008 02:40:31 -0700 (PDT), Erik wrote:The protocol itself will mostly consist of alternating question/If your protocol is strictly request-response with the single
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.
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.
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
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...:-)