how should a UDP transport look like after the big transport refactor

[zaibon]

In my quest to understand and get my hands dirty with libp2p I was looking to implement a UDP transport.
So I discovered this repo. Now I have a couple of question regarding how an UDP transport should look like now that the big transport refactor has landed.

Using the tcp transport as example I can get my head around pretty much every part of the transport interface.
The only problem I have is regarding the Listen method of the interface. Listen should return a Listener and a Listener should have an Accept method. In the context of UDP, an Accept method doesn't really make sense. So I'm puzzled, should we have another kind of transport for non connected transport type or should I hack around it and implement a UDP listener that would always return the same underlying connection for example

I've started working on some implementation if you already want to have a look at it : https://github.com/zaibon/go-udp-transport

[backkem]

I'm interested in this abstraction as well. Just returning the same connection on Accept doesn't seem like a good idea. It would turn Accept from blocking into non-blocking since there is nothing to wait for.
I see the following options:

• Add a thin protocol above UDP to make it act like a reliable connection, at least some initial connection setup message. However, it would no longer be plain 'UDP' transport.
• Add support for multiformats/go-multiaddr-net PacketConn to libp2p/go-libp2p-transport Listener. However, this means all higher level code should work with both.

CC @Stebalien @lgierth

[Stebalien]

So, the current thinking is to have a separate transport "column" for packet based connections as they're significantly different.

[zaibon]

some discussions around that topic also happened there: libp2p/specs#71 (comment)

[ghost]

So, the current thinking is to have a separate transport "column" for packet based connections as they're significantly different.

I was thinking something else. They aren't all that different: libp2p/specs#71 (comment)

[Stebalien]

We'll have to be careful about prioritizing connections and saying "all connections support literally all features" is a strong statement we'll have to think about. However, that should work.

(Note: we'll probably also want session-less packet connections and those will likely need a separate stack).

[ghost]

We'll have to be careful about prioritizing connections and saying "all connections support literally all features" is a strong statement we'll have to think about. However, that should work.

Yeah agreed that we need to be able to tell the nuances there. For many use cases there'll be one combination of transport/muxers/crypto/etc. that'll fit nicely, and most other combinations will be less than ideal.

Note: we'll probably also want session-less packet connections and those will likely need a separate stack

This is the fire-and-forget messaging that's mainly motivated by DHT latency and throughput right?

[Stebalien]

This is the fire-and-forget messaging that's mainly motivated by DHT latency and throughput right?

Yes.

[bonedaddy]

As far as I can tell there isn't much in the way of UDP transports. I looked at the fork someone made but it doesn't look like it compiles or works. Has there been any success in a UDP transport? I know there is quic but I'm not sure if that would fall under the same "pure udp transport"

[Stebalien]

An actual UDP transport would be be packet/message oriented and would require a new transport stack and some new libp2p interfaces for sending/receiving messages.

[bonedaddy]

Damn that is no short order, but makes sense. thanks.

[zaibon]

I guess we can close this issue then. I'll close it. Fee free to re-open if anything else needs to happen here.