Gnutella DoS attack?

[sdsalsero]

Something's gotta be going on here... Over the past two days the number of people downloading from me has been steadily dropping. I haven't changed anything on my end so I assume they're being blocked somewhere. I keep reading stories about companies hired by RIAA and MPAA to disrupt P2P networks and I suspect this is the result.

Does anyone have any idea what's happening?

The way things're going I'm gonna have to switch to another P2P system, which I would hate to do after being a loyal Gnutella (and Limewire) supporter for the past two years.
____________________________________

I just tried restarting LW and enabling Ultrapeer (I usually reserve my bandwidth for uploading). It took almost a whole minute for me to establish a stable connection to anyone! What could cause that? I seem to be properly established as an Ultrapeer now, at least...

[trap_jaw4]

I don't think the RIAA/MPAA have anything to do with it.

I'm not sure, but it seems to me, as if the lower number of uploads is rather caused by LimeWire. I don't know if it's really a problem.

[Blackbird]

I kind of noticed the same thing. I've been using LW for about a year and a half now, but I just got the forums here. I think that maybe the number of people on right now is just smaller. LW's little connections counter on limwire.com doesn't seem to indicate that is so however. Theory: a large percentage of people who use P2P programs are college age and younger. Perhaps the past week and the next few are the traditional weeks for finals, so fewer of them are actively downloading and uploading. Second Theory: they're all, however, still connected, just not downloading.

I don't know why. Also, it could be you, and it could be coincidence.

Any one else have any other ideas?

[David91]

I'll start with a Limewire specific point and then ramble off-topic for this forum. In recent upgrades, the developers have capped the number of search hits returned. Gnutella has been experiencing serious traffic management problems and, this is one of the strategies to "improve" matters. Hence, you may be seeing fewer hits and, of those, more may be unresponsive. You could consider filtering out the LAN servants which would probably improve the percentage of positive connections achieved from the hosts returned. Now, invert this. Most people do not filter the servants and will see only a limited number of "real" hits for each search. Thus, the chances of your site's collection appearing are actually reduced.

As to your more general question, you are correct in your assumption that the majority of p2p clients in the USA are accessing the net from LANs. System administrators have been responding to the encouraging words of the RIAA by reducing the QoS on bandwidth allocation to their users. And the users have been observing several new trends in addition to the much-publicised litigation. School, college and university principals, and employers have begun to enforce more real anti-copyright theft policies on the ground. Spiders released by RIAA investigators are now roaming the net to detect large holdings of potentially illegal downloads and notifying educational institutes, large employers and ISPs of the addresses of offending sites. And ISPs have been sending out warning letters to those customers suspected of trafficking in illegal downloads.

While individuals were able to sit undisturbed on their machines, they could believe they were invulnerable. Now that they are receiving e-mail and written warnings, they understand that the pattern of behaviour, unchecked up to now, is under more direct attack and some grow cautious. Equally, some are rapidly devising some very amusing little packages to confuse the spiders and others are engaging in a dialogue with their ISPs on the lawfulness of the scanning of their "private" materials without a search warrant.

The number of people who exchange files ebb and flow in response to circumstances. I take no view on who is right or wrong in this latest battle over copyright. Reading some reports of the volumes of files held on some educational systems, I might be tempted to describe the abuse as excessive. Equally, the reaction of the entrenched commercial interests is obviously too uncompromising to be justified. Either a compromise will emerge (such as Apple's initiative in the USA) or there will be an armed truce. Whichever it is, the rest of the world can watch the activities of the RIAA with disinterest and you should find most of the material you want through patience.

[trap_jaw4]

Originally posted by David91
[B]You could consider filtering out the LAN servants which would probably improve the percentage of positive connections achieved from the hosts returned. Now, invert this. Most people do not filter the servants and will see only a limited number of "real" hits for each search. Thus, the chances of your site's collection appearing are actually reduced.

Filtering LAN clients is not a good idea because it can reduce the number of results you receive substantially. The ultrapeers you are connected to will return a certain number of results. If you are filtering LAN clients, your servent will just drop some of those results. You will not get more non-firewalled results instead. -
If you are on a LAN yourself (and if LimeWire is aware of that), LimeWire will automatically set the firewalled-bit in your query and other LAN servents will not return any queryhits (there is no option to force LW to do that, though).
The next versions of LimeWire should have a higher push timeout & push proxies, fixing some of the problems with connections to clients from within a LAN.
From my experience clients from a LAN are generally faster and less often busy than servents with a direct connection to the internet, making up for a lot of the trouble when trying to connect to them.

[David91]

Hi trap_door

Good to have the opportunity to learn something from you again since you have always been able to point out the error in my ways. In experiments reported by the University of Montreal:

Experiment A Experiment B
Total addresses received 7482 19484
Invalid addresses 2240 (30 %) 7042 (36 %)
Repeated addresses 1432 (19 %) 5298 (27 %)
Already in cache 1696 (23 %) 3978 (20 %)
Retained 2114 (28 %) 3166 (16 %)
Unique good addresses 1514 (20 %) 1792 (9 %)

only 20% and 9% of search returns were useful addresses. Given that such a high proportion of the search returns were invalid hosts, why is filtering such a bad option. It maximises the utility of the search list displayed and, if the user repeats the search on a regular time displaced basis, there should be a significant improvement in the quality of the results. But you also neglect to consider the more fundamental point I was making, namely that because these invalid returns are in the majority, the limitation on search returns actually reduces any given user's chance of getting good hosts.

[trap_jaw4]

If a direct connection attempt for one host fails LimeWire will always send a PUSH message (which is not delivered directly and does not depend on the supplied address from the queryhit). If you have a direct connection to the internet and you are thus accepting incoming connections, you can still download if the PUSH request is delivered successfuly.

[David91]

But that has to rank as one of the most obscure replies I have received from anyone. Are you saying that if I attempted to connect to a host using an address with no global validity, Limewire will send a PUSH message to another host with a globally valid address to attempt a connection for the same material?

Let us ignore the fact that this would not be an answer to the two questions I asked so that you can carry on my education. If my interpretation of your answer is correct, you are describing a feature of Limewire that is new to me. Could you supply me with the address for the documentation on this feature, please. If my interpretation is incorrect, could you please clarify your answer.

Many thanks

David

[trap_jaw4]

The PUSH message is documented in the original Gnutella 0.4 protocol from Clip2. It has always been a part of gnutella and all servents should support it.

http://rfc-gnutella.sourceforge.net/...0_4-rev1_2.pdf

[David91]

Right so, "If a direct connection cannot be established, the servent attempting the file download may request that the servent sharing the file “push” the file instead." The specification only says "may". You're saying that Limewire actually sends the PUSH in its present version? Is there any evidence that the IP in Servent Identifier Field ever responds by establishing a new TCP/IP connection to the port?

This is most interesting. And, although this "may" work for firewalled hosts, what about all the other invalid IP responses contained in the pongs that end up being displayed as hits? Unless I am wrong on that as well. Does my machine suppress all the other hits that are invalid for different reasons?

Thank you for humouring my in my ignorance

David