in reply to 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 email@example.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.