ockam
ockam copied to clipboard
build-trust
Rust - UDP Transport
Ockam Transports provide Ockam Routing support over various communication protocols. The get-started guide has an introductory example of how the TCP transport can be used.
A UDP transport would be a great addition, and simple to implement for std environments.
This should live in a crate called ockam_transport_udp along with the other ockam crates in the same path.
TCP Transport provides a good example of a transport implementation.
If you would like someone to help / mentor / pair program with you as you work on your first Ockam issue, please leave a comment on this discussion.
@0x00A5 that would be awesome, thank you. Let us know if you have questions.
@mrinalwadhwa Sorry for taking so long to start looking into this. I just read the tcp and websocket transport crates and have some questions about the UDP transport implementation.
- Both tcp and ws transports use
{protocol}ListenProcessorto accept incoming connections and then register a worker pair which owns the read and write half of the steam. For connectionless protocol, such as UDP, do we want to use a similar pattern? - It seems
TransportMessagehas a dynamic size which could exceeds the max size of an UDP datagram. Thus, I am planning to useUdpFramedand implement a custom codec that encode and decode similarly to what the TCP transport does inprepare_message. Does this sound about right?
Hey @0x00A5, surprised to see you here, it's been a while, I hope you're doing well 😄.
Anyway, in some sense we'd like consistency with the Elixir implementation of this (see https://github.com/ockam-network/ockam/blob/develop/implementations/elixir/ockam/ockam/lib/ockam/transport/udp.ex and https://github.com/ockam-network/ockam/tree/develop/implementations/elixir/ockam/ockam/lib/ockam/transport/udp).
That said, as far as I can tell, it actually does not handle this problem, so a simple option would be not to handle it either and emit an error, although long-term we'd want something better. Honestly, given that the max size of a datagram is pretty large this seems reasonable -- certainly if you'd like to implement framing that would be pretty cool! But, possibly should be done in a subsequent PR.
As a note, another point of reference here is the BLE transport (which is still somewhat experimental at the moment). It actually caps the max size of an message and caps it to a fairly low value. That said, this cap is larger than the maximum size we can fit in a single BLE packet, and as a result, shorter messages are buffered. I don't quite know how we perform framing (the expert here would be @antoinevg), but it's possible that given the experimental nature of that code, we just kind of hope for the best (it's also possible the protocol handles it for us in a way).
So, overall I think there are a few options. I would say to start, given that the cap for UDB is (I believe) around 64k, it would probably be best to just error on an attempt to send an overly large message through, and leave framing for future work. @mrinalwadhwa might have more concrete thoughts here, though.
