Network servers should be system daemons. Having the server be inside of the client is a poor design, IF you want a good network. There should be one server running all of the time, no matter how many users log in, and runs if nobody is logged in.

The current mechanism is like having your web browser run as your web server. The current model is very Windows-like (a synonym for poor design) and maybe you have to go that way to make a cross-platform client/server without a lot of hassles, so maybe it is OK in that case. But, the question still stands: isn't a GUI network server a dumb design?

A Gnutella client is both a server and a client, so you would have to break part of it out into a server and that would just add more problems to what is already a complicated thing to do. You could have two things but most people want to know the "server" goes down when you quit the client, and the client shows all the server data plus the client data. It's not really a dedicated server.

You have source code, why not try breaking it apart and see how it goes?

I don't know why this is here in this section, can someone please move this to "general gnutella"? Thanks

I agree that it would be nice to have a gnutella client which consists of a daemon and (a) front-end(s).

But I don't see that it matters architecturally. As long as the client is multithreaded enough that the GUI doesn't slow the network response down, then it is perfectly valid to have a single program.

However, for CONVENIENCE I would LOVE a daemon which would launch with linux, detect when my ppp0 interface is up (dialup) and start sharing files and retrieving downloads I have specified either explicitly (file hash is known) or implicitly (search criteria given eg grep for filename, minimum bitrate, length of song).

It should have controllers built into the frontend that would let me easily turn sharing off etc, for when I really need all my limited bandwidth for something other than filesharing.

This architecture would help some people who have a firewall, in that the frontend could connect from a different server (ie one protected by firewall) than the daemon, which could be running in a DMZ, on the firewall or separate machine.

HTTP HTML sounds like the best controller interface for this to me.

My mp3 box sits under my stereo with no console, and I control it with lirc. I would so love to have napshare running on in all the time downloading whatever new songs it finds. But to do that the napshare "engine" would have to be separated from the GUI. Anything that is designed to run unattended, 24/7, should not require a GUI.

I originally posted this when thinking aboout how things like magicdev and napshare are strictly GUI programs. I also read an article saying that the only real problem with gnutella types of programs is that the server only works while people are logged in. This is the Windows way of doing things, because it is a fairly limited OS. I would rather see Windows programmers start to do make real servers instead of this type of program being used more in Linux/*BSD.

However, Napshare-like programs do have a bit of a reason to be linked, because they retransmit information found as a client. Maybe the way to
do it would be to have a non-GUI client+server
daemon, and a separate GUI control interface.

run gnut or see gtk-gnutella about the gnut deamon both are lame console clients

yeah, this is exactly the kind of Gnutella client (ehum local server) I'm looking for. We are several persons to share the same MacOSX machine and we all use Limewire. When one of us wants to log in you have to log out the open user session, which means you have to quit Limewire and stop all ongoing down/up loads. Would be much better to have a local server which can run as a daemon and start when the machine is booted, to which you can connect a client from the current user session. All requests would continue to run in the server regardless of wether the client deconnects. Is anybody working on something like this?