I know bitzi supplie a source code for HUGE. Was there a java version of the source code? If not, how difficult is it to convert the source code (I imagine that it is pretty tough)?

Will BearShare be implementing HUGE? Vinnie has said in the past that he will not have multisource downloads w/o filehashes. I am sure LW and BS have discussed this. As the two clients make up the majority of the network it would be nearly fully implemented if the 2 would support it.

Any timeline?

What benefits does HTTP 1.1 provide?

-gf

I know that Bitzi guys coded up a Java implementation at one point, but I don't think it's publicly available yet. I just sent a message to them checking on the status, though.

As far as HTTP 1.1 goes, its basically nice for two reasons:

1) persistent connections, so you don't have to disconnect when you've received your part of the file, and then reconnect to request another part.

2) the ability to simply connect without embedding precisely what you're asking for in the connection header -- this allows you to connect to everyone you can connect to, and then decide which parts of the file to request from which hosts. This is nice because you have a little more information (who you can actually connect to) before you have to decide which parts of the file to request from who.

I think Vinnie will implement HUGE, although I'm not positive. As far as a timeline for the hashes, it should be pretty soon. It's not at the top of our priority list, but it's not far from it.

Thanks.

Oh, and I just implemented the change to group same-size search results together. Do to the technical details of the code, the first group can contain files of the same size as other groups, but after that every same size file is put in the same bucket. I'm about to commit the code now.

i am very curious about this download mesh - could you explain how it is supposed to work and what its advantages are? have you any technical article available at limewire or the gdf?

--- thanks

off topic:
what do you think about implementing channel chat on IRC ? Gnucleus already does this, but its users are far too less...the channel is deserted...is it an option for some time in the future ?

All you fools dissing limewire don't know what you're talking about! This is f___ing amazing compared to the previous gnutella programs! Who cares about the stupid spyware! What do you f____ing expect for free??

The swarm downloads kick ***! Instead of limewire's usual 2 KB/s Im downloading at 30-100 constistantly! & since my network admin blocked morpheus/kazza (that a__hole) this is my main source of free sh_t!

Oh yeah, for you fools saying the swarm dl's dont work, you might need to leave limewire running for a while to get 'em to work.

THANKS FELLAZ!

I believe the download mesh he is refering to is where one client that hosts a file will also keep track of other clients with the same file. When the host recieves a request for the file it will also send information regarding other hosts where the same file can be found. This will allow for more hosts to swarm from.

-gf

nice that swarming works for a flaming ignorant with a highspeed connection beating on people who utter criticism. this is a beta release man and we are just trying to help the lime folks in making it even better. you might be glad because you can load your stuff with 30-100 now, but there are many many modem users who would be glad about 5-6. of course swarming is one of the greatest improvements ever in gnutella. but compared to swarming with morpheus and edonkey it is not a match at all. so relax and smile about the success at yours, but don't flame us because we would like to benefit as well.

Jay, thanks very much for the enthusiastic support, and I'm glad you're enjoying the program. I do really want to discourage anybody on the forums from personally attacking each other, though -- let's try to keep this a nice and clean operation, ok?

The final release should have significant improvements in a number of areas, although they might not be immediately apparent. We will probably be releasing another beta today with the new changes.

As far as the download mesh goes, the previous poster was correct. A download mesh relies on the basic observation that you can easily keep a record of who has successfully uploaded from you, storing their ip address. Then, when you respond to another query for a file that you have, you can also return the ip addresses of everyone else who has successfully downloaded that file from you -- this provides new peers for swarmed downloads extremely cheaply.

The mesh part really comes in when you request the file from one of the ips returned in the first list, and it returns another list of ips of hosts who have successfully uploaded from it, and so one. Quite quickly (and with very few messages) you can get a long list of hosts who have a given file. This addresses the issue of scalability in a whole new way, as you can easily know all you need to know (that they have the damn file) about hosts otherwise not within your network horizon.

Oh, and we should have mentioned that swarm downloading is completely turned off for modem users. We did this because there is a potential shortage of upload slots on the network if everyone starts swarming, and modem users (we thought) could not really get much out of swarming anyway.

We are, of course, open to changing this if given a good reason. Do the other programs allow swarming for modem users? Does it improve things that greatly?

Apologies for not mentioning the modem user exlusion sooner.

BTW, dl limit does not seem to work when you're swarming.

Right now, I have dl limited to 8 simultaneous, but I have 8 dl slots active from which multiple are downloading from 2 or more hosts.

DL limit SHOULD count swarming also. Right now it seems that I could have limit of 8 and still have 8 files downloading with each swarming from 12 hosts which in total would mean 96 active connections.

Not very bandwidth-effective, eh?