Re: Good IPC Message Protocols?

Does this make sense?

Not really. The only differences between the encoded version and the unencoded version are:

The characters you used as delimiters;
'=' & "\n" versus ':' & "\n".
The character values you can transmit.
With the encoded version being far more restrictive, without really making anything more secure. It could also come back to bite you if you suddenly have the need to deal with data elements that contain punctuation.
Eg c:\... or firstname.lastname@someplace.com and many others.
The time you spend encoding and decoding.

Is there a better way to do this?

If you are looking to hide your stuff from the bad guys, use proper encryption.
If you're looking for a reliable protocol, prefix your transmissions with a count value.
This has many advantages. Being able to read a set number of bytes to get the count that tells you how many bytes to wait for on the next read can be a real boon to timelyness.
Look at the n/a* pack template for one way to do that.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re: Good IPC Message Protocols? Select or Download Code

Replies are listed 'Best First'.
Re^2: Good IPC Message Protocols? by hobbs (Monk) on Jan 30, 2009 at 23:48 UTC
I think you missed the part where the keys and values are base64'd as part of the serialization. Which actually increases the things that can be transmitted easily, and improves robustness because the payload can't be confused with the framing. So while I agree with the principle of not reinventing wheels, especially when security is on the line, pileofrogs isn't as misguided as all that.	[reply]
Re^3: Good IPC Message Protocols? by BrowserUk (Patriarch) on Jan 31, 2009 at 00:49 UTC
Now you point it out, you're right++. I got hung up on the "64 characters" bit and completely forgot that the input to the encoding process can contain any byte values. That said, I still much prefer length prefixing (via pack 'n/a*' etc.) which also allows the data packet to contain all byte values, but has the added advantages of: 4(or 2 or 1)-bytes/per packet transmission overhead rather than 37%. Negligible encoding/decoding overhead. The ability to read for just what is required rather than rely on buffering and buffer management. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]