Sometimes need to manually 'Access' G2 source

[ceriank]

I and a potential G2 push source are both on v2.5.5.0. I show all sources to see him and he is the only G2 source (the rest are ed2k). There is NO timer for him. It is blank, but the potential ed2k sources have a countdown timer. If I right-click on him and select 'Access', I immediately get in his queue. I've seen this happen twice now. Anyone else seeing this?

[ailurophobe]

Maybe you were already queued in ED2K? Shareaza would not IIRC automatically ask for a second connection, but if you ask for one manually the Shareaza in the other end will by default accept it just fine.

[ceriank]

Actually, I think I may have already been accessing another file or two of his over G2 and just didn't notice. You may be correct, however. Thanks.

[ceriank]

Having made some more observations, I'm still not absolutely convinced that the 'simple explanation' is the correct one here. Setting that aside for the moment...

Here is another aspect resulting from my observations:
1. All sources visible (several ed2k and no G2)
2. Search for G2 sources using 'urn:sha1:hash'
3. One G2 (push) source found (2 slots, 7 waiting in queue) and I confirmed that this source is not listed for any other files I'm downloading.
4. Source is added to downloads list and when I go look at the file the countdown timer is at about 45 seconds for that G2 source.
5. When the timer reaches zero, poof the source is removed from my downloads list.
6. Tried double-clicking on result from search window and steps 4-5 repeat.

Would someone help me to understand this behavior and/or provide an explanation.

[ceriank]

Ok, I've got a partial handle on this. The G2 (push) source was already queued on another set of files (apparently we have similar tastes).
But I still don't understand why the 45 second countdown followed by disappearance as a source... shouldn't he/she have stayed in the list as a potential source for more than 45 seconds?

[ailurophobe]

Connection.TimeoutHandshake == 45s

[ceriank]

[brov]

Push source is not contacted directly. To be able to download from such source the client must know hubs connected to it, to initiate reverse connection. As clients can often change hubs, ip, etc, or you can't accept incoming connections, 45s seems to be reasonable time.

[ailurophobe]

Yes, for a push source if the connection time outs, push route expires. This is actually the correct behaviour since the reason for a push source not answering in 45 seconds is usually that the route has become invalid already. Although, does anyone know if the "exceed query limits, ignore" or "core overload" respond to push connections to keep them alive?

[ceriank]

Thanks for the explanation.

My line of thinking in this case was that since (I eventually noticed) I already was in that source's upload queue (for two files... one actively downloading), I just assumed that somehow an 'exceeded queue limit' type message would somehow get passed on to me within 45 secs (by the hub, if necessary) and reset the timer to a higher value instead of delete the source. The G2 push source was Shareaza 2.5.4.0, I forgot to mention. I'm on 2.5.5.0... which rocks, by the way.