Re: Kazaa! iptables table sizes and performance
From: jack (not_at_all.org)
Date: 05/09/03
- Next message: jack: "Re: Islam hacks Vatican?"
- Previous message: jack: "Re: Kazaa! iptables table sizes and performance"
- In reply to: jack: "Re: Kazaa! iptables table sizes and performance"
- Next in thread: Chris Lowth: "Re: Kazaa! iptables table sizes and performance"
- Reply: Chris Lowth: "Re: Kazaa! iptables table sizes and performance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 09 May 2003 23:31:49 +0200
jack wrote:
> I had some "talk" (that by mail, You know) to developers of both kazaa
> and edonkey (and some other, don't remember) asking them to come up
> with some sort of "reject token" that a server can return in order to
> stop those infinitely repeating connection attempts, as they seem to
FWIW,
I found back what I did then, date of this post is Feb 20, 2003;
thread was "Re: Port 4662, 10 times more packets since november":
<PROLOG: My request to:
info@edonkey2000.com; mldonkey@monsieurcinema.com;
Feb 19, 2003 - Answers came promptly, as follows>
Subject: Client connection flood...
Hello, there!
The corporate network that I am responsible for does not
take part in eDonkey. Since the connection to the inter-
net via DSL uses dynamic IP addresses, it happens that we
inherit IPs from former eDonkey clients. Thus, we get ba-
zillions of connection attempts to 4662/tcp, which I
understand is the client-client means of contacting.
Now since we have no eDonkey clients in our network, those
connection attempts are eventually dropped, resulting in
the clients trying to reconnect over and over. Since this
behaviour is not desirable, neither for us, nor for the
clients, I have been trying several mechanisms to stop
those requests; I tried with simply ignoring them, send
tcp reset, and icmp replies, yet with no success...
That's why I want to ask You whether there is a way to
stop those requests from repeating after they failed a
number of times (preferrably one, but perhaps a value of
four or so...). Or, even better, if there is some sort of
reply that I can send to the requesting client telling
it explicitly that it is useless to do any further
attempts on this IP...
Again, I think that this would make life easier for
eDonkey clients as well when they don't need to despe-
rately query a peer that is no longer there...
Thank You in advance,
Jack.
</PROLOG>
<MASTER QUOTE>
Ok, quick summary of what I tried:
I contacted staff at edonkey2000 and mldonkey, emule to be done later,
or, not at all...:
I asked them whether there is some means to stop other clients from
connecting to a box that obviously does not take part in that p2p
thing, like sending a specific token or something.
Here's what I got:
eDonkey2000:<quote>
Unfortunately there is nothing we can do. The donkey client will stop
trying to connect to your machine after it sees you are not there. But
some of the donkey clones, which we do not make, are not so nice and
will continue to try to contact you. So you should try contacting the
emule project.
</quote>
, and mldonkey:<quote>
The first thing you can do is to use an edonkey client, that does not
share anything, and hope it will tell connecting clients that it
doesnot have the files they want. I'm not sure it will work, because
there are different clients, and they have a different behavior when
receiving such replies. Some of them simply drop them, and reconnect
later, some of them (as mldonkey) remove the source from their
tables. Another problem is that the client that was on your IP before
may have been registered as a source for a file on a server, and the
server might keep this association for a very long time: clients will
connect to you, remove you from their sources, and receive you again
as a source from their server, forcing them to reconnect, and so
on... and there is no way to tell the servers you are not sharing
those files anymore.
</quote>
... - Which says it all... - I suggested implementing some means of
explicitly tell the servers, but first of all the clients that that
service it not available. Well, let's wait and see.
Then, I tried some of the other things again, like rejecting those
packets with all sorts of dropping silently, icmp messages an tcp
reset, but no go.
As Kasper had suggested, I then gave http status replies like "404
File not found", or "BYE.", as in the MFTP specification, but again,
without success. After all, I looked into that mldonkey source, and
I learned that if it's an http like request (there are other proto-
cols), the only replies that are distinguished are "200 OK" and
"302 Moved temporarily", all others are ignored in terms that the
connection is closed and gets into a retry loop. Where, as it seems,
it will live on forever...
Anyway, all of those p2p folks seem to be making a big secret of
their protocols, so I didn't want to put any more effort into this.
Bottom line: It doesn't matter what You do with those packets, they
will keep coming anyway, because those folks don't care about any
means of terminating these "swarms"... - So, doing anything but
dropping the packets (like having an "empty" p2p client... - lol)
will only add to all that unwanted traffic and take up even more
of Your bandwith.
Wolfgang Formann wrote:
[...about 4662/tcp...]
No further action by me.
</MASTER QUOTE>
Just for info, Jack.
-- ---------------------------------------------------------------------- My personal reading of the string "MicroSoft" expands to "NanoWeak"...
- Next message: jack: "Re: Islam hacks Vatican?"
- Previous message: jack: "Re: Kazaa! iptables table sizes and performance"
- In reply to: jack: "Re: Kazaa! iptables table sizes and performance"
- Next in thread: Chris Lowth: "Re: Kazaa! iptables table sizes and performance"
- Reply: Chris Lowth: "Re: Kazaa! iptables table sizes and performance"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
