Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Good IPC Message Protocols?

by BrowserUk (Patriarch)
on Jan 30, 2009 at 02:26 UTC ( [id://740091]=note: print w/replies, xml ) Need Help??


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 firstname.lastname@someplace.com and many others.

  • The time you spend encoding and decoding.
Is there a better way to do this?
  1. If you are looking to hide your stuff from the bad guys, use proper encryption.
  2. 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.

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.

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://740091]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (8)
As of 2024-04-23 10:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found