From: David Schwartz on
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
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.