Jump to content

Uploading and Sandvine


kitfox69

Recommended Posts

Hello all!

To start out with, I know Comcast has dialed down their all out disconnecting of bittorrent requests (sending false reset packets). I have recently noticed that they do allow some uploading... but they are still keeping someone like me from seeding without downloading.

In my recent observations, it appears that their management equipment will allow the first, and sometimes second and third, piece(s) of my uploads go out to the requesting address, but after that first piece is finished all following connection requests are timed out (false reset).

This has been frustrating me for days now and I finally took it upon myself to log EVERYTHING that utorrent could and analyze it. Today I decided to spend 2 hours manually testing a theory I came up with and it works.

I can open utorrent, watch the first few pieces get transferred successfully and then when the reset packet get logged, stop the torrent and immediately restart it. This immediately forces the connected peers to disconnect and then reconnect allowing them to pick up another piece of my upload.

This has worked EVERY TIME I have done it for those 2 hours... and uploading in 512 KB pieces to 2 peers made for PLENTY of stops and starts, but the results showed that initial pieces are not blocked by their filtering and that they use that transfer information to block all following requests.

I am using the version 1.8 build 5 beta and would like to request that an advanced setting be added to set a specific time frame to totally disconnect peers after the seeder stops uploading pieces. If say you were able to set it to drop peers after 10 seconds of receiving a reset request, or even after not starting a new piece, and then be able to reconnect that peer, than this method of blocking would be defeated. Plus by setting it as an advanced option it could be totally ignored by those not affected by this.

If anyone has any ideas or suggestions to add to this please feel free to comment and email me.

Link to comment
Share on other sites

This helped... Thanks.

But it still has not fixed my problem as I can't seem to break 10 KBps upload even while downloading.

I understand that handling of the RST packets is dons on the OS level... but is there some way to interrupt this?

For instance could it be possible to stop utorrent from taking RST requests from the OS unless it is a hash encrypted request actually sent from the other peers? If utorrent was capable of encrypting the legit reset packets and be able to determine the difference between the real ones and Sandvine's fake ones, would that not stop this method cold?

If a filter could be implemented just before the OS level of RST reception, and that filter was able to track the IP addresses of the peers we are connected to , then that filter could be instructed to disregard RST packets from those IP addresses unless they were preceded by a shared hash between the peers, in which case the hashed RST packet would be honored and pushed through.

Does anyone here know if something like this is possible?

Link to comment
Share on other sites

> I can't seem to break 10 KBps upload even while downloading.

This possibly be an issue not related to Sandvine. Upload speeds are not affected when you are downloading even with Sandvine. Not for me anyway. It only seems to be an issue when soley uploading.

Link to comment
Share on other sites

When just seeding, I often see peers disconnect from me when they top the magical 30 KiloBYTES/second mark. It seems to be one of the criteria ComCast uses in its Sandvine hardware for when to break connections. :(

Even while downloading a torrent, I see quite a few connection reset by peer (Error 10054) messages in uTorrent's Logger. Almost certainly ComCast's doing. My guess is they also limit non-ComCast connections by total number...exceed that number and you may not keep any particular non-ComCast connection for long. :(

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...