Bug report why uTP connections never closed

[KolbyML]

😱 oh no uTP connections are never closing 🧐

But why?

Doing some analysis only accept_with_cid was affected. This problem can be resolved with two fixes though

• adding timeouts on awaiting connections created by accept_with_cid
• and properly handling accept_with_cid. accept() specific logic which was breaking accept_with_cid

In most stream protocols you aren't able to choose a cid and the way the code was written it could block accept_with_cid for accept() specfic logic.
accept_with_cid/accept are two different paradigm to form connections so you can only choose 1 or another for your acception.

• accept: pulling connections off a incoming connections queue
• accept_with_cid: initiating connections from negotiating at a the application using it level (trin, fluffy etc)

But Kolby if we are required to pre-negotiate connections in the connect_with_cid/accept_with_cid paradigm shouldn't our client always receive the incoming connection for accept_with_cid to accept? Yes we should as we are on a controlled network where nodes aren't being shutdown mid message. We are running a controlled network with constant uptime. We could expect this behavior once our network has users though

interesting note

accept_with_cid was also having this bug when our network wasn't overloaded as well, so this isn't only a overloaded issue.

So we will fix the two issues about accept_with_cid I listed above.

performance with the 2 fixes

:D it is working now as expected which is awesome!

Future work

Going forward we will need to debug why the other node isn't sending us our uTP initaition packet, we are supposed to negotiated for it at the Trin code level. So this is 99% a bug in Trin's code itself unlike the bug with accept_with_cid() which is a bug in the uTP library

[KolbyML]

Now that we fixed issue 1 with ethereum/utp#122. Issue 2 not receiving utp connect message from pre-negotiated on trin level

We are able to see how often issue 2 is happening.

What is interesting is issue 2 is happening just under around 45% of the time which is quite significant. (History failed connection on this graph is issue 2 happening)