search

ntop / n2n

Peer-to-peer VPN
GNU General Public License v3.0
6.28k stars 943 forks source link

How to use n2n to break the speed limit of ISP single connection #651

Open pokebox opened 3 years ago

pokebox commented 3 years ago

Recently, when I used n2n to create network transmission files in various locations, I accidentally discovered that some ISPs limit the upload speed of a single link. When using super nodes, the total transmission speed of multiple file transmissions is only 300KB/s. I am trying to do it without using n2n, The same is true for sftp single file transfer. But when I try to use sftp direct access without using n2n, the total speed of downloading multiple files at the same time can reach 70Mbps! I am sure that a direct connection is established between the n2n super nodes. So can n2n provide multi-threaded or multi-link connections in future versions to increase the transmission speed?

Logan007 commented 3 years ago

As mentioned earlier, this would be a very interesting enhancement!

Everybody, please share your thoughts on how to realize and implement this.

llfj commented 3 years ago

The ISP will limit the incoming line rate of UDP packets. TCP can break through the speed limit of blocked ISP, so we look forward to the perfection of TCP transfer. It is recommended to use UDP first in P2P, and use TCP in preference to transit through supernode.

pokebox commented 3 years ago

The ISP will limit the incoming line rate of UDP packets. TCP can break through the speed limit of blocked ISP, so we look forward to the perfection of TCP transfer. It is recommended to use UDP first in P2P, and use TCP in preference to transit through supernode.

But in experiments, it was found that ISP may not only limit the rate of UDP, but also TCP. Because when I try to use sftp or http to establish a connection directly, the speed of a single connection is still very slow.

Logan007 commented 3 years ago

Do I get it correctly that this feature would require a bundle of sockets for each connection?

That would require some new "abstraction layer", namely a "connection" which holds and manages (opens, keeps open, re-checks for changes, re-opens in error case, closes) the sockets associated with the connections. The connection would be more related to the peer view. A whole new level of connection and socket management!

Do the edges suffering these ISP restrictions would be required to already listen on several ports then? This mode needs to be enabled somehow, a new command line option? How to advertise the extra ports? Maybe send REGISTER packets (with the same cookie) through all sockets? The receiving peer could identify them as "belonging together" by that same cookie and therefore knows that it is not a new port for that other peer which still carries the same MAC. But then, how to make sure that each source socket sends to a different destination socket (this might be required to circumvent the restrictions)?

The current configuration would be the special case of one socket per connection and should be compatible.

Those are the cornerstones I can identify. Any volunteers for implementation?

RHONSO commented 1 month ago

Can someone teach me how to do it