Publish utp protocol code as standalone library ?

[sgmihai]

I am trying to write a torrent client, for learning purposes, and having a library for utp transmission would be nice.
There are no docs to that part of the code and I am not familiar with the specifics, so I have to ask, is this "vanilla" utp or does it have subtle differences in the eth ecosystem ? Can it be used to interop with torrent clients as is ?

Secondly, is there any chance this could be copied to a different repository and published to nimble ? Wouldn't have to be actively maintained, or code in nim-eth to link to it, just having it separately and dependecy free as possible would be nice.
I noticed it depends on a few units outside /utp that don't seem to have anything to do with utp itself, that might hinder this potential effort: eth_hash.nim keys.nim random2.nim - but it seems to be mostly for random number functions, and eth_hash for KeccakHash which I am not sure is used in utp protocol itself.

I think this would be a valuable addition to the nim ecosystem. Curious to know what you think.

edit: another issue might be compatibility with nim's asyncdispatch. I couldn't compile the example code in utp.nim with asyncdispatch:
type mismatch: got 'proc (server: UtpRouter[common.TransportAddress], client: UtpSocket[common.TransportAddress]): Future[system.void]{.gcsafe, locks: <unknown>.}' for 'proc (server: UtpRouter[TransportAddress]; client: UtpSocket[TransportAddress]): Future[ ... return fakeFuture' but expected 'AcceptConnectionCallback[common.TransportAddress]'

[kdeme]

Sorry for the very late reply. I seem to have completely missed this issue.

To answer your questions:

• Yes, it is supposed to be Vanilla uTP. During development it was tested against the test app of libutp. It also follows the libutp and libtorrent implementations rather than the uTP specification. There are some slight differences or mistakes in the spec. That being said, it is not super well tested against these implementations, that is, I don't think it has been run against those implemetations for long connections sending lots of data, with lots of data loss, etc. So issues may still arise obviously.
• The uTP implementation is being developed for an Ethereum project called the Portal Network. This is why it is currently in our nim-eth respository, as this project already requires the nim-eth dependency and we also need to run the uTP on top of discovery v5. Nevertheless, you can run it over UDP (or any custom transport can be added). This can be seen for example in https://github.com/status-im/nim-eth/blob/master/eth/utp/utp_protocol.nim vs https://github.com/status-im/nim-eth/blob/master/eth/utp/utp_discv5_protocol.nim.
  Anyway, adding it to nim-eth was mostly done to get development started faster especially as we didn't know yet where we were going with this. I think it has reached or might reach a point soon where it makes sense to move it to a separate repository.
• The uTP implementation is developed and only tested with nim-chronos. I do not necessarily expect it to work with asyncdispatch. If you do manage to make it work at a certain point, then we cannot guarantee that it will keep working in the future.