DC Linux/Unix Hub Software??
Moderator: Moderators
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
DC Linux/Unix Hub Software??
i know of open dc hub, but it seems very unstable, and uses one thread for each user! (arghhh!!) :-S
what are my other option, and are they any good??
thanx
Chris
what are my other option, and are they any good??
thanx
Chris
1. what's wrong with 1 thread/user? Apache uses 1 thread per connection, too - that's usual in the *nix world. The hub I'm developing (currently for Windows, but I intend to port it to linux) uses 1 thread per user, too.
2. there's also DCTC hub, at least version 0.1.2 is stable, CCG 3 (anime hub with 700 users limit) has been running it for a long time now
3. OpenDCD has a linux version, too. not sure how (un)stable it is though...
2. there's also DCTC hub, at least version 0.1.2 is stable, CCG 3 (anime hub with 700 users limit) has been running it for a long time now
3. OpenDCD has a linux version, too. not sure how (un)stable it is though...
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
sorry, i was talking about opendcd.. my bad!
however 1 thread per user puts a lot of strain on the processor i should think.. or so i've been told!
however the *real* open dc hub that were now looking at seems very nice! Does anyone have any experience using this hub s/w, and could you tell me it's strengths/weakness' and where to find any improved versions etc etc?
thanx again! (please excuse my [rare] ignorance, hehe)
Chris
however 1 thread per user puts a lot of strain on the processor i should think.. or so i've been told!
however the *real* open dc hub that were now looking at seems very nice! Does anyone have any experience using this hub s/w, and could you tell me it's strengths/weakness' and where to find any improved versions etc etc?
thanx again! (please excuse my [rare] ignorance, hehe)
Chris
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
It really goes on a few things;
First one is the server setup... multi-processor systems cope much better with multi-threaded applications.
However, the problem with the multi-threaded approach and a DC hub server is that 90% of the activity is relaying messages to the other connected clients. This means that the bulk of the time is spent switching between the different thread contexts.
I'm no expert on this, but I have done various tests and have seen that a single-threaded setup is indeed the more efficient route for a DC hub server. I believe Nev has also done some testing in this area and come to the same conclusion, as he was the one that reassured me when I was first exploring the different methods.
Neimad
First one is the server setup... multi-processor systems cope much better with multi-threaded applications.
However, the problem with the multi-threaded approach and a DC hub server is that 90% of the activity is relaying messages to the other connected clients. This means that the bulk of the time is spent switching between the different thread contexts.
I'm no expert on this, but I have done various tests and have seen that a single-threaded setup is indeed the more efficient route for a DC hub server. I believe Nev has also done some testing in this area and come to the same conclusion, as he was the one that reassured me when I was first exploring the different methods.
Neimad
-
- Posts: 202
- Joined: 2003-01-06 06:22
- Location: Salford, England.
- Contact:
On Linux a thread is a lightweight process.ender wrote:1. what's wrong with 1 thread/user? Apache uses 1 thread per connection, too - that's usual in the *nix world. The hub I'm developing (currently for Windows, but I intend to port it to linux) uses 1 thread per user, too.
Each process gets a default of 1ms to execute between context switches on Linux with the current stable (vanilla) kernel (unless you do a sched_yield() or block for IO).
A scalable Hub should take ~1000 user nowadays. Which means 1000 threads would lead to really bad overall performance on a busy server, and the "ping latency" for the hub would be way high. Worst case scenario is very bad!
Opendchub is the best hub I've found on Unix. It uses select() and spawns multiple processess for each 500 users (default, but configurable). I've tested it with ~600 "fake" (perl script) users on a p200/32mb and it ran without problems.
The ONLY good reason for using a 1 thread for 1 user aproach is
that it's easier to code.
(Btw: Apache 1.x uses processes, while Apache 2.x uses threads and performs better...)
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
Why does it do this? I know theres a limit on select() with regard to number of sockets, but is there any other reason to split it up? Besides, there is poll() which is pretty much the same except that 1) poll can take any number of sockets 2) it transfers slightly more data and is therefore slightly slower. Done simply because of speed?Dj_Offset wrote:Opendchub is the best hub I've found on Unix. It uses select() and spawns multiple processess for each 500 users (default, but configurable). I've tested it with ~600 "fake" (perl script) users on a p200/32mb and it ran without problems.
-
- Posts: 506
- Joined: 2003-01-03 07:33
i would go for a select-approach... i have always liked select, and yes as sandos express there is a problem with select with regard to number of sockets, but it can surley be solved fairly easy with some queueing, timeout and other things (will not go into details)..
programming-is-like-maintaining-a-relationship-and-haveing-many-relationships-forces-you-to-use-many-looks-on-your-door-if-each-girlfriend-has-a-key-to-your-appartment-ly'ers ,))
programming-is-like-maintaining-a-relationship-and-haveing-many-relationships-forces-you-to-use-many-looks-on-your-door-if-each-girlfriend-has-a-key-to-your-appartment-ly'ers ,))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
Poll() is not implemented on all platforms, thus select() is more portable.sandos wrote:Why does it do this? I know theres a limit on select() with regard to number of sockets, but is there any other reason to split it up? Besides, there is poll() which is pretty much the same except that 1) poll can take any number of sockets 2) it transfers slightly more data and is therefore slightly slower. Done simply because of speed?Dj_Offset wrote:Opendchub is the best hub I've found on Unix. It uses select() and spawns multiple processess for each 500 users (default, but configurable). I've tested it with ~600 "fake" (perl script) users on a p200/32mb and it ran without problems.
From the poll man-page:
"The poll() systemcall was introduced in Linux 2.1.23. The poll() library call was introduced in libc 5.4.28 (and provides emu-lation using select if your kernel does not have a poll syscall)."
So you can use poll() if you use the GNU libc.
Why does it split up into threads of 500 users per select()? I would guess to improve server latency.
Btw, Linux 2.6/3.0 (whatever it is going to be) will have a new epoll() which is supposed to be much more efficient and faster.
I wrote QuickDC - A DC++ compatible client for Linux and FreeBSD.
Yeah, I know. Must say Im very surprised linux didnt have any better poll-interface. It seems that Freebsd has a nice interface: kqueue/kevent:Dj_Offset wrote:Btw, Linux 2.6/3.0 (whatever it is going to be) will have a new epoll() which is supposed to be much more efficient and faster.
http://www.kegel.com/dkftpbench/Poller_bench.html
-
- Posts: 506
- Joined: 2003-01-03 07:33