LW allowing firewalled UPs (to LW devs)

[et voilà]

Following the message from Gregorio on the GDF stating that LW had many UP firewalled, I checked the intra UP connections of my LW UP client (9 hours uptime): more than 50% of the connections had a listen-ip of a firewalled host! I then restarted LW (after being a leaf for a few hours) to see if is was an aggregation of firewalled UPs was hapenning over time: no! 15 out of 30 LW were firewalled and thus not accepting connections from leafs (no push proxies etc...). This is an area open for serious optimisations for LW 3.7! That is a lot of waste bandwith and query horizon!

Ciao

[stief]

Salut et voilà

I read Gregario's post on the GDF, but thought he got that info from his crawler. How did you determine that the Listen-IP was firewalled? In Connections I see a few NATed addresses like my own, but just figured their routers are opened so they can accept incoming like mine. I don't know how to properly read the tooltips on the incoming UP hosts, so would appreciate how to tell which ones are firewalled.

Merci--encore une fois.

[et voilà]

Salut Stief, long time no see. If you look in the ultrapeers tooltips, you can see the header Remote-IP: 67.xxx.xx.xx , this is your IP broadcasted to the Gnet. If you we're firewalled your Remote-IP header would read: 192.168.1.xxx or 10.10.10.xxx. It is the same thing for the ultrapeers, when they are firewalled they display the 192.168.1.xxx in the Listen-IP header.

BTW I saw in the CVS that LW team corrected this issue this monday for the next 3.7 due this week, great!

À+

[sberlin]

Just FYI, when LimeWire 3.7 is released it will contain significant fixes/additions to address connection problems and the ultrapeer election scheme.

[stief]

Sam--I just dl'd the jum242, which includes the MagnetMix hand. If this includes all the connections changes, they worked smoothly here, but I still see 15 0f the 30 UP's with 192.*.*.* Listen IP's

Merci et voilà. Encore un plaisir. Here's a sample of what I think, now, is a firewalled UP. Correct?

[et voilà]

Oui, it is firewalled, but since the core changes are on UP election. When the masses upgrade, no more 3.7 ultrapeers would become UP if firewalled, so in long term they will disappear. I think it is wise to let those dumb UP to connect to newer UP, because otherwise they would cluster themselves will older UP and make a large portion of the LW nodes to get low performance (+ they would consume lot of bandwith harrrassing newer UP to get their 32 gnet connections).

À+

[stief]

Looks like the current CVS changes to the connections code have some unusual results, but still lots of firewalled UP's (usually 2/3).

more connections at first--75 after 30 minutes; 83 after 80 minutes; 63 after 102 minutes, and 62 after 9 hours. I'm used to seeing 60 (30 UP + 30 leaves).

-acting as a leaf AND an Ultrapeer for more than 30 minutes? (enabling the incoming searches checkbox pops up the shielded leaf message, yet searches are rolling by faster than I can read, like an Ultrapeer). Details below.

-when 75 hosts, 36/37 UP's were incoming, and 21 firewalled.
-when 63 hosts, (33 UP's ; all incoming), still 21 firewalled
-when 62 (32 UP's ; all incoming) 20 firewalled

LimeWire version 3.6.15jum245
Java version 1.4.1_01 from Apple Computer, Inc.
Mac OS X v. 10.2.8 on ppc
Free/total memory: 13235960/90054656

-- listing session information --
Current thread: AWT-EventQueue-0
Active Threads: 180
Uptime: 30:56
Is Connected: true
Number of Ultrapeer -> Ultrapeer Connections: 36
Number of Ultrapeer -> Leaf Connections: 37
Number of Leaf -> Ultrapeer Connections: 2
Number of Old Connections: 0
Acting as Ultrapeer: true
Acting as Shielded Leaf: true
Number of Active Uploads: 1
Number of Queued Uploads: 0
Number of Active Managed Downloads: 2
Number of Active HTTP Downloaders: 2
Number of Waiting Downloads: 3
Received incoming this session: true
Number of Shared Files: 10072
Guess Capable: true

[sberlin]

Firewalled ultrapeers will remain on the network until we release a new version and people upgrade. Changes to CVS will have no effect on existing clients.

There was a bug in the development version for a short time period that allowed an excess of Ultrapeer connections, but we fixed it rather quickly. I'm not positive when Jens-Uwe built his version, but if it contained the bug then that is bad, as it was a rather serious bug. (Whenever you handled a search for a leaf, you erased your list of connections.)

That's very strange (and very bad) that you had Leaf -> Ultrapeer connections, yet also had Ultrapeer -> Leaf and Ultrapeer -> Ultrapeer connections.

We'll take a close look at the connection logic to see what may be going wrong.

Thanks.

[stief]

Thanks for the info

There was one jum version (244) that was quickly replaced with 245, probably in response to the CVS changes.

In case it wasn't clear, the leaf/ultrapeer combo seen yesterday lasted more than 30 minutes, but was gone for the later checks mentioned.