scalable network architectures (was RE: [Mono-list] Mono fitness for ircd project)
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: email@example.com [mailto:firstname.lastname@example.org]
> Behalf Of Michael Poole
> Sent: Monday, June 03, 2002 9:43 PM
> To: email@example.com
> Subject: Re: scalable network architectures (was RE: [Mono-list] Mono
> fitness for ircd project)
> "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
> > 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
> 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 - Monoemail@example.com