scalable network architectures (was RE: [Mono-list] Mono fitness for ircd project)
04 Jun 2002 00:42:40 -0400
"Matt Liotta" <firstname.lastname@example.org> writes:
> We were talking about scalable in the context of current number of
> sockets. Real-time signals allow for significantly more current sockets
> than any other architecture.
I think this oversimplifies things. There are two important counts of
sockets: total sockets and active sockets. Which (or what else) did
you mean by "current sockets"?
Scaling up the total number of sockets is usually done by adding or
removing sockets one or a few at a time -- /dev/poll, kqueue() and
real-time signals all do this. select() and poll() require the app
list all sockets for each system call.
Scaling up the number of active sockets is done by reporting only
active sockets instead of status for all the sockets. Again, select()
and poll() do this poorly; /dev/poll, kqueue() and signals do it
If each active socket only requires a little bit of user-space work
(e.g. HTTP or IRC), delivering a signal for each one adds a lot of
overhead. Delivering activity notices in groups reduces this
overhead, and so allows sockets to be active more often. The cost is
that the app may end up waiting longer before it learns of activity
for a given socket.