>From: Christian Biere <[EMAIL PROTECTED]>
>Date: Thu, 16 Aug 2007 23:35:53 +0200
>
>Lloyd Bryant wrote:
> > After switching to the GTK2 version (BTW: love the new layout), I've
>started
> > paying more attention to the sources for downloads. And I've noticed
>that
> > the port number shown in the "downloads->sources" tab are often (I
>believe)
> > incorrect.
>
>You can double-check with netstat or lsof if you think the ports are
>incorrect.
>
> > An example: I currently have two downloads running. The first is
>drawing
> > >from x.x.x.x:1320. The second is drawing from x.x.x.x:1332 (Same IP,
> > different port). But, if I attempt to "browse host" for either of them,
>the
> > new search is created as x.x.x.x:37465.
>
>That means 1320 and 1332 are most-likely the source port and those are
>incoming
>connections. The GUI never displayed whether connections are incoming or
>outgoing and still doesn't. The 37465 should be the listening port of the
>peer but it might only be reachable over UDP or not at all.
>
> > I'm assuming that this means that both downloads are from the same host,
>and
> > that the port numbers reported in the sources pane are incorrect.
>
>I'd agree with the former thought it could be two hosts behind a NAT or
>two peers on the same machine even. Unfortunately, the GUI does not show
>the GUIDs though they are exposed if you click on "Copy URL to clipboard".
>If these are tapazooged (the term formerly but not formally known as
>firewalled),
>you should find a PUSH URL in your clipboard which exposes the GUID.
>
> > Note that I have my "max downloads from a single host" set to one. But
>as
> > far as I can determine, I have two active downloads against this source.
>
>Yes, I think this limit happens to be ignored for tapazooged peers. I've
>seen
>it happening too.
>
> > OK - just for the heck of it, I started up another file download that
>the
> > above-listed host has available. I now have *3* downloads from that
>host.
> > The third one shows as x.x.x.x:1336. Browse-host still maps to
> > x.x.x.x:37465.
>
>LimeWire allows up to 3 uploads to a single address at a time I believe
>instead
>of just one by default.
>
> > I could see a situation like this happening, if the vendor (Limewire in
>this
> > case) had support for some kind of load-balancing scheme (i.e. requests
>for
> > downloads handled by one server, but downloads actually served from
>another,
> > as with some web servers). But AFAIK no Gnutella servent supports
>anything
> > that sophisticated...
>
>There are at least two possibilities. These peer could have multiple
>network
>interfaces and outgoing connections might be routed through another or a
>proxy
>even. Another possibility which I haven't checked is that the displayed IP
>address is actually that of the Push proxy. Are you sure the x.x.x.x:37465
>is actually a public IP address? If in doubt, try whois.
>
>
>--
>Christian
FYI - the x.x.x.x address is a valid public IP address (it traces back to a
pool for Verizon FIOS).
I looked at that particular Limewire host a bit closer, and this is what I
*think* is happening:
1. The node is a shielded leaf (tapazooged), and requires a push for
downloads.
2. I send the push request (via its proxy) to the main port number (37465).
3. The host creates a connection, on a varying port number (seems to be
sequential).
So I send a push request (via whatever node) to x.x.x.x:37465, but the
actual connection comes back on x.x.x.x:1375 (1376, 1377, etc, for multiple
file downloads).
So the port numbers *are* correct for the actual data connection. The port
numbering is *not* a GtkG bug, but an issue of how Limewire is creating the
connections for a push. There appears to be a legitimate issue in GtkG
where it shouldn't even request the second download if my "max downloads
from a single host" is set to one - I'm guessing it's getting confused
because of the alternate port numbers.
There *is* another issue in the sources pane that's related - I have one
download (currently stalled) that has *3* lines for the same source:
x.x.x.x:37465 "Requeued due to timeout"
x.x.x.x:37465 "Requeued due to timeout"
x.x.x.x:37465 "Giving priority to THEX"
And the THEX download itself:
x.x.x.x:37465 "Requeued due to timeout"
And in another file downloading from the same source:
x.x.x.x:37465 "Requeued due to timeout"
x.x.x.x:37465 "Requeued due to timeout"
x.x.x.x:37465 "Ignoring push flag at ..."
x.x.x.x:3771 "Downloading..."
So something about how that push source is operating is causing GtkG not to
clean up timed-out duplicates for the same (actual) source. I can't
manually clean them up, either, as a "Forget" on *any* of those will
eliminate *all* of them (including the active downloads, as I discovered the
hard way...).
I've seen similar issues with a Frostwire host (I think it was
4.11.something, but I didn't think to write down the version). So this may
be a reflection of some weirdness in older versions of Lime/Frost (since I
know the most recent version is up to 4.14.x). (The Frostwire host was also
shielded, and so required the same push method to initiate a download).
Lloyd B.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
gtk-gnutella-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
