nazar-pc
commented
6 years ago Instead of creating offers from the sender node, announce offers to the routing table. (in normal case it's ip:port address).
Could you clarify what do you mean here?
I would consider to use typescript, instead of lifescript, as it's very hard to read
It is more of a personal taste. I like LiveScript for some of its sugar, but it requires you to be familiar with it, otherwise it is indeed a bit tricky to read (also make sure to configure 1 tab to be 4 spaces, otherwise it looks terrible).
I'm not going to respond to all of the rest questions yet, because I'm not sure we are on the same page (also clarification from you would be nice). However, I'd like to ask did you read https://github.com/nazar-pc/webtorrent-dht/blob/master/bep.rst? It contains formal description of what was implemented (except extensions, which will be added too at some point).
I had time to play around with the WebRTC itself and i might suggest something.
Instead of creating offers from the sender node, announce offers to the routing table. (in normal case it's ip:port address).
There are two benefits: 1, The browser melts down on too many parallel connection, so you can initiate 5-30 offers by node advance. 2, You are not bombarding the signaling node, if there is no offer available from a particular node, as you cannot go directly to the node and connect to its port directly in WebRTC, just through it. 3, You can remove infos without pinging anyway, as it sends back close message. 4, You can eliminate the offer hop chain, just you need the answer and ice candidate hops.
In the signaling server case, you need to close WebSockets if the initial peers has been connected, as i think the WebRTC in the filesharing case makes more burden. A normal server simply cannot handle too many Websocket connections. (1000-2000 maybe - so it needs some pooling mechanism, anyway the whole meaning to use DHT with WebRTC would be meaningfull)
WebRTC has been figured out in 2015, but it's in draft still. (I'm not sure why)
My understanding is that you cannot reuse already used offers, but if the underlying connection has been closed, than you can reuse it again. So i would consider some sort of offers pooling in the routing table.
Unfortunately as it's a totally different technology it makes the K-bucket system a little bit more complicated if we need to achieve similar throughput.
I would consider to use typescript, instead of lifescript, as it's very hard to read. I would separate the classes of torrent and webtorrent through inheritence anyway.