Just my 2 cents.

Leonid Mamtchenkov aka TVSET

The BEEP protocol uses it, and Marshall Rose says it is the most efficient method. See RFC3117: On the Design of Application Protocols (a good read).

Bernstein uses strings preceded by an delimited decimal length string in netstrings.

Note that there are really several issues here which can be handled together or separately. First is the reader knowing how much data to expect in the next "chunk". Second, delimiting logical strings within a transaction. Third, knowing whose turn it is to talk. In your example, it appears issues one and two are combined, and the third issue is just handled by the client and server programs just knowing (e.g.) how many strings to accept. For simple protocols that's okay, but it's better to have some general method to indicate line turnaround (e.g. SMTP/POP error messages continue with a "-" as the fourth character in a line to indicate that there's more to come, and use a "." on a line by itself to indicate the end of a message.

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.";

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.

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.";

#Send and receive a simple string 
$client->send("HELLO THERE") || die "ERROR SENDING: $@\n";
$reply = $client->receive() || die "ERROR RECEIVING: $@\n";
print "$reply\n";

#Send and receive complex objects/strings/arrays/hashes by reference 
#%hash = ("to be or" => "not to be" , "just another" => "perl hacker")
+; 
#$client->send(\%hash) || die "ERROR SENDING: $@\n"; 
#$reply = $client->receive() || die "ERROR RECEIVING: $@\n"; 
#foreach (keys %{$reply}) { 
#print "Received key: $_ = $reply->{$_}\n"; 
#} 

#Send and receive large binary data 
#for (1..4096) { 
#for (0..255) { 
#$largedata .= chr($_); 
#} 
#} 
#$client->send($largedata) || die "ERROR SENDING: $@\n"; 
#$reply = $client->receive() || die "ERROR RECEIVING: $@\n"; 

#$client->close();
[download]