[Bug 3.8.7] Duplicate connections as UP
 

Salut à tous, as an UP i've seen today duplicates in UP connections as well as leaf connections. ie two instance of the very same IP (they weren't nated or behind router etc..). This is quite a stupid bug to say the least ;) Now, please fix it!

Merci beaucoup

Salut et voilà

I just checked my connections--no duplicates (uptime 30 hrs as UP on the official 3.9.1beta).
Sandvine p2p controls did show duplicates (of my own client) in the past: old screenshot here

This does not sound like your case, but just in case . . .

Héhéhé, at least I know Sandvine isn't the problem here :D I am UP for a couple of hours, the two connections were from a 3.8.7 as UPs and two same 3.6.15 as leafs. The duplicates have been connected for the same time +/- 1 second (ex: 3.8.7 connected for 15:26 and the same 3.8.7 connected for 15:27) to my UP so this may be a race condition in the code. (I should have taken a screenshot, I disconected them manually before thinking about that...:rolleyes:).

Ciao

Not necessarily a bug: there may exist two distinct hosts at the same IP, trying to connect to you through the same firewall or NAT routing device...

Why do you think that these hosts are not firewalled or NAT-routed? It's possible, for NAT-routed hosts on the same LAN sharing the same Internet access, to create independant connections to the same target UltraPeer on the Net, and these two hosts on the same LAN way still be able to accept incoming connections on the same port.

These two hosts do not communicate each other to check their mutual connections attempts.

But usually the UltraPeer will disconnect one of them, à priori the most recently connected one that will have to seek for another UltraPeer...

But normally, the first Gnutella packet that a Limewire leaf node sends to an UltraPeer is a connection header specifying on which port they expect to receive incoming connections, as well as their own Gnutella servent GUID and IP address and port number within the first Gnutella message sent which should be a direct PING with TTL=1 and Hops=0 (so that this ping message will not be relayed to other hosts, but will just feed the UltraPeer pong cache, and will setup a routing path for QueryHits to forward after the leaf has relayed a Query through your UltraPeer.)

MÀJ/update here is a picture of the same UP connected two times (the ip and port are the same and the QRP filling is the also the same. They are unfirewalled because they're running UPs.) They connected at the same time to my machine (+/- 1second).http://cmt.homeip.net/documents/buggy.jpg

Took a while for catch this rare condition, but now can confirm--3.9.9 Beta (pro). Also managed to get screenshots of the tooltip info (identical). Uptime over 5 hours, and each using differing amounts of bandwidth.

Note that a firewalled node CAN BE a UltraPeer. What is really needed is to accept incoming connections on the configured port. This does not forbids firewalls or NAT routing devices.

Even in the 2 other examples shown as screenshots just above this message, it is really possible that two hosts (with distinct GUIDs) share a connection with the same visible IP, and even the same shared directories (which may be on a mounted local network shared disk).
For Gnutella, they may even be two distinct UltraPeers each one with its own set of connections. So they participate to the topology. Servents are not uniquely identified by their IP but also by their port number for incoming connections. As the first ping that is exchanged between connected host will contain this port number, they will be distinct.

I can't remember however if the two direct pongs exchanged contain the unique host GUID or just a unique GUID matching the ping request. If this is the unique host GUID (to be used in QueryHits and routing of pushes), then it should be possible to identify if two connections from the same IP belongs to the same host.

Humm je le sais, it's obvious Philippe....

There is one chance out of 50 billions that this eventuality happens .... Admit it, there are 10 millions more chances for this to be a bug and a lottery happening:rolleyes:
Possibilities are one thing (what you describe CAN happen, but can it have happened a couple of times on my computer and on the one of Stief-- no!) , but you have to look at the probabilities sometimes...

Philippe, t'es sûr que tu n'as pas un diplôme en philo? Moi je suis plus du type statistisques :)

just to clarify, I looked back at the screenshots and that host had the same IP:Port (6346). However, in another screenshot earlier the host used 6348. If it connected twice using a different IP:Port, and changed to the same later, that would explain the rarity, no?

Salut Stief, if he had port 6348, maybe he was running two instances of LW, which is possible under windows (this happened to EllisD). Anyway it is weird and LW shouldn't allow two UP connections of the same ip and port.


Here is another thing weird, an UP connected for more than two hours but it didn't even sent a QRP??? Has you can note on the shot it isn't a 0.6 normal peer either....
http://cmt.homeip.net/documents/pkoi.jpg