News: Sandvine's P2P Filter

[Paradog]

Without a doubt, peer-to-peer file sharing is among the most popular online activities for Internet subscribers. But while it may drive adoption, P2P doesn’t pay. It costs.

Up to 60% of the traffic on your IP network is generated by common file sharing clients like Morpheus and Bearshare. Asymmetric bandwidth consumption is always a concern, but even more troubling is the propensity of P2P clients to engage in “protocol chatter” with other clients off-network – driving up your NAP fees and eroding profitability.

Sandvine Peer-To-Peer Policy Management helps you establish policies that direct your subscribers’ file-sharing traffic down the least-cost network path.

The Sandvine PPE 8200 is a one rack unit (1RU) designed to lower network costs resulting from Peer-To-Peer traffic by logically rearranging the peer-to-peer (P2P) network topology. Sandvine's patent pending technology analyzes all P2P searches and ensures that each is redirected to an on-net host before attempting an off-net host. A search will only reach an off-net host after all internal searches have returned negative results. This reduces the number of searches that transit off-net, resulting in a reduced number of downloads occurring from off-net hosts. The result is a lower bandwidth cost for the service provider.

From www.sandvine.com

If this is possible I think it would be easy to block P2P networks totally.....

[stief]

Thought you might be interested in what Sandvine looks like for a user today. What a waste of bandwidth on a 1 mbps DSL (and who knows how much for those poor folks trying to download!)
Sorry about the graphics--let me know if they're too vague and I'll edit them to text. (Don't have your knowledge Peerless!)

[stief]

p2p has sure made it easy for kids to use all the bandwidth we give 'em . . . and the ISP's are scrambling because their assumptions about how much people use must surely be getting more scrambled.

Still, the unfairness of picking on p2p bugs me. They want to preserve bandwidth for what other apps? If the internet browsers need the bandwidth, it's probably to load god-awful html pages, mostly ads. If businesses need the bandwidth, I don't like subsidizing their communications (especially if they end up against my spam filter).

yada yada yada.

The other ISP I'm evaluating (just a 128kbps dsl) is arguing the latency of the network is causing the poor connections I see there too this week (some worm directed at Microsoft?) while they screen for viruses for the next week or so. Noticed Sandvine offers something similar, so it's hard to judge if I can get a clean connection to the gnutella network here. Hope the drop in netsize isn't because of all this active interference.

Know of any reliable way to verify a clean gnutella connection other than trial and error? Sandvine is just one of the devices that can interfere.

[trap_jaw4]

I just submitted the proxy patch to LimeWire. I'm almost sure you will get past this Sandvine thing by using your ISPs http (or socks) proxy. (Almost all ISPs offer http proxies, maybe you'll have to dig a little to find the address).

If you can't accept incoming connections or force your IP address, this patch will also proxy your uploads (unlike morpheus ;-) ) and it will also proxy all outgoing gnutella connections (also unlike morpheus )

I'm not sure if LimeWire will implement this, though.

[stief]

Once again--trap_jaw finds a solution!

Thanks from here: I'm sure many others will be grateful too.

[Paradog]

Originally posted by trap_jaw4
I just submitted the proxy patch to LimeWire. I'm almost sure you will get past this Sandvine thing by using your ISPs http (or socks) proxy. (Almost all ISPs offer http proxies, maybe you'll have to dig a little to find the address).

If you can't accept incoming connections or force your IP address, this patch will also proxy your uploads (unlike morpheus ;-) ) and it will also proxy all outgoing gnutella connections (also unlike morpheus )

I'm not sure if LimeWire will implement this, though.

Now thats really cool, how to you proxy gnutella's binary traffic through an http proxy though, just curious because i wouldnt know hot to implement this for http?

Dude, you had one version with blocking implemented and published to on your own, why dont you do the same for the proxying, just for the case LimeWire doesnt implement your code.

[trap_jaw4]

You simply send the HTTP proxy a request like this:
"CONNECT <HOST>:<PORT> HTTP/1.0\r\n\r\n"
and if the HTTP proxy answers "200 CONNECTED" you are connected. It's really, very, very simple.

[Paradog]

Thanks for your constructive contribution bpmax
Yeah sure trap_jaw, connecting is easy but how do you send binary messages through your HTTP proxy? If I'm not wrong it would be something like

HTTP/1.1 200 OK
Content-Length: 14
COntent-Type: Gnutella/Traffic (?)

[Binary Messages]

So eh?

[trap_jaw4]

Originally posted by Paradog
Thanks for your constructive contribution bpmax
Yeah sure trap_jaw, connecting is easy but how do you send binary messages through your HTTP proxy? If I'm not wrong it would be something like

HTTP/1.1 200 OK
Content-Length: 14
COntent-Type: Gnutella/Traffic (?)

[Binary Messages]

So eh?

The HTTP 1.1 specs (rfc 2616) introduced the CONNECT command for proxies. Upon receiving the http proxy then creates an outgoing connection to the requested host and sends a 200-reply if successful including a couple of other headers terminated by "\r\n\r\n" but after that the proxy simply forwards all traffic between the two endpoints.
This is also known has HTTP tunnel. Between the host requesting the connection and the proxy this is like a regular HTTP connection, for the remote endpoint it's just an incoming TCP connection and the proxy does not send any headers on its own initiative.

Do not confuse this with HTTP GET or HTTP POST, you don't have to send any headers for every gnutella message.

[Paradog]

Oh I get it. Can you post a compiled version of your stuff?