UDP

UDP is a connectionless protocol found one layer above IP. It performs no handshake, no
acknowledgement of any king and no error detection, which makes it a very simple but unreliable
protocol.
RFC User Datagram Protocol
TCP
TCP is a connection-oriented procotol, which makes it highly reliable. Its main feature is that all the
packets transmitted must receive an acknowledgement that they were received correctly. Because TCP
is found above IP, IP is in charge of fragmentation and reassembly of the TCP packets: it also carries the
TCP packets across multiple networks.
https://www.ietf.org/rfc/rfc768.txt
To establish the connection a three-way handshake must be performed. Each device must send SYN and
receive an ACK to/from the other device.
RFC 793 Transmission Control Protocol https://tools.ietf.org/html/rfc793
TLS
TLS provides a secure communication over TCP, which makes it a reliable transport protocol.
It is composed of two layers:
-

TLS Record Protocol in charge of connection security. It makes the connection reliable by
checking the integrity of the messages using a keyed MAC and it also uses symmetric data
encryption.
TLS Handshake Protocol in charge of performing the client-server authentication by negotiating
the terms of the connection

The main advantage of TLS is that it allows other higher-level protocols to layer on top of it.
RFC 2246 Transport Layer Security 1.0
RFC 4346 Transport Layer Security 1.1
RFC 5246 Transport Layer Security 1.2
DTLS
DTLS is based on the Transport Layer Security (TLS) protocol. It provides a secure communication
without the need of a connection channel like TLS. The main differences between TLS and DTLS are as
follows:

TLS is stream-based (TCP), whereas DTLS is datagram-based (UDP)

Because UDP is unreliable, DTLS has to deal with packet loss
TCP provides a bidirectional tunnel that allows the packets to arrive in the same order as they
were sent. In datagram protocols, the packets can arrive at any order or they can be duplicated,
therefore DTLS deals with packet ordering by adding an additional sequence number to control
the order and to check if the packet was duplicated or not. It also makes use of a windows
mechanism that allows to store unordered packets until the complete sequence has arrived or it
is determined that the sequence was lost. Such handling of the given windows and timeout
parameters need to be configured properly in order to avoid any possible attacks.
To avoid DoS attacks, DTLS introduces the use of a cookie which allows to control the amount of
times that a source address sends a ClientHello to request a handshake.

The supported DTLS implementation contains cookie handling. As we can observe in the next figure, the
difference between a DTLS implementation with and without cookie exchange is after the first
ClientHello was sent. The server receives it and it acknowledges the client that the request was received
with a HelloVerifyRequest. This HelloVerifyRequest contains a stateless cookie. Afterwards, the client
will retransmit the ClientHello message adding the received cookie from the server. Once the server
receives this new ClientHello, the handshake will proceed.
For more additional information regarding DTLS.
RFC 6347 Datagram Transport Layer Security Version 1.2 https://tools.ietf.org/html/rfc6347
RFC 4347 Datagram Transport Layer Security https://tools.ietf.org/html/rfc4347

https://github.com/zeromq/czmq/blob/master/src/zbeacon.c
http://stackoverflow.com/questions/12630676/zeromq-broadcast-to-entire-network
http://zguide.zeromq.org/c:udpping2
http://grokbase.com/t/zeromq/zeromq-dev/1357rs0ct1/zmq-udp-im-here-broadcast