Re: [Mldonkey-users] Investigation: No download for some, fulldownloads for the other

[René Gallati]

Hello,

> Well, I understand that, but, on the other hand, I often stop my
> client to play on my computer for one hour, and then restart
> mldonkey. Other people start their client at 9am in the office, and
> shut it down at 5pm before leaving. If they share a very rare file,
> you will be happy to connect to them the day after (or the next
> monday) because you have remembered them, and not because you are on
> the same 30-users server that they have unluckily connnected
> to. Moreover, source propagation will only work if you find someone
> which is on the same server, which is also unlucky, because you are
> only downloading rare files and so don't connect to many clients.

I *do* understand that side of the story. However I always thought the
primary mechanism to obtain sources is by asking servers...? At least that's
the default behaviour of eDonkey, whose quirks I learnt and observed. If
your source re-emerges then it is going to publish on a server and
subsequently gets found again. If mldonkey does no UDP searches to all
server it knows, then I can see there is a problem. If I remember correctly,
the official eDonkey clients asks every 15 min or so a batch of servers to
obtain sources.

When I reemerge, my client connects to servers (even several at once, with
mldonkey...) and thus gets seen again. I see no problem therefor.

I simply consider it rude networking behaviour, if a client consistently
tries to reach me even though every single time he gets a "he's gone"
message back. (As a side node, the afforementioned behaviour repeats itself
three times -> SYN  <--- SYN, RST, ---> SYN <---- SYN, RST,  ---> SYN <----
SYN, RST within one second. This is probably the TCP stack of the
originator. However the client comes back after 5 oder 10 minutes and
repeats) And of course it is not just one client, there are lots of clients
doing this ..... Would the timeout be shorter I'd look at it as "hammering"
but as for now, its just as I said: rude network behaviour.

Most people probably don't know or see this, however I wouldn't mind if
mldonkey behaves nicely. If my system(s) say there's nothing there, then
there IS nothing there. I don't mind if mldonkey later gets my IP due to
source exchange and tries again ONE time. However repeated tries to reach
something that always tells you "not here" is just.... wrong.

Also remember that all german T-DSL users lose their IP after 24 hours. So
the chances are high that you continue to pester entirely other people's
machines. (My IP is fixed, therefor I see them over days trying to reach me)

>  So I don't think that remembering very old sources is such a bad
> thing, unless your file has already many good sources, or you are

No remembering old sources is not bad at all. Simply not losing them when
they cease to exist is... maybe you want to add a counter and only lose a
source once you hit X tries which responded in a port closed message.
(Whereas X shouldn't be greater than 3 though... that's still enough tries
for port unreachables...) Add to that an exponential timeout and it will
behave much nicer (ie source gets asked after one hour, gets port
unreachable back -> requeued for asking in 2 hours. Then if again port
unreachable -> requeue for asking in 4 more hours -> if still port
unreachable, delete the source)

> running out of memory.  The only thing that need to be to done is to
> delay such reconnection attempts, such as a few hours instead of the
> 10 minutes of good sources.

Maybe. However if you always get a port unreachable back, you should stop
considering the source valid.

Haha, to proof my point: I just sniffed on my connection. Within 5 minutes,
I've recieved 21 SYN packets on my mldonkey port. From 5 different source
IPs... I've last run mldonkey on that port 7 days ago.... (!!!)

Go figure... I cannot say what type of clients that were, you don't see that
in their SYN. However, as I mentioned, I don't mind using a client of which
I know it behaves nicely with regard to networking behaviour.

--

C U

     - -- ---- ----- -----/\/  René Gallati  \/\---- ----- --- -- -