... Just today, I've discovered another major spammer. I assume, you already know about these: 69.44.155.54 69.44.156.53 69.44.157.56 69.44.158.204 The spammer...
... Typo, that's 69.9.189.190. It looks like the ranges are limited to 69.9.187.0/24 69.9.188.0/24 69.9.189.0/24 But that's hard to tell without asking...
Hi, I wondered why the hell the GWebCache request rates are still steadily increasing even though LimeWire has mostly switched to UHC now. Turns out, MLDK...
... One option could be that MLDK not implementing compressed comnections, it is not able to connect to modern servents and therefore desperately looks for...
... It seems to be in the mldonkey bug database already. Let's hope they fix this. http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9686 guruz...
LW still supports connections which are not compressed so I guess this is not the origin of this issue. I've no problems connecting to the GNet with not...
Propose reuse ttl and hops as the timestamp for RTT Each Ack should copy this the timestamp value. The structure looks like: struct GetRTT // 23 bytes { ...
... Just curious - has anyone tried STUN/TURN/ICE stack or at least looked in that direction? Any experiences to share, positive or otherwise? Best wishes - ...
... "Mark with GGEP 'IP' so that servers send our IP back in Pongs" What's the format of GGEP IP and what exactly do you expect as reply? I assume GGEP IP in a...
... My UHC experience tells me that 10-12% of all UDP ping/pongs have a RTT above 1s. The median is about 120ms or 160ms, depending of the location (USA vs....
... Because you're not reading the GDF via the Yahoo! web interface. Otherwise, "scroll up" would have been enlighting enough. Raphael...
Raphael_Manfredi@...
Feb 3, 2005 9:48 pm
21357
... Um, I'm reading this straight off the web from Yahoo, but the words "scroll up" aren't enlightening me at all. What, do I scroll up and my Gnutella core...
Hi Greg what do u think about this: Reuse ttl and hops of Gnutella Header as the timestamp for RTT. Sender put timestamp in each Data message and receiver copy...
... Why not save bandwidth and just have the sender store the timestamp in a table index by the message's unique ID? (forgive if I'm missing something; I...
... Oh, right. The field is already there. I suppose I should say: why not save the field for something else and just have the sender store the timestamp in a...
You can't tell the request is lost, or the reply is lost, or the RTO is too small. save timestamp is easy and no error ... RTT. ... timestamp in ... and ... ...
... We could expand on Julian's suggestion to put magic in the timestamp field: treat the "timestamp" as a set of flags (like we twiddle the minspeed bits in a...
... I wonder why you don't use GGEP instead of re-using parts of the GUID. The 128-bit GUID gives a rather good protection against brute-force packet injection...
1) as file transfer protocol, it may be too heavy to keep GUID and GGEP. 2) The initial sequence number should be 0. 3) as for the brute-force packet...
