[Bathtor]

It's time to stop throwing exceptions when someone selects UDP as transport protocol. This PR provides UDP support and a few other improvements and updated dependencies on the networking side of things.

Status

This is currently a preview, that I'm looking for feedback on. In particular:

• Is this using the buffers in the most sensible way? UDP datagrams are delivered in an all-or-nothing manner, so all the work we do for framing in TCP is technically unnecessary here, but so far I'm just re-using those classes for simplicity. So the question is: Can and should we do better?
• Sender protocol API: Currently Kompact always inserts a TCP as a sender address for any message. I think it would be nice to default to using the same protocol on the sender as for the destination, but we need to provide users a way to override this behaviour if desired. What would be a good API for that?

Related Issues

This fixes #48

[adamhass]

Regarding UDP readingt:
The error return on line udp_state.rs:113 should be matched around network_thread.rs:230 and result in a buffer_swap, I think it should be done by simply returning Ok((received_bytes, IOReturn::SwapBuffer)) instead of the error on udp_state.rs:113.

Regarding Sender Protocol API:
I believe an optional config parameter called "sender address" in the network config would be good enough?

[Bathtor]

Regarding UDP readingt:
The error return on line udp_state.rs:113 should be matched around network_thread.rs:230 and result in a buffer_swap, I think it should be done by simply returning Ok((received_bytes, IOReturn::SwapBuffer)) instead of the error on udp_state.rs:113.

Done. Doesn't answer the question about framing, though.

Regarding Sender Protocol API:
I believe an optional config parameter called "sender address" in the network config would be good enough?

I don't think so. If someone wants to change that behaviour, they probably want to do that on a per-message basis. My suggestion is a separate API where literal ActorPath instance can be supplied which won't have their protocol adjusted. See recent commit on what I was thinking about.

[adamhass]

Done. Doesn't answer the question about framing, though.

I get it now, misunderstood the question. I didn't realize reading from UDP gave stronger guarantees on what was read than TCP. We could theoretically skip framing and do something simpler.

I can conceive of a couple of uses of the framing information for other purposes than just decoding data messages. Primarily, the handshake messages use special frame types, and, I was also planning to let other special network-layer-messages use framing as well, like flow control messages. Not sure if these things are or ever will be relevant to UDP channels...

The FrameHeader is 9 bytes per message, so we're basically just doubling the UDP header information which is 8 bytes by keeping them. I would say that it's worth it to keep the framing for simplicity/uniformity.

I don't think so. If someone wants to change that behaviour, they probably want to do that on a per-message basis. My suggestion is a separate API where literal ActorPath instance can be supplied which won't have their protocol adjusted. See recent commit on what I was thinking about.

Okay I see, that API looks good to me 👍

[Bathtor]

I get it now, misunderstood the question. I didn't realize reading from UDP gave stronger guarantees on what was read than TCP. We could theoretically skip framing and do something simpler.

I can conceive of a couple of uses of the framing information for other purposes than just decoding data messages. Primarily, the handshake messages use special frame types, and, I was also planning to let other special network-layer-messages use framing as well, like flow control messages. Not sure if these things are or ever will be relevant to UDP channels...

The FrameHeader is 9 bytes per message, so we're basically just doubling the UDP header information which is 8 bytes by keeping them. I would say that it's worth it to keep the framing for simplicity/uniformity.

Ok, then I'll merge this as is for now. I still think in the longer term we wanna remove that duplicate information, because for most UDP-based protocols, the bytes available per package a very precious.

But I saw that the frame header size information is very pervasive now, so supporting multiple types of headers is not quite trivial at this point. So it's probably best to leave that for a future PR. I'll make an issue so we don't forget about it