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

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!)

Attached Thumbnails

 

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.

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.

Once again--trap_jaw finds a solution!

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

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.

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.

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.

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