[request] UDP transport

[liamstask]

breaking out as distinct from #107

Would be great to make unreliable datagrams available as a transport option.

[gdamore]

Thanks, I'll keep this on the table. Its not a strong priority for me at the present, but definitely something it would be nice to have.

[liamstask]

looking at this a bit - main uncertainty has to do with the fact that the existing platform udp code does not correspond to the ep/pipe api in the way that, say, the tcp platform code does.

do you think it would make sense to adjust the udp platform code to implement nni_plat_udp_ep_* and nni_plat_udp_pipe_*?

if that were in place, it looks like it would not be too bad to create the udp transport as follows:

static nni_tran_pipe nni_udp_pipe_ops = {
	.p_fini    = nni_udp_pipe_fini,
	.p_start   = nni_udp_pipe_start,
	.p_send    = nni_udp_pipe_send,
	.p_recv    = nni_udp_pipe_recv,
	.p_close   = nni_udp_pipe_close,
	.p_peer    = nni_udp_pipe_peer,
	.p_options = nni_udp_pipe_options,
};

static nni_tran_ep nni_udp_ep_ops = {
	.ep_init    = nni_udp_ep_init,
	.ep_fini    = nni_udp_ep_fini,
	.ep_connect = NULL,
	.ep_bind    = nni_udp_ep_bind,
	.ep_accept  = NULL,
	.ep_close   = nni_udp_ep_close,
	.ep_options = nni_udp_ep_options,
};

static nni_tran nni_udp_tran = {
	.tran_version = NNI_TRANSPORT_VERSION,
	.tran_scheme  = "udp",
	.tran_ep      = &nni_udp_ep_ops,
	.tran_pipe    = &nni_udp_pipe_ops,
	.tran_init    = nni_udp_tran_init,
	.tran_fini    = nni_udp_tran_fini,
};

does that make sense? do you have another approach in mind?

[gdamore]

I've been thinking about the semantic for UDP (may have a commercial customer that needs it), stay tuned.

[itsermo]

any updates on this?

i'm looking at using nanomsg for a project, but one of my requirements is to have a UDP-based option when i don't care about reliability, but want to communicate with computers across networked equipment in a lowest-latency fashion

[KenthJohan]

Looking forward of UDP integration. In many cases I would rather have UDP drop packages than getting late data from TCP.
UDP is more reliable as regards on time in low latency real time systems.

[jeinstei]

Ditto on this -- I've been unable to easily find good UDP protocols, and it really would be nice to have something that isn't custom every time for embedded real-time applications.

[devlpr]

Same. I'd really like to use nng but I cannot because we really need UDP.

[mjmvisser]

I'm honestly shocked UDP isn't supported out-of-the-box. It's the standard for realtime protocols that care more about latency than reliability.

Edit: so it looks like low-level UDP platform support is already in place. @gdamore do you have opinions on the public API? I'm tempted to just go ahead and implement it. Digging into it, it seems it's just adding "udp4" and "udp6" schemes (also "dtls" for datagram tls?) and implementing dialer/listener., so there's no change to any public API.

[esemeniuc]

would love to see udp added

[gdamore]

I have a draft implementation (very rough) and a spec. Initially this is just unicast, but I intend to add mesh support.

[gdamore]

For NNG 2.0 (development branch, see dev2.0) I have a PR that adds this -- see #168 - although be advised its a work in progress. There is also a draft specification at nanomsg/rfcs#1