when you deal with gnutella, it doesn't matter which client you use--they all run the same protocol and thus form the same network. bickering over the various clients in pointless as long as everyone can find a client they like. that way, we *all* get access to their music :)

Thanks for the recommendations...

I haven't tried KaZaa, because of stuff like this:
http://www.salon.com/tech/feature/20...tal/print.html

I don't fear my browsing habits being "secretly sent to servers"... but I do run NT, and I don't need these silly little programs bringing my OS down... I've rebuilt it enough ; ).

Similarily, I haven't tried MusicCity Morpheus.... I can't ignore the hundreds of reports by users of this one ruining their systems. The music isn't worth the risk. On top of that, the authors propose no response to user complaints.

This is what I find a real shame... the most popular file sharing applications out there are either malicious or riddled with garbage.

Haha, fflewddur, I knew that, honest ; ). I shouldn't have put that "look for the clients with the most users" there... that's my general rule for proprietary clients such as WinMX.

You people that insist that Gnutella servents should have this feature and that feature when such a feature would have to be protocol-based need to read the Gnutella protocol, which I coincidentally just finished reading like 15 minutes ago or so. There you will find that the only thing that the protocol concerns itself with is searching for files that match a search string, pure and simple (of course there are ways to connect to other servents and stuff like that, but I meant functionality-wise). Napster and every single last other non-Gnutella file-sharing program out there is a product, not an implementation of a protocol. As products, they are free to put whatever they want to in them, from chat rooms to buttons that will cause your toaster to automatically make breakfast for you. Gnutella, on the other hand, is a file-search protocol, pure and simple. If one wants to chat with people, one generally doesn't use the Gnutella protocol, although from what I've heard some servents seem to implement features like that, but which are certainly not standard. Gnutella isn't even a file-sharing protocol, strictly; it is a file-search system, because the sharing goes on through HTTP (which will give RIAA lawyers all kinds of fun if they ever decide they want a piece of this over here). So those that demand chatrooms built in to their file-sharing tools (yes, I am aware of what I just called it), the ability to look at other peoples' files in a list, whatever, while those aren't totally crazy things to want (especially looking through a list of what someone has), you will have to either look elsewhere or perhaps try to get the Gnutella protocol modified. The version I just read was version 0.4, but I know there are modifications to it and there is now a version 0.6. If you come up with good ideas that are reasonable and realistic, you have a chance of having them become part of the Gnutella protocol. However, that will almost certainly not happen if you do not write a Gnutella servent, so if you are that interested and really want to have a say in the protocol you should do that. The protocol isn't that hard, believe me. If you can program and use network connections, you can basically program a Gnutella servent. Well, that's enough for now.

Morpheus (and Grokster) are essentially the same thing as Kazaa... they access the same network (just like the different Gnutella clients)... as for the spyware... I look at it as a nessecary evil... these companies need some revenue producing method... I personally don't use Kazaa all that often (once, twice a month, maybe)... I'm on Win2K and haven't had problems with Kazaa... when you install you get to choose which of these programs are installed with the exception of Bonzai Buddy...

fflewddur... I agree somewhat... some clients have been known to do bad things to the network (automated searches, dropping d/l's from dis-similar clients, sending bad messages, reporting bad network sizes, allowing large TTL's, etc) bickering is a nessecary evil in order to provide some forward momentum on the protocol... the clients need to maintain some semblance of order otherwise the whole thing could go to sh-t.

"Such a feature would have to be protocol based"

Not nessecarily... you can circumvent deficiencies in the protocol sometimes by using different methods... look at Limewire 1.7... it comes with a fully instant messaging utility built in... Gnucleus uses IRC for chat (although no one is ever on) ;-)... browsing hosts used to be common as essentially you have a web server running on your machine beacuse you need to upload via HTTP... I haven't used bearshare in a while but I know it used to have a browse host feature... Limewire also used to have a browse host feature... so all of these "features" are possible with the current protocol in place... modifications of the protocol to include these features would just make the network a tighter unit... I have read the protocol... it, like you said it really only covers the distributed search... so essentially all gnutella is, is a distributed search engine... but like so many developers have shown it is possible to get around these...

I mean a browse host feature would be as simple as every client simply keeping a HTML file on the computer... this would have a list of all the shared files... then you just make all of the files have URL's... I believe that's what bearshare does (or did)... most of these things are possible... and trust me I would love to help build the code for such things but I can't code to save my life... so that really limits me to simply suggesting things for the network...

"I code in my spare time, it doesn't cost me a dime"
 

okay Guest, then please come back when you have you deluxe client handy!

Meanwhile stop ignoring that good programs need time, a good team and indirect or direct financial support. It does not mean time is money, but it means if there would be money, there would be developer working on it. The mentioned budget is my first estimation when I should code a real good P2P for a big customer... team of 2-3 programmers, artist, testers, also expenses + ISP + homepage + documentation... not alpha/beta, no a finished and tested application after months of work, I would say it's pretty cheap. Half the prize would be okay for a simple client or even less for a early beta. If you ever had coded bigger projects (open source or full paid) you wouldn't run around shouting:

"yeah I have enough spare time and it's so f*cking easy to code a great program alone and all for free!" Ignoring reality, dude?

Hehe, I didn't say it like that, no need to put words in my mouth and make me sound bad.
You seem to be stuck on the idea programming costs money. All I'm saying is that is incorrect. I bet a lot of these clients were written by individuals in their spare time. As a lot of programs are.

Believe me I have the inspiration to write a client, but I'm too indulged in other projects now to start another...

You're right!
Programming costs time. What I ment is, if you have less spare time or need more for a project, then it is _very_helpfull_ to get paid for it. It is not a must. Sorry for misunderstanding!

Btw I believe and same for me. Still searching for a girlfriend that can code too. Having sex and coding same night, awesome. :)

Both chat and list browsing can be implemented without any modification to the protocol. A browse is simply a query packet with TTL == 1 and query string == " " (four spaces) and works with every client I've seen tested. Chat is a different protocol but can be easily incorporated into a client. Every person participating in a chatroom might share a ".chtrm" file ("Quiggley's Jazz Fusion Chat.chtrm" for example). The client knows what to do with this file when it's downloaded and automatically opens a new chat window for it when it is. In fact, you can run endless sorts of P2P services on top of gnutella by extending this idea (of associating a service with a file extension); proxying and auctioning are some of the first things that come to my mind.

The agitators are right! Current clients suck. But I'm pretty certain they will get better ;)

A client to client chat can also implemented by using IRC's DCC send protocoll.

It's well known and as big advantage it can even routed through well configured firewalls (e.g. Linux with IRC masquerading module). So users could chat to each other or setup individual chatrooms for friends... similar to eggdrops's party line. The extra traffic is at minimum, few bytes/s

Just an idea, Moak