Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add UDP #326

Open
aratz-lasa opened this issue Oct 15, 2019 · 8 comments · May be fixed by #327
Open

Add UDP #326

aratz-lasa opened this issue Oct 15, 2019 · 8 comments · May be fixed by #327

Comments

@aratz-lasa
Copy link

aratz-lasa commented Oct 15, 2019 •
edited

I have made a first draft for implementing UDP in Transport Layer.
It is supposed to be implemented in Go, however master branch is empty. The only code we can find is in the second branch feat/udp.

So, my approach is not based at all in Go's "implementation". I propose a unified interface for UDP and TCP Streams: IStreamReader and IStreamWriter. Apart from getting a unified interface, I have also tried to keep it simple. Now, streams just implement four methods: get_extra_info, close, read and write. I may have made it too high-level abstracting from methods like drain or others. I let it for discussion ;)

It may look weird UDP implementing a Stream interface, however, in order to achieve modularity between transports, we must simulate a Session-like-stream on UDP. Due to this Unified Interface, every transport protocol will need to implement four interfaces: ITransport, IListener and IStreamReader and IStreamWriter. You can find the new Stream interfaces here: UDP Streams and TCP Streams. On the other hand, I think this two last interfaces could be gatherer into one interface, however, I have prefered to divide them, for being compatible with current RawConnection, Swarm....

Of course, this code is just a playeable implementation, intended for encouraging discussions and give a new perspective. I have not made any tests for UDP yet, even though, TCP passes current tests while implementing this new Unified Interface.
@aratz-lasa aratz-lasa linked a pull request Oct 15, 2019 that will close this issue
Open
@ralexstokes
Copy link
Contributor

i know there has been some discussion on how to best unify tcp and udp under libp2p -- pinging @mgoelzer or @raulk for links to previous discussion

@mhchia
Copy link
Contributor

mhchia commented Oct 17, 2019

  1. Unified interface: to me, the unified interface for different transport sounds nice and necessary, in order to support other transports like QUIC.

  2. UDP: I couldn't find out a component in libp2p where UDP is necessarily depended on in other implementations. What I can think of for now is Kademlia, but the currently used transport which IPFS run Kademlia against is TCP. I lean toward to have more discussion on its usage and how we should support it before we actually implement UDP.

@aratz-lasa
Copy link
Author 

2. UDP: I couldn't find out a component in libp2p where UDP is necessarily depended on in other implementations. What I can think of for now is Kademlia, but the currently used transport which IPFS run Kademlia against is TCP. I lean toward to have more discussion on its usage and how we should support it before we actually implement UDP.

I completely agree. We must think and discuss about it, before implementing it. (By the way, I just did the pull request for being easily referable the code, I did not have any intention for merging it right away)

What do you mean by "how we should support it"? How would be best implemented?

@mhchia
Copy link
Contributor

mhchia commented Oct 18, 2019

What do you mean by "how we should support it"? How would be best implemented?

Yes. Sorry for being unclear. I meant how we should implement it. Which parts need modifying(Even though the other components are abstracted from the underlying transport, I guess we might encounter some issues when those components uses UDP transport.)

@mhchia
Copy link
Contributor

mhchia commented Oct 25, 2019 •
edited

I had a post asking about UDP support in libp2p forum. @bigs have a proposal for it. Since the discussion on the packet protocol is still ongoing, IMO it's nice to contribute to the proposal and we can implement it after things are settled.

@ghost
Copy link

ghost commented Oct 28, 2019

@bigs

@raulk
Copy link
Member

raulk commented Nov 1, 2019

Hey folks, track and participate in the discussion by following the links on this epic: libp2p/specs#225 Thanks!

@ShadowJonathan
Copy link
Contributor

ShadowJonathan commented Dec 20, 2019 •
edited

Maybe it's interesting to note here that I have been thinking about how to reorganize libp2p's connection implimentation structure, for example, here is a quick diagram of how the current tree (partially) looks like in that regard, and I've made a theoretical implimentation diagram here of a new situation, this all ties into #228.

The last diagram is still a draft, and already outdated (it's revealed through debate that I.*Connection right there can just replace Abstract.*Tunnel, the spec definition of "connection" is adequate enough for that), one which I have to flesh out and add other parts of the program to to make an actual calculated proposal, in an issue I'll post in due time.

(Opinion: Python is not Golang, and we shouldn't entirely rely on go-libp2p for examples, but instead work and live by the specs)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
py-libp2p
Status: No status
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add udp aratz-lasa/py-libp2p
5 participants
@raulk @ralexstokes @mhchia @ShadowJonathan @aratz-lasa