From @theobat on Fri Oct 07 2016 13:20:02 GMT+0000 (UTC)
Hi @diasdavid ,
Not sure about this sentence in the libp2p specs :
Note: At this time, no unreliable implementations exist. The protocol’s interface for defining and using unreliable transport has not been defined.
I don’t think I understand properly what this means so could anyone throw a simple explanation ? (What I think it means is : there is no spec defined for how to handle in the ipfs p2p protocols the absence of a transport protocol in a multi address path… ). More specifically what does unreliable means in this context ?
From @whyrusleeping on Fri Oct 07 2016 18:21:38 GMT+0000 (UTC)
libp2p isnt really sure how to handle unreliable protocols in general. It makes a large number of assumptions about all of its transports being reliable (in the TCP, receive all the packets in order meaning of the word).
Adding unreliable transports to ipfs would mean rethinking how various aspects of the protocol work, crypto for example would need to change, we currently use a stream cipher that requires reliable ordered packets.
The identify handshake also would need different logic, getting that info exchanged is required for the proper functioning of the node, so we would want a way to ‘upgrade’ temporarily to a reliable connection (retransmits, etc) and then back down for other comms.
From @diasdavid on Sun Oct 09 2016 22:30:56 GMT+0000 (UTC)
@theobat exactly what @whyrusleeping said. tl;dr; IPFS wouldn’t work over a straight UDP socket, which is an unreliable transport. However, a way to make it work is to upgrade the UDP socket with some kind of Congestion Window to add reliability to the flow, like UDT or uTP do, however, we don’t have that ‘Congestion Window’ stand alone module implemented.
From @diasdavid on Sun Oct 09 2016 22:40:08 GMT+0000 (UTC)
@Kubuxu it would be helpful to point to those threads when referencing that there are bugs, so that people that find this issue can also know if the bugs are ‘solved’ by the time they find this.
For reference I want to contribute some of my findings testing and debugging the UTP transport.
Last year I’ve been testing IPFS with UTP enabled to see if the UTP transport would improve transfers on unreliable networks and would not interfere other transfers that were ongoing in the network. I was hoping UTP, being build on top of UDP, would work beter than TCP in my network and would give priority on other network traffic that was on the network.
Unfortunately the UTP transport did not work very well for me. It looked like the UTP transport was flooding the network and blocked all other network traffic.
Apparently the behaviour is caused by the underlying UTP implementation as I noticed the same behaviour of UTP when I tried the ucat test application that is included in the UTP implementation.
I also tried the ucat that is part of the C++ implementation of UTP. This implementation works like I expected. It would maximise throughput but give priority to background traffic. It seems that the back off mechanism that is documented in the UTP specification (BEP 0029) is not implemented in the Go library.
Note that I wanted to add some more links to related content but since I’m a newby I’m not allowed to post more than 2 links…
