Re: Choosing a client/server protocol

The server will be sending seemingly random-length bodies of text ranging from 5 characters to 1000-2000 characters in length. The clients will be sending in short lines for the most part, possibly larger bodies less frequently.

Might you be able to provide a reason or two as to why the fixed-length method would not be a good route to go? All communication will be a simple "this command" to handle "this data". I'd like to hear why it's a bad idea (or maybe just not the best).

TVSET's link in his response contains examples of the SMTP, IMAP, and POP3 protocols. I'm in the process of combing through the pages right now.

If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, please reply to this node or /msg me to inform me as to what is wrong with the post, so that I may update the node to the best of my ability.

Comment on Re: Choosing a client/server protocol

Replies are listed 'Best First'.
Re: Re: Choosing a client/server protocol by sauoq (Abbot) on Jul 07, 2003 at 23:14 UTC
Might you be able to provide a reason or two as to why the fixed-length method would not be a good route to go? All communication will be a simple "this command" to handle "this data". I'd like to hear why it's a bad idea (or maybe just not the best). Well, I was looking at it in the context of your example which seems to want to support direct access via telnet. Typing `09text_data0016example_password` seemed painful. I see I may have misread your intentions though. Just the same, specifying a fixed number of digits for the data size does seem brittle. If you ever find yourself needing to support chunks of data with more 10,000 or more characters you'll have to change a bunch of code. Other than that, it's really fine. It makes a tradeoff between the need to know the length of your data before you send it and the need to process the stream looking for delimiters. I'd really suggest trying to use an existing protocol if possible though. It could save you a lot of time by allowing you to use modules which are already available and have been extensively used and tested. -sauoq "My two cents aren't worth a dime.";	[reply]

Replies are listed 'Best First'.

Re: Re: Choosing a client/server protocol
by sauoq (Abbot) on Jul 07, 2003 at 23:14 UTC

Might you be able to provide a reason or two as to why the fixed-length method would not be a good route to go? All communication will be a simple "this command" to handle "this data". I'd like to hear why it's a bad idea (or maybe just not the best).

Well, I was looking at it in the context of your example which seems to want to support direct access via telnet. Typing 09text_data0016example_password seemed painful. I see I may have misread your intentions though.

Just the same, specifying a fixed number of digits for the data size does seem brittle. If you ever find yourself needing to support chunks of data with more 10,000 or more characters you'll have to change a bunch of code.

Other than that, it's really fine. It makes a tradeoff between the need to know the length of your data before you send it and the need to process the stream looking for delimiters.

I'd really suggest trying to use an existing protocol if possible though. It could save you a lot of time by allowing you to use modules which are already available and have been extensively used and tested.

-sauoq
"My two cents aren't worth a dime.";

[reply]