Poll for Interest: Helping unconnectable (firewalled) users

[cjard]

Some of us out there are unconenctable for reasons beyond our control, like a work's firewall.. but using work's connection is generally very good because it's quick. However, the unconnectability causes some problems including lack of interest from peers, and inability to serve the full swarm.

Sometimes those users who are firewalled at work are not firewalled at home, and i'm considering a way to use this to make them connectable at work. The current thinking is:

To upgrade the client's intelligence to make it aware of a split between the capabilities of the incoming and outgoing stream: incoming connections will be served at a lower speed if they are routing through a home connection of 256kbit (upload speed on a home dsl line) rather than a megabit+ works connection. Also, the home connection would be split again, half serving the incoming data from other unconnectables, and half sending data out to other unconnectable peers. It would be slow - however, something's better than nothing

Currently I can achieve this setup by custom writing two socks servers (one with client awareness). It's proxy chaining and is established method of doing things. The difference being the proxy nearest the client, when asked for an outgoing connection, makes it direct (work can connect outbound) and when the proxy is asked for a bind, it will route via the home connection. The IP to report to the tracker is the home connection's IP.

Issues with this that i'd like to speak to a developer about are that i dont know huge amounts of detail about the torrent protcol - i'd need some way of causing the client to prefer making outgoing connections. This is why i think that building the intelligent connection into the client would be better. I dont know how to make the local client proxy force the client to prefer outgoing, or if it is even possible. At a push, the home proxy could become bittorrent protocol aware and behave like a client, choking itself up to prevent excessive amounts of inbound connections. But i'm not sure, which is why i'd love to hear comment from uTorrent developers who know the protocol more intimately, and can expand their thinking into my domain of understanding (generic tcp networking)

Could some developer comment on this? Would you be interested in making uTorrent the first client that can use one proxy server for outbound (i.e. none) and another proxy for inbound, with different speed settings, slots, etc.. basically to avoid the inbound connection swamping because it is being routed via a much lower speed line? I'd be glad to write the home side proxy server; i wrote a customised socks 5 server for my university dissertation, so im already familiar with the protocol and issues with it.

Hopefully this system would be more successful that bitcomet's system for NAT traversal (which is limited and slow) - this system doesnt need other users to be running uTorrent, and improves swarm visbility greatly

[DreadWingKnight]

To upgrade the client's intelligence to make it aware of a split between the capabilities of the incoming and outgoing stream: incoming connections will be served at a lower speed if they are routing through a home connection of 256kbit (upload speed on a home dsl line) rather than a megabit+ works connection. Also, the home connection would be split again, half serving the incoming data from other unconnectables, and half sending data out to other unconnectable peers. It would be slow - however, something's better than nothing

Automatic line rate detection, requested already.

Currently I can achieve this setup by custom writing two socks servers (one with client awareness). It's proxy chaining and is established method of doing things. The difference being the proxy nearest the client, when asked for an outgoing connection, makes it direct (work can connect outbound) and when the proxy is asked for a bind, it will route via the home connection. The IP to report to the tracker is the home connection's IP.

You're assuming the tracker will even accept being passed the IP override value. Many trackers don't.

Issues with this that i'd like to speak to a developer about are that i dont know huge amounts of detail about the torrent protcol - i'd need some way of causing the client to prefer making outgoing connections. This is why i think that building the intelligent connection into the client would be better. I dont know how to make the local client proxy force the client to prefer outgoing, or if it is even possible. At a push, the home proxy could become bittorrent protocol aware and behave like a client, choking itself up to prevent excessive amounts of inbound connections. But i'm not sure, which is why i'd love to hear comment from uTorrent developers who know the protocol more intimately, and can expand their thinking into my domain of understanding (generic tcp networking)

Outgoing only = bad.

http://bt.degeeez.net/firewalled.html

BitTorrent swarms thrive when all peers are connectable. If more outgoing connections are made than incoming, more strain is placed on peers that can establish connections in both directions, harming the overall swarm health by reducing the number of connection slots available.

Ultimately, firewalled users are going to be a problem no matter what solution we try to implement.

[cjard]

Automatic line rate detection, requested already.

Not quite what i'm seeking: I need comments on effectively throttling upstream and downstream over ifferent routes. I dont care whether it's automatic or manual

You're assuming the tracker will even accept being passed the IP override value. Many trackers don't.

It's a good point and one i hadnt considered. It's easy to solve though; if the tracker wants to work out the client IP rather than be told what it is, then we simply forge the connection to the tracker via the home routing.

Outgoing only = bad.

http://bt.degeeez.net/firewalled.html

BitTorrent swarms thrive when all peers are connectable. If more outgoing connections are made than incoming, more strain is placed on peers that can establish connections in both directions, harming the overall swarm health by reducing the number of connection slots available.

Ultimately, firewalled users are going to be a problem no matter what solution we try to implement.

very true.. and i do appreciate your point that we should be avoiding firewalled users all together. Im looking at this from a different angle: turning 100% firewalled users into some percantage connectable (an odd concept in a black and while world, but lets say for argument that your home connection has 10% the data rate capacity of your works line, i reckon that makes you 10% connectable via this method

Personally i would rather the swarm have some percentage of partially connectable peers, than have those peers as unconnectable. Where there can be no possibility of making a peer 100% connectable, then why not make them something better than 100% unconnectable. Plus, if i, as a firewalled peer, have some chuinks of a file and a new peers joins the swarm who IS connectable, then surely they deserve to trade with me; they've made the effort of being connectable and i've got the file. I'm going to leverage my massive upload capability to give them what they are looking for - and we both brought something to the party

The notion of making yourself connectable by using someone elses connectable connection is not a new one; but i think the splitting of it is. Ultimately, I hope it will be if benefit to the swarms, and I'm keen to see if you have any further comments, as your post provoked some more thought from me.. Thanks!