scalable network architectures (was RE: [Mono-list] Mono fitness for ircd project)

Matt Liotta
Mon, 3 Jun 2002 22:03:28 -0700

Sorry, bit of a typo on my part. I meant concurrent number of sockets.
If you want to support a high number of concurrent sockets that are
rarely active then real-time signals are the way to go. However, we are
getting off-topic, so we can finish this up on irc since we are sitting
in the same channel right now anyway.


> -----Original Message-----
> From: []
> Behalf Of Michael Poole
> Sent: Monday, June 03, 2002 9:43 PM
> To:
> Subject: Re: scalable network architectures (was RE: [Mono-list] Mono
> fitness for ircd project)
> "Matt Liotta" <> writes:
> > We were talking about scalable in the context of current number of
> > sockets. Real-time signals allow for significantly more current
> > than any other architecture.
> >
> > -Matt
> 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
> better.
> 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.
> -- Michael
> _______________________________________________
> Mono-list maillist  -