[Xorp-hackers] Questions on the architecture

[Halldor Isak Gylfason]

It's true that XORP would hardly be dealing with thousands of open file 
descriptor, so this is probably not an issue. It's also true that it the 
cost of select depends on the implementation, however the interface itself 
is a limit to how effective an implementation can be. An effective 
select-like implementation would of course keep the set of file descriptors 
in kernel space, so you wouldn't have to copy all of them to the kernel on 
each call and perform the scan. The select interface however kind of insists 
on this copying and scanning.

Having the sockets opened only in FEA makes sense in light of what you are 
trying to accomplish design-wise. You could of course accomplish the same 
thing through a generic shared library, which would avoid the cost of the 
indirection of the FEA, but as you pointed out you are not pushing gigabytes 
of data, so this hardly matters.

Thanks for your answers,

Halldor isak

>From: Bruce M Simpson <bms@spc.org>
>To: theo29 the29 <theo29_1@hotmail.com>
>CC: xorp-hackers@icir.org
>Subject: Re: [Xorp-hackers] Questions on the architecture
>Date: Wed, 9 Feb 2005 14:43:40 +0000
>
>On Wed, Feb 09, 2005 at 11:51:17AM +0000, theo29 the29 wrote:
> >
> > I have two questions on the XORP architecture which I hope someone can
> > answer:
> >
> > 1. The architecture is based on a single threaded event loop, that 
>divides
> > its time doing a select() on all its file descriptors (in the selector
> > list), and executing expired timer events. A select() is one of the more
> > expensive things you can do in the kernel, so I was wondering if you had
> > thought something about the scalability of that approach (for example in
> > terms of number of protocols communicating with the finder server). Did 
>you
> > not consider asynchronous IO?
>
>It entirely depends on what one is doing.
>
>Sure, select() can be expensive, but it depends on how one implements it.
>There are other techniques which fill a similar niche (e.g. BSD's kqueue,
>SVR4's poll(), Linux/Solaris /dev/poll and so on).
>
>In the case of XORP, we aren't dealing with potentially thousands
>of file descriptors, so the usual performance speed-bumps encountered
>when dealing with select() and poll() (preparing the file descriptor sets,
>scanning them, et cetera) aren't an issue.
>
>We dont't push gigabytes of data at a time through the control plane,
>so I don't see how POSIX.1 Asynchronous I/O could help.
>
>I should also point out that POSIX.1 AIO implementations vary greatly
>in their scalability. FreeBSD 5's, for example, all takes place on a
>single kernel thread shared amongst all AIO client processes.
>
>Whilst XORP's EventLoop code could certainly be rewritten to use
>kqueue() or some other native event multiplexing mechanism, this
>seems on the face of it to be a micro-optimization, unless one is
>in a situation where it's totally necessary (e.g. Windows, various
>RTOS or embedded operating systems).
>
> > 2. What is the purpose of the SocketServer class. Should protocols not 
>open
> > their own sockets, but rather deligate that to the XRL target 
>implementing
> > the socket4.xif (which I belive is executed in the FEA process now)? Why
> > deligate this task?
>
>Protocols should not open their own sockets. A deliberate design decision
>was made to delegate socket operations to the FEA in order to make the
>framework more portable between platforms.
>
>In the case of the Windows platform, the use of the SocketServer is going
>to be important, because of the subtle differences between Winsock 2 and
>BSD-derived socket implementations which are there to trip you up.
>
>There's also the case where XORP could run in an environment which does
>not support sockets at all, or even kernel-space TCP/UDP, in which case
>it would be necessary for the FEA to do this work.
>
>Regards,
>BMS
>_______________________________________________
>Xorp-hackers mailing list
>Xorp-hackers@icir.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/