If hash is already in play and isn't expensive, then I'd like to see the checkmark as yes/no, rather than "maybe."

I like the idea of multiple meanings (coloured checks), but suspect this adds "unecessary" complexity.

I found the hash column under audio options, but no hash showed for images. Perhaps extending the hash display for other files would be an interim solution?

That's an excellent idea, et voila -- I'm surprised no one has thought of it so far. It's be terribly difficult to implement, but it's a damn fine idea.

Merci Sam, however my upload idea was much better as I recall. I was in the metro this morning, thought about that then I fell asleep because there was still 10 stations to go. Didn't think about it afterwards... so I forgot it. It's frustrating :mad:

In fact, after adding some debugging options in Java 1.4.2, OpenGL is ALSO enabled on that version (and I can see the warning displayed on the Console with Java 1.4.2 too)

I have seen yesterday the option "-Dsun.java2d.opengl=true" added in run.bat, and I have already tried to set it to false.
This has NO effect: the OpenGL pipeline is still used, on both Java 1.4 and 1.5 (where I see the warning on the console).
And images are still improperly displayed.

The kind of image corruption I get is when MULTIPLE distinct images need to be refreshed on the screen at the same time: this affects graphic buttons that are all refreshed at the same time, for example when the window is minimized then restored, or when moving the mouse across a row of buttons (one button needs to have its border flattened, and another needs to have its border raised, so both buttons need to be redrawn, and they will both display the same image, one is correct and the second is not).

I really think that this is not a OpenGL bug, but a synchronization issue within the new L&F theme manager (from jgoodies.com), where there's a shared instance whose member points to the image to refresh.

I DON'T have this issue with the current release of LimeWire 4.0.8 or even with Limewire beta 4.1.1 (without the jgoodies L&F), either on Java 1.4 or 1.5, but only with the current development version (4.1.5+) on both versions of Java.

The OpenGL message only appears since some recent beta version, when jgoodies L&F were enabled; and since then the images are incorrectly rendered, the display is desynchronized, and:

In addition when I move the window on the screen, all components are displayed at the wrong place, or the GUI freezes, sometimes Windows will hang. I really suspect that jgoodies-Looks needs its code to run only in the main GUI thread, and that it sollicitates some OpenGL functions which are not properly synchronized and can hang Windows completely if it is used out of the main thread.

Note that I tested the jgoodies Looks demo separately without problem (in addition, without the OpenGL warning on the console). So I suspect that the integration of jgoodies Looks in LimeWire breaks some assumption about multithreading safety.

It's actually because the setting of openGL got inserted into the gui's Main class. It'll be removed in a few hours.

I just noted that a few minutes ago and I was about to write about it. It's a bad idea to force a system property hardcoded in the code. I did not notice this addition in Main.java until one hour ago, when I commented it out in Main.java, and recompiled.
Now LimeWire works again perfectly without it (of course I have removed the forced property set on the command line in "run.bat", which was also added).
I think that these system properties, if they are needed, should be set manually by users, in their VM settings. However, given that LimeWire on Windows ships with its own VM instanciation program (limewire.exe) and that I doubt it will read and inherit from system properties that have been parametered in the Java Control Panel, may be we could (on Windows at least where the LimeWire.exe runner is used) enhance the LimeWire.exe launcher to get system properties from global Java settings on that machine (this would allow using the standard Java Control Panel to set such properties if needed).
This is too much an advanced setting, which may be useful only on platform that have problems with DirectX drivers, and that can be solved by setting Java2D to use OpenGL instead.

My display board is a Radeon Mobile 9600, a quite recent one, with the most up-to-date drivers certified compatible with Windows XP SP2 and DirectX 9c, and with much hardware support for OpenGL operations. However, OpenGL support in display drivers is often much less tested today. I think there may be a problem within my display driver for its support of OpenGL, or bad assumptions about OpenGL capabilities within the OpenGL support libraries of Java.

I have just tested a few OpenGL apps on my system, and found no such problems, so the problem seems specific to Java2D's use of OpenGL on Windows. So I think that the bug is within the so-called "OpenGL pipeline" managed internally by Java2D. Visibly, not all OpenGL operations made by Java2D are not properly pipelined, and Java2D suffers various synchronization issues with asynchronous OpenGL operations performed by hardware, even if the pipeline is used to serialize these operations in a single internal Java2D thread.

Hummmm.... Lots of bugs in the Sun Bug Database related to its support of OpenGL: most complain that OpenGL was mainly tested by Sun on Windows only, but with much less efforts for Linux.

Support of OpenGL for Linux is very recent, but still bogous, only in Tiger beta, where this is the only "portable" solution to have hardware acceleration for Java2D, because there's no DirectX on Linux. On Linux, there's an alternate interface for hardware acceleration, DCA, but its support in Linux kernels is still too much embryonic and much less widespread than OpenGL.

So may be we could enable and try OpenGL on Linux only, where it significantly improves the display speed, but it will not work correctly before Java 1.5 is officially released, and it won't work with Java 1.3 which is shipped with most Linux installations (including RedHat and SuSE). I think it's safer to keep the default support through DirectX, which is the prefered interface for most games on Windows, and on which most manufacturers have invested their development efforts. OpenGL remains a secondary interface for Windows, and Microsoft offers very little help for its effective support.

For Mac OSX users, this is not an issue: Java2D is ported independantly by Apple using the Mac drivers architecture.

Look into the Sun Java Bug Database for "OpenGL ATI Java2D", you'll see lots of issues. ATI boards are very common on PCs (including GeForce and Radeon models), and it's up to Sun to find a reliable way to work with ATI's OpenGL drivers on Windows. For now it does not work reliably.

Yup, we're not gonna enable openGL. It was in there by accident.

Thanks Sam. Sun officially says that OpenGL is still not supported in Java. The system property is only there in Tiger-beta for developers that want to test their apps and that want to help Sun with bug reports.
Sun is not even sure it will be ready and enabled in the final release of Java 1.5 for Windows (but OpenGL will be supported in Jav2D on Solaris, and probably on Linux). The support of OpenGL is being developed for a later better integration of Java3D in a future release of Java.

Surely in the interests of open networks and file sharing - we should not be re-naming ANY files we are keeping in public view. Am I right?

Well, renaming files should not be an issue today, given that files should be identified by their content (i.e. their SHA1 signature or the associated URN), rather than by their name.
The file name used to be necessary in old versions of Gnutella to download files by names, but this method is largely deprecated due to various filename encoding issues.
Renaming a file normally does not change its content, so it is safe for swarmed downloads (of course it will only change the name under which a file can be found for new incoming searches, but this won't harm incoming download requests by URN)

On the opposite, editing meta-data MAY change the file content and require it to be rehashed (for example when editing MP3 meta-data), meaning that the file will no longer be delivered for incoming download requests by URN (replying with 404 not found).

One bad thing is that some servents (GTKG?) attempts to retry the download when a download by content digest URN fails with 404 status, by using the old deprecated method of download by name, and if thy want swarmed downloads, the file will appear corrupted.

My opinion is that we should no longer accept incoming download requests by name, in all modern servents that supports downloads by content digest URN (we should return 404 not found if we have an URN for the file that may have been modified with its URN adjusted accordingly).

Well, you can still rename files in your OS browser, but there happens some quirks in LimeWire, because it does not detect the name change immediately. The only way to recover is to force it to refresh the directory, so that it will see the new name, will recompute the file hash (LimeWire does not know it is the same file content as before it was renamed), and then see the matching URN that can be honored again for incoming transfer requests.

But I have seen that this still leaves the file in red (unshared), if you don't refresh also the "Shared files" filtered list in the LimeWire Library.

Note however that you won't be able to rename a file as long as a upload or play is in progress. But the safest place to rename a file should be the LimeWire library, and not the Explorer, as long as LimeWire does not include a monitor for OS notifications about changes in the monitored folder. This monitoring option exists on Windows and probbly not on Linux (don't know about Mac OSX). If this monitoring was effective, we could rename safely all files from the Explorer, because LimeWire (in fact the Java Filesystem integration classes) would receive those notifications.

Renaming files
 

There's of course the obvious & simplest of reasons why a person would want to rename a file. Too often there are incorrectly/inaccurately named files being shared. 2ndly, some os's (eg: mac os9) which have a limit on the length of name. A longer than legal name can cause probs.)

OK , you guys obviously know a lot more about this than me. The only time I renamed a file was when I was a kazaa user (gag) ... I came across a game that took 3 days to download and it was a completely different game. I renamed it to "THIS IS NOT xxxxxx" and purposely kept it in the download folder so that other people would know. (On kazaa you can see all the sources and the individual file names) This led to a lot of messages from users asking me if the content was correct and I saved loads of people from downloading it.
The main problem was there was about 75 sources of this incorrectly named file.
Of course, I don't have the time to police the whole network!!! ;)

Another reason for renaming files is effectively the presence of fake files, whose names are returned matching exactly the query, but whose content is advertizing for some porn sites.
These files are easy to detect: lots of people share them without verifying the content, and so these files have unusually high number of sources (100 or more, matching the same SHA1 signature).
This affects mostly small video files (around 3 to 5 MB), but I have seen recently some fake Windows Media Audio files, that contain automatic links to these porn sites.
May be we should think about creating a distributed database of files identified by their SHA1 or URN with such deceptive unrelated contents.
For now one of the surest ways to detect fake files is that their name match exactly the query string: in LimeWire, query strings that are sent are formatted in lowercase, with no punctuation, and single separation spaces, and no common short keyword like "a" or "on" or "is". A query hit without significant meta-data and no verbose description, and a size below 5MB, and lots of sources (more than 30) is almost always a fake deceptive file.

Looks like the memory is still a problem with OS X.

Running jum353 over for a day eventually ate up 2 GB of hard drive space, resulting in a "out of disk space error", and eventually a java crash sent to Apple. "Exception: EXC_BREAKPOINT (0x0006) "

I've saved the bug report if anyone wants it, and did manage to grab a screenshot of memory activity a few minutes before the crash

(Running as UP, about ~.5GB downloaded, ~2 GB uploaded)

[edit--overly large screenshot removed]

Salut Stief, since apple java 1.4.2 update 2, my virtual memory didn't go over 600 megs. Are you using the latest java update?

ciao

re: fake files
 

verdyp, my understanding is that these results are generated from popular searches by certain sources linking onto the search. Sure, people may dwnld these accidently, else the offender(s) for generating these files may be accumulating them (Possible source of fakes. ) Rather than just using keyword filters (eg: .wmv, .exe, .jpg), which doesn't suit people looking for files in these formats, your suggestion sounds good. Brainstorming ideas? I made a suggestion in the New Feature Requests section for a size filter to be added to LW. This can help people in more ways than one & would certainly help to block out those automatically (I suspect) generated search results that are fakes. This is the size filter suggested & its advantages: http://www.gnutellaforums.com/showth...threadid=28255

Quote from the possible source of fakes link I gave above: 'Movie Pirates take ripped versions of porn movies and publish them on the network. (Copyright-infringment). The porn industry in response to this attempts to curtail the activity by flooding the network with video-clips that advertise the websites for such material.'

Quote:

Salut Stief, since apple java 1.4.2 update 2, my virtual memory didn't go over 600 megs. Are you using the latest java update?

Salut et voilà--Happy Thanksgiving
Yes, it's the latest public release.
LimeWire version 4.1.5jum353 Pro
Java version 1.4.2_05 from Apple Computer, Inc.
Mac OS X v. 10.3.5 on ppc
Free/total memory: 34005840/89513984

I saw CPU usage had definitely improved with the update, but I wasn't sure about memory, so I planned to let LW run all weekend. FWIW, here's what memory looked like after an 11 hours run (the earlier screenshot is after a 30 hour run)

[edit--overly large screenshot removed]

Resalut Stief, maybe the CVS versions fixed that bug. How old is the jum353 build?

Ciao et bonne Action de grâce à toi aussi!

Looks like Jens-Uwe last modified jum353 07-Oct-2004 21:58. Unless I missed the fix, I figure the problem is still in the CVS.

(and happy Columbus Day to Bushlanders).

Well I guest I'm lucky since the java update. I've got no problems since well before 7th october. Can you confirm that virtual memory behavior on your two macs? Since the last restart of my LW I've been UP, downloaded four short video clips and uploaded 2.5 gigs with LW now using 468mg virtual memory :eek: Well at least I can't complain!

Ciao

drag & Drop from LW's window
 

Was anybody aware that you can drag & drop from LW 4.1.5's windows onto iTunes. See: http://www.gnutellaforums.com/showth...826#post101826 I don't know if this is restricted to 4.1.5 or OSX.

Re: re: fake files
 

I know that these fake files are returned by automated replies, that match any query, not only the queries that contain some porn keyword (although a number of automatic repliers are only targetting porn keywords to send their fakes, exactly like what happens in newsgroups whos name contain some porn keyword, and that are targetted automatically by robots. This is less a question of copyright infringement than a question of abusive advertizing (spamming), something that webmasters of porn sites are used to do since long...

Now that nearly nobody looks for porn messages in newsgroups because of these spams that fill them completely, and that email filtering is becoming more and more effective, I do think that these spammers are trying other popular networks (and Gnutella is one of these)...

We are only at the beginning of such attacks, so the current filters implemented in servents as well as limitating usage policies may soon become ineffective to protect the network from such spammers.

The copyright holders use other strategies: they want you to download some non-deceptive content, but that use file formats containing active scripting and links which, when activated, will monitor and limit your ability to download possibly copyrighted materials. Some of them include some active components, which are not technically spywares, but profit from the P2P network to build a parallel topology that allows copyright holders to inspect easily the content of the network.

The focus of these components is not to monitor your search activity directly but to build an efficient search topology reaching rapidly the copyrighted materials, so that they will be able to list their ffective sources, even if these sources are proxied through other servents: these parallel network build a topology that can bypass these proxies, because they behave themselves as proxies on which those wanting to hide themselves will connect without knowledge. For now they will attack sources, rather than downloaders.

A counter-measure for this kind of indirect monitoring is to really make Gnutella share only fragments of files, and to accelerate the adoption of swarming downloads from multiple sources, so that no one shares completely a single file, but some fragments. This could be done by offering, like on Freenet, a spare space into which random file fragments will be cached when downloaded directly or proxied for someone else. (Freenet goes a little further, by encrypting this spare space, so that even the user owning that cache in its PC can't know what is in this space where the cached and fragmented content is only indexed by blind URNs, without identifying information).

I don't think we need encryption for this space, which could be feeded only when the content is proxied for someone else, and not directly for downloads. This space would be found on the network through Alt Locations with HUGE, or by active searches for URNs (when this will work someday if we later find a scalable DHT to manage them), but not directly through Gnutella searches by query strings.

Careful: Caching is dangerous legally. That way the programmers could be sued, and I assume we all don't want this.

Yes, dragging from LimeWire to another application works. It was added in 4.1.3 -- see the feature history at http://www.limewire.com/english/cont..._history.shtml .

Caching is a universal technic for programming.
A programmer could be sued, only if it does not offer to the user an option to clear its cache. The detail level at which a cache content can be consulted by the user is not defined legally: a user just needs to know that there are data in this cache.

If it was so sensible, there would be no legal use of any proxy even for the web navigation. What is critical here? Are there legal requirements on what a cache can contain? Must we maintain a log of remote accesses to this cache? If so, we should also add a log for past downloads in the current Gnutella. I don't know the legal details, and I don't want to know more about it. If you are informed about such things, then don't program it, but let others do it, notably if such legal constraints do not apply to this programmer.

In US and on the Internet, until there's a legal constraint not to do so, you are free: what is not forbidden is authorized, and something can be forbidden legally only if there's a public statement about such regulation, and efforts have been done to make these constraints publicly accessible.

In France, a law is considered public and known, if it has been published in the "Journal Officiel" and some other private publications and newspapers covering the area of application.

In the European Union, a directive cannot apply to any member country before it has been backed by a national law defining its level of application: a member country can choose not to apply a directive, and can be attacked face to a European Court if there's no such law after a dead-line date, but even so, that Directive will not apply before there's a matching national law.

i have a problem with the beta i use it for mac os x 10.3.5 and it connected yesterday but now it isnt connecting at all

Memory issue
 

Just a short update for LW 4.1.5 (since I changed over from dialup to adsl last night): after about 10 hrs Real memory use was 620 MB, VM at 1.1 GB. But after I cancelled some old searches from last night & some completed files, Real memory dropped back to about 530-40 MB.
I'm just a bit curious b/c in my java folder in the apps utilities folder there's both Java 1.3.1 & 1.4.2 Plugin Settings files. Also in my OSX/Lib/Internet Plugins/Java Applet.plugin is for Java 1.3.1 I presume these are for my browsers?! I've wondered whether I should delete 1.3.1 settings file at least!?

LOTR: I would not touch to that if I were you, they do not have influences on LW. I would wait until LW beta 4.1.6 goes live to test the VM issue with open searches because I remember fixes by LW team related to that later than the 4.1.5 release. As said before, the VM issue is gone for me. Maybe it is because of changes in CVS. Either that or the only change I made to the CVS version fixed the problems (banning many Gnet client abusers).

Ciao

Well! Congrats on the ADSL (at last!) LOTR. You can always confirm which java LW is using from the sample bug report in prefs.

et voilà--Thanks for yesterday's reminder to try on both machines.
I ran both the G3 and G4 for more than 18hrs (as UP's; the usual 2 GB+ of uploads and a few big swarmed downloads), and the VM never went higher than 800 MB's on either machine, so I couldn't repeat yesterday's results.

I ran out of time to see if repeated "browse host" might be the factor, since that was what I was playing with mostly before. Browsing a host with lots of shares is still the number one way to get a non-responsive screen here.

I did do a safe boot/permission repair on the G3, though. Perhaps that might make a difference for you too LOTR (I'd be interested in hearing if it does).

btw LOTR--has your ISP set a monthly cap on the bandwidth? Automatic throttling starts here as soon as bw exceeds 70 GB in the last 30 days.

Believe it or not, doing lots of browse hosts may have caused it. There was an issue we noticed with Sockets not being properly closed while doing browse hosts. I believe that's been fixed in CVS.

If you do happen to be able to repeat the problem though, please let us know what you did to reproduce it.

LOTR -- how many searches do you generally have up, and how many did you kill to reduce the memory by 100MB? When you say you cancelled some completed files, does that mean the download was still in the download table listing "Completed"? About how many of those were there? Do you know if those downloads had lots of sources while they were active?

Sam: any plans to support the partial files sharing source mesh specific to bearshare 4.6? I think a basic ask a read support would be enough as LW already shares partial in the normal source mesh. There are now a lot of bearshares on the Gnet and it would be great to get those ressources available.

Ciao

Thanks Sam.

Will a search for "browse" on http://limewire.org/fisheye/changelog/limecvs/ point to when the changes were made?

Sorry--I've been having trouble keeping up with the changes through the following links. If you can suggest some updated links, TIA.

http://www.limewire.org/jira/secure/Dashboard.jspa (returns a 500)
http://www.limewire.org/nightly/tests/osx/index.html (showed 0 tests recently, but back up again now)
http://www.limewire.org/nightly/clov...lts/index.html
http://www.limewire.org/nightly/clov...istorical.html (major revisons going on?)
http://bugs.limewire.com/bugs/home.jsp (too overloaded with this long run of 4.1.5?)
http://www.limewire.org/ (any chance the opensourcer credits will be updated soon?)

I generally only do one at a time with the exception of a couple last night. 5-7 search results I guess I generally keep up. Sometimes it gets twice this size before I think about ridding the older ones. The search results I left up overnight was around 10 or so, & I deleted all but one but did some more searches (I have 7 up now & ram is 510 MB but increasing at around 20 KB/s.) (I just deleted 6 of these search results but it had no effect on ram.)
There were 5-6 files listed as 'Complete' that I deleted from the dwnld list. Sources for the dwnlds ranged b/w 1-3 (generally 2.)

Slow to respond: I had a troublesome dwnld would reach 100%, verify to 99% & rebegin dwnlding at 80+%. I happened 4 times before I deleted it.

Oh I didn't notice exactly when it happened but certainly not immediately after I deleted that file, certainly after I completed another file 5 mins later, the ram use jumped down to 480 MB.


stief I not only feel I'm off crutches, but I can run, not only walk, lol. Services here are not as advanced as many other places. On my plan, 'so-called' unlimited everything. Except if 3 things are true: the isp is stressed, I dwnld over 8 GB in a mth & I'm within the top 5 or 10% of heaviest users my speed will be capped but only until one of the above 3 conditions no longer holds true. I was on the phone at lengths about this today. This wasn't what I understood when I 1st signed up (the fine print/obsure link.) I'll try a safe boot later today (this is the land of tomorrow.) Which means you should all be in bed right now, lol.

LOTR--here's an old link re bandwidth capping, but it does cover most of the arguments.
http://slashdot.org/articles/03/09/22/1744232.shtml

btw--if you run as an Ultrapeer, keep an eye on the bandwidth: I'm seeing up to ~15KB/s (can lead to about 1 GB/24 hrs). This used to be about 1/2 as much, but has been creeping up in the last few months as far as I can tell.

Anything need testing this weekend?

If 4.1.5 and even jum353 far enough behind the CVS, I suspect using either would not very useful.

iTunes DAAP support (iT Sharing Prefs)
 

I was wondering if anybody can fill me in about Digital Audio Access Protocol & how it works in LW?

Stief: I forgot to do the safe start, but did do it a few hrs ago & repaired permissions, at present ram 311 & 735 MB for VM. I'll see how it goes after many hrs.
Actually I have a suspicion that if you leave already completed dwnlded files on the dwnld list, it accumulates ram. After many hrs (before I did the safe start), I deleted about 6 completed files off the list & ram seemed to jump down a bit (again.) It might be just my imagination. It won't happen anymore b/c I've set it for autoclear completed files.
stief I'm not brave enough to run as an UP. I'm at the bottom end of adsl so it's probably not worth the effort. I'm already over 3 GB in 5 days, lol. That's despite trying to ease up a bit at times.

Salut à tous,
This week a lot of code has gone through CVS:

Now LW doesn't send QRP with the hash tables, the UP no longer pass through hash queries (that LWs never used anyway). LW only takes now magnets with URN AND an IP address. This reduces traffic for UPs.

LW now prefer using UDP hosts caches before trying Gwebcaches, reducing gwebcache traffic.

Firewall to firewall transferts updated. As well as alternate locations.

I wonder when LW will post an updated beta, it's been what 2 months since 4.1.5? Lots have changed under the hood since.

LODR: are you using the JUM's build?

Ciao

No.

Just FYI, the UDP attempts before GWebCaches aren't on the mainline yet. Once that's all completed we'll merge it in & likely put out a beta. Since GWebCaches are so overloaded right now, we don't want to put out another release till we can make sure they won't get further overloaded (and also make sure that clients can connect faster initially).

Thanks for this marvelous change. As LimeWire represents alone (in all its versions) more than 60% of all traffic to GWebcaches, this would be wonderful to reduce this traffic by alternate host discovery methods like the new UDP caches.

I have seen the traffic on my cache multipled by 5 in the last few weeks, so I have done some major rewrites of part of its code in my new version 1.3, for tripled performance.

This version now also makes a more rigourous check of URLs, and contains now a very basic active checker for the submitted IP:port of hosts, plus some other checks for known IP or port numbers that cause problems.

Also for LimeWire's active search of hosts by locale (which may require lots of connections with some locales to find a matching one), my cache now starts implementing a filter for the host addresses returned, so that a minimum number of returned hosts will at least match the querying country, region or continent. However my cache will still return a significant number of hosts belonging to any region. I may enhance the filter to also take into account linguistic data about each country or territory, but this requires some tuning of threshold parameters.

You can see how I detect them simply by looking at the web pages of my cache on rodage.net; the detection is based on statistic files published daily by each of the 4 RIRs, which I preprocess to allow fast search of querying IP. For now I update the preprocessed IP-to-country maps manually, every few days, but they are generated automatically by a script that I will enhance to perform all in one pass; I will soon implement a more automated updater, that will allow maintaining these maps at least once everyday. Today, 176 countries or territories seem active on Gnutella (some territories don't have IP delegations, and use assignment from the main country to which they belong).

Note that some hosts belong to the 'EU' region which is any country in the Europe/Africa region managed by RIPENCC, and some other belong to the 'AP' region which is Asia/Pacific managed by APNIC. Finally very few hosts use IP addresses that are still not registered for use by any RIR, and that I assign within a special code region '__' representing the Earth (this most often comes from new IP blocks recently delegated by RIRs to LIRs or ISPs, but whose usage still lacks some info published by the LIR or ISP; with the new RIR policies about IP assignments, this should appear much less often than before, and in a near future, such IPs will not be usable at all on Internet as long as they have not been registered by a RIR; some of these addresses also come from change of delegation between RIRs, notably by transfers of legacy European blocks from ARIN to RIPENCC).

My cache also now keeps 1000 hosts instead of 400 before, and returns 50 addresses instead of 30 before, to reduce the number of requests, and the number of occurences of repeated requests. 1000 hosts represents approximately the number of hosts sending valid updates now every about 20 minutes. I have also reduced a bit the minimum delay allowed for repeated accesses from 30 minutes to 20 minutes.

The next major version 1.4 of my cache is coming with faster operations, but more complex code. For now the version 1.3 of GWebCleaner contains only the most important and basic changes to accelerate it, but its code is becoming tricky. I expect being able to manage more than 5000 accesses per hour during peak hours (for now I can only manage about 3000 during peak hours, and 16000 during offtime hours).

Re: iTunes DAAP support (iT Sharing Prefs)
 

Share some tunes in LimeWire (mp3, m4a, aiff, wav and m1a are supported), launch iTunes on an arbitrarily computer in your LAN (in most cases the same machine where LimeWire is running but you could use different machines if you want). In iTunes you should see a new Playlist right next to the Music Store Playlist pretty much on the top (LOTR's LimeWire Tunes). Click on it and... Or do you want to know the technical details?

magnets
 

This will make Bitzi completely unusable.
please change it to:
Only magnets with URN and IP OR with URN and file-name OR with URN, filename and IP.

A magnet with file-name should only initiate a search for that filename so it isn't more strenuous than a simple search request/query.

Else you take away many uses of magents (for example posting files when you don't have a stable IP or a webserver).

Re: iTunes DAAP support (iT Sharing Prefs)
 

Hmm, I have 2 folders: one called Lotr's LW Tunes & the other called 'LW'. There seems to be a significant difference in no. of tunes b/w them. What does the 'LW' song list represent? Oh I noticed under Control menu there's an option for disconnecting Lotr's LW Tunes (CMD+E) as though it's a mountable volume (but there's nothing mounted on the desktop.)

So how does this work exactly? Who shares my files is it other p2p users or other iTunes users (I'm a bit lost here, lol!) And what's the difference b/w sharing my iTunes Library via added share folders & using the above function? And what if you have both?

OK, the LimeWire Playlist (somewhere at the bottom, a light blue icon with a clef on it) is LimeWire's "old iTunes support". It is based on AppleScript (thus Mac only) and it simply copies complete downloads to iTunes.

Lotr's LW Tunes (looks like a stack of icons, dark blue and a clef on it) is the new iTunes support. If I interpret your messages correctly then you have never seen iTunes Music Sharing in action? Please take a look at this page (especially the movie).

http://www.apple.com/support/itunes/...ent102094.html

DAAP is just a different name for what Apple calls iTunes Music Sharing. The files you're seeing in the playlist are the files you share with LimeWire. The playlists are only visible and accessible by computers on your LAN or WLAN and only via iTunes. Whenever you double click a song it is streamed from LimeWire to iTunes.

So what is DAAP? It is a server with a database, a transaction manager and a streaming component.

You can have both functions enabled but it's somewhat redundant.

Pro "old iTunes support"
- copies files to iTunes and you can burn them onto CD

Con "old iTunes support"
- duplicates wherever you look
- Mac only

Pro DAAP
- the music stays where it is and is simultanieously accessible by multible computers (no need to copy the music across the LAN)
- works with any computer (Mac, WIndows, Linux whetever). The only exception is that the music can only be accessed by Mac/Win since iTunes is only available for these systems.

Con DAAP
- doesn't copy the music to iTunes. I.e. you can't burn it directly.

Re: magnets
 

I personnaly only use Bitzi to verify if files are legit when I download. URN without IP means searching the network and means too much traffic for UPs as of now. I hope someone implements a DHT for URNs, as it seems to be the only efficient way. We'll have to wait to see.

Ciao

Actually we do accept all types of magnets; only in the case there is nothing but a sha1 in the magnet we display a warning message that the user will need to start a search manually.

@zab: Then it's another situation :-)

The Bitzi-Magnets will then still work and I have nothing to complain about it (Nothing to complain... Darn! ;) ).

I just noticed that a BearShare 4.5.2.2 was able to successfully grab 40 or more .jpg's from me without triggering a "banned greedy client". Good! Looks like they have successfully implemented something like client-side queuing, and know when to request the next file.

Any chance LW will do the same?