Prev: Is there anything special I need to do in order to mix object files created by the C and the C++ compilers?
Next: Need to use streams/buffers, but NOT related to stdin, stdout or to files
From: David Schwartz on 14 Sep 2009 01:08 On Sep 11, 2:30 pm, Ramon F Herrera <ra...(a)conexus.net> wrote: > Thanks, Tom. You confirmed my suspicions. I have always wondered why: > > - IP has an encrypted equivalent: IPsec > - TCP has an encrypted equivalent: SSL > > but there is no such thing as an encrypted UDP. DTLS can thought of as an encrypted UDP. http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security There are, to some extent, good reasons why encrypted datagram protocols aren't popular. Part of it is that most of the advantages of datagram protocols are hard to replicate in a secure protocol. For example, designing a secure broadcast protocol is non-trivial, and would require some other channel to negotiate the keys. Also, unless you implement your own retransmissions and acknowledgements, keeping the encryption context the same on both ends becomes challenging. DS
From: Nick Keighley on 14 Sep 2009 04:42
On 11 Sep, 17:16, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > Ramon F Herrera <ra...(a)conexus.net> writes: <snip> > [the function] read_some: > > Remarks > > The read_some operation may not read all of the requested > number of bytes. > > This being a property your [] library shares with the > underlying system call. TCP does not preserve message boundaries which > implies that, if you need to read 'messages', you must design a > protocol such that the end of a message can be recognized by > inspecting the data recevied so far and continue to call read until > such an end of message indication was seen. Note "end of message indication" could be a count at the beginning of the message. Otherwise you have to do "byte-stuffing" or such like to avoid false positives on EOM detection. |