Implement Solution For uTP

[GGist]

I didn't realize so many peers only accepted connections over uTP nowadays. During testing it was hard to find any peers that still accepted connections over TCP, so we will want to prioritize work on bip_utp, this issue is to track the progress of that work.

[the8472]

There are several utp libs on crates.io. Maybe one could be used to avoid duplicate effort?

[GGist]

@the8472 That is I think the most realistic for the short term. I didn't see any utp crates that were futures based, so in the short term I would still like to have a small wrapper over those crates, where we run blocking reads/writes to the utp stream in a dedicated thread and expose a futures based interface over that.

In the long term, it would be nice to have a utp solution that worked on top of tokio's UdpSocket so that a dedicated thread is not necessary.

[the8472]

There's this: https://github.com/carllerche/utp

It even lets you wrap an UDP socket.

[GGist]

Interesting, that looks like it could fit the bill.

Will look in to it more when I get around to hooking it up with the Handshaker.

Thanks!

[GGist]

Just an update from looking in to https://github.com/carllerche/utp. I was able to get the library working with tokio, however, the library has some issues that I was able to identify, and others that I was not able to identify.

Off the bat:

• Doesn't send a timestamp that follows the spec, but instead, sends a timestamp relative to when the connection was initiated
• Sets initial ack number equal to the seq number of an ack packet, causing clients to ignore us, since we acked a packet that doesnt actually increment the seq nr

It looks like the code works when running against itself, but I am not sure that it has been tested against real clients. Additionally, it has a lot of un-answered PRs, so I am not sure if the owner is planning to actively maintain it.