The Silent-Bob Edonkey Server
The Server with the necessary *OOMPH*

01/2003

Thanks to Nicko, Hamsterer und KGB Networks the English version of the site os online.

12/2002

The memory-problem is solved!
Lugdunum Master has found the problem. Older Emule Versions (<0.23) caused the problems with theis lowID bug. As long as the Emule developers won't implement a way to get rid of old broken versions i have to disable lowID clients on my server to keep it operating.
Without the impact of the "Emule-DOS attack" and a few tuning-tips from Lugdunum Master i could increase the number of clients to a stable 50.000.

As the new dserver can make use of more than one CPU, there is no longer the need to run 2 dservers on the same machine. And as one big server is better than to small ones, server #2 will be off forever.

11/2002

The #2 server was switched off and the number of clients allowed on the #1 server was increased to 25,000. There is a still unclear memory problem, which prevents higher user-numbers, and causes the server to hang often.

09/2002

The number of clients increased steadily.

09/2002

Thanks to the new version of the Lugdunum server i could increase the user number to 9000 per server.

08/2002

Thanks to the new version of the Lugdunum server i could increase the user number to 6000 and also permit LowID clients.

07/2002

I have been using the patched version of the original Donkey server made by the Lugdunum Admins for some time now. (http:// lugdunum.dyndns.org/kiten.html). Now the server runs stable finally. I have had no more crashes.

Now each server has 5000 users and they react to some extent faster to all queries. It now runs faster than with 4000 users on the original server.

I block Bot users, users with a LowID (they load the server heavily), and users with more than 5000 shared files. If the user has more than 1000 shares these are not used (the donkey is not suitable for mp3's etc. and this relieves the server substantially).

Spring 2002:

After a long time (I have had the computer under testing for several weeks) and after many different configurations i came to the following conclusions:

In my case the limit is the CPU and possibly the RAM. Network utilization is very low.

The server UDP code is not optimised at all. With approximately 1500 users the connectivity via UDP was simply ridiculous [<50%] (although at this time the CPU utilisation was far from 100%). Therefore i have decided to optimize teh server for high numbers of clients.

Since the dserver doesn't make use of more than one CPU (even with high numbers of threads) i have decided to run 2 dservers on one machine in order to be able to use both CPUs fully.

 Index    Technical    FAQ    Links   Contact