wait a minute... i have only incoming hosts. shouldn't i have at least one outgoing?

Also: Almost zero dropped I/O. Used to be much more w/ 2.9.11

1) There are some patches for the progress bars to show which chunks of the file have been downloaded, - but since LimeWire should download in the correct order beginning at byte 0 ending at the last byte, (at least recent versions do so), seeing which chunks have been downloaded should not be interesting at all.

2) The dropped IO column is hidden by default, like the rest of the connections tab so it won't lead to any misunderstandings for most of the users.

3) Java Swing does not offer you much flexibility as far as the look-and-feel is concerned. It's probably not worth the effort to try and add some real skins like Shareaza has them.

All of those GUI issues should have VERY low priority compared to new features like push-proxy, DHT or Partial-Filesharing. I wouldn't mind if LimeWire had only a command-line interface if it had all those others features instead.

Why should you have an outgoing connection if you are an ultrapeer? You might have one when you connect for the first time but the longer you stay connected, the more likely you are to have only incoming connections.

The number of dropped IO messages are lower because of pong caching. LimeWire does not sent as many pongs as it used to, so naturally less of them are dropped by flow control.

trap, I agree with what you're saying about the technical aspects of LW, but the first priority is the user. B/c w/o the user, gnutella and LW are nothing. Say if PC people go to Kazaa instead of LW, b/c they don't like the GUI, that's one less person uploading and sharing and contributing to the network. The network works on the basis of its wide user base, and at the very least, LW has to maintain its current user base, and ideally increase it. While other gnutella clients improve their GUI, and seemingly, to the casual user, thus drastically increase the effectiveness of the software, LW loses out if they don't at least keep pace. And this is much more applicable to PC users, who have such a wide variety of choices. If the people want eye candy, and it takes a little eye candy to get these people on LW and share, I'd want a couple more thousand users sharing than a fixed resume button.

trap_jaw,

thanks for the info regarding the incoming.

improving gui vs improving core: i completely understand your points. you represent the programmer's/power-user's point of view.

otto normalverbraucher perceives things differently. the look and feel has lots to do with subjective perception of performance, coolness and how new and advanced something is.

i'm caught somewhere in between these two but i realize there needs to be a balance, and currently, there's an exclusive emphasis on making the core better, and that's bad.

the fact that these columns are hidden (because they display misleading info?) doesn't solve the problem. the solution would be some clearly readable stats regarding requested/sucessful/failed uploads and dropped/missing messages. it is reassuring to know that your uploads actually arrive somewere.

regarding the progress bars: if a host downloads from 4 other hosts, it can't possibly start at 0% with all four of them. and what about other vendors? do they also download starting at 0?

looking at the questions in the forum, it seems that at least some of them are misunderstandings because of the GUI being unclear.

i'm sorry i was so rantsy earlier. it's the old story of industrial designers and engineers. they tend to have very different ideas of what the probem is.

I noticed Sam is also working on the related (?) progress bars. Sorry to hear you have less interest in LW. You really should treat yourself and benefit so many of us by getting a Mac! Maybe we can respark your interest in LW. Let's start a fund to make up the difference you think it would cost you to switch! I'll throw in $CDN 20 for starts--anyone else want in on the fun of switching TJ? :D

OK. Still, Why should these networks be so much better at longer files? Packets are packets, or is Java the main factor here? The RIAA scares don't seem to have cut down on the gnutella users, but perhaps the kinds of files being shared has been affected. Is gnutella's "music speed" related to flooding the network with finding multiple connections? Just musing.

I couldn't reproduce the missing text without reinstalling, and I'd trashed the OSX installer--you're probable right that it was the background colours because the text is white on a gradient blue in OSX. The text showed in other themes offered (Windows style--noticed the striping is much more visible). However, font size is very different between the "OSx" [sic] default and the other two options (black and default), and wouldn't revert to the larger OSX font in Advanced Stats.

This may have been responsible for a freeze. I was in UP mode on a direct connection, and after the freeze I haven't been able to run as an UP since.

Leaf mode is quite stable though; searches work as good or better; downloads still require kill/redownload (no repeat required) babysitting; but uploads are still choking after the initial burst. I was puzzled by one "urn get" upload: Does this mean the 2.9.11 host was uploading based on an urn search? The new stats sure give more to think about, and look to be very useful for figuring out why I see so little upload success whether connected directly or behind a gateway.

Re the gui/core priorities, I respect the need to make the core the priority. It does get irritating to read the occasional Acq user sneering at LW when 75% of Acq is LW and opensource work. Why don't the devs use more of Dave's open gui code, installer techniques, iLife integration and java implementation? Two (three?) months ago I though we'd see the benefits of a developer working on an OSX box in "two weeks" but I was wrong. Since there are some core problems that still seem to show up in the OSX (and XP?) forums, I guess the core work must continue, but do wish the devs would at least say they've contacted Apple and tried to find out how to integrate java, LW and OSX--esp OSX LAN's, packet management and firewalls. As you said trap_jaw, "the network core is not really something that you can discuss with the users".

Cheers

ps et voilà--do you host a GWeb cache? Wondered if that could be part of your UP ease of connection.

à Stief, non je n'oserais pas tenir une gwebcache avec mon adresse IP dynamique. Vive Anaheim!

pas de ducks--vive les canadiens. Moi, je suis de Saskatchewan, alors je n'aime pas le chef de Oakland. C'est presque Anaheim! Merci pour l'information de la GWeb. Just a thought. LW just crashed on me just before posting this--it was trying to be an UP. It's up to ~30 connections in ~10 mins, so I'll see. I don't have advanced stats checked this time.

I suggest you go reading user complaints in these forums. How many posings that go like "Can't download!", "Can't search!" or "Always awaiting sources" would you find? And how many postings saying "Help! LimeWire is too ugly" are you seeing?
In addition, as I said before, changing the look-and-feel of java swing applications is not exactly very easy. There were some attempts to do that, but they made LimeWire rather slow and unresponsive.

These columns are hidden because their information is not useful for the average user. For the expert, the info is not misleading at all. Information about successful/failed uploads etc should be in the advanced statistics (at least they are in the cvs version) but those stats are not very useful for the average user, either.

The four downloads start at 0, 100K, 200K and 300K. If you have N downloaders for one file, they will always try to download the first N chunks that have not yet been written.
I really don't know about all the other vendors but I assume most vendors do the same, to be able to preview files as good as possible.

Then the solution is better documentation.

I've not lost interest in LimeWire, I'm just working on a few other projects that require a lot of attention.

Other networks are better, mainly because users with big files are using eDonkey more often than Gnutella. It's not necessarily a question of better technology (not long ago most of the big movie sharers were using IRC). However in case of Gnutella it is also a question of technology. Without partial file-sharing big files are not distributed quickly enough so you have to wait much longer before the files are available and without push proxy firewalled hosts cannot take part in the download mesh.

The urn is sent by modern clients in the QueryHit, so you will know the urn of a file without specifically searching by urn. In addition if you get alternate locations from the download mesh all you usually know is the urn of the file you want (and not how some user may have named the file).

The gui code and the installer only works on OSX and LimeWire would have to create different versions for different OSs. That's more work for the developers. The java stuff should be more or less the same in Acquisition and LimeWire.

Wow--thanks for all the info. I'll be greedy and try and prolong this great class! This is better than finding a host that downloads great stuff at 80 KB/s! Sorry for being a leech--hope I can find a way to pay it forward or back. Any chance I can help you with a Shakespeare or Romantic Poetry class?

Acq has been using Java 1.4 since it was still only available in the Developer's preview version. Should using 1.3 or 1.4 make much difference to the gnutella experience?

Is the URN (Uniform Resource Name?) generated/linked to the sha1 hash (how can I see/know a file's URN?). I thought I read that searches by hash had been blocked/stopped.

I noticed two new columns in the connections pane: compression I/O and QRP %. I like the compression stats (saves having to turn on advanced stats to view), but noted of the hosts reporting, most show 0/40. I have both options for compression enabled, so I guess 0 means I'm receiving 0% of that host's message as compressed, and 40 means I'm compressing 40% of the messages I send out. Did I get this backwards/sideways?

I don't know how to read the infrequent data in the QRP% column (Query Returned P?). Any suggestions?

Cheers, and thanks again. LW has sure helped gnutella be better since those dismal times in November-January, even if I did log three beta crashes today!