RageIRCd v2.0 (bluemoon): Network I/O Engine
--------------------------------------------

$ Id: auth.txt,v 1.3 2002/10/24 13:55:06 rageircd Exp $
(C) 2000-2005 the RageIRCd Development Team, all rights reserved.

The network I/O engine in RageIRCd v2.0 is highly modular, and can 
interface with different system I/O implementations. This means that on 
newer operating systems, high-performance I/O interfaces can be used, to 
increase the overall server performance under high client loads.

From beta-7, the RageIRCd v2.0 config script should accurately detect and
display the recommended I/O engine module for use on your operating system.

Overview
--------

The following network I/O interfaces are available in RageIRCd v2.0.

   o) epoll - Linux 2.6 and above (and patched 2.4)
   o) rtsigio - Linux 2.4 and above
   o) kqueue - FreeBSD 4.3 and above (and NetBSD soon)
   o) devpoll - Solaris 7 and above
   o) poll - standard for older systems
   o) select - standard for older systems (limited to FD_SETSIZE fds)

Linux - epoll
-------------

Systems running Linux 2.6 and above should take advantage of the epoll 
(Event Poll) interface. This is the recommended option for Linux users, 
and uses 10-12% less resources than rtsigio. (Also available for Linux 
2.4 as a kernel patch and library.)

Linux - rtsigio
---------------

On systems running Linux 2.4 and above, the rtsigio (Real Time Signals) 
should be used. This controls I/O events using system signals. RT signals 
perform well under high client loads.

FreeBSD - kqueue
----------------

On systems running FreeBSD 4.3 and above, the kqueue engine module should 
be used. This is an extremely powerful I/O interface that uses next to no 
system resources, and performs extremely well under high client loads.

Solaris - devpoll
-----------------

On systems running Solaris 7 and above, the /dev/poll interface should be 
used. This is similar to the standard poll() system call, but uses a 
constant block device instead. This means that events are constant across 
I/O calls, and therefore uses just 10% of the overheads by poll().

Other Systems - poll & select
-----------------------------

The standard select() and poll() system calls are available on all modern 
systems. Although they work fine for smaller servers, they don't perform 
well under high client loads. Neither of them scale to any great extent.

Superior I/O implementations (kqueue, devpoll, epoll, rtsigio) should be 
used where supported. Otherwise, poll() is superior to select() as it is 
not subject to an FD_SETSIZE file descriptor limit. However, poll() begins 
to slow down considerably after a few thousand simultanious connections.

End of document.
