in reply to Choosing a client/server protocol

It might help to know what the nature of the data is that you wish to exchange with this protocol...

Going the XML route might indeed be a good idea. Can you leverage XML RPC or SOAP?

Your second idea is likely to be much more error prone and brittle. I wouldn't go that route. You might consider something similar to it though, especially if you anticipate the need (for debugging or otherwise) to connect to your server with, say, telnet and communicate in the protocol by hand. You might take a look at SMTP, for example.

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

Replies are listed 'Best First'.
Re: Choosing a client/server protocol
by Coruscate (Sexton) on Jul 07, 2003 at 20:47 UTC

    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.

[reply]
      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]

In Section Seekers of Perl Wisdom