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

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.

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!

À+

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

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?

Attached Images

picture 2a.png (34.5 KB, 601 views)

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).

À+

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

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.

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.