[Xorp-hackers] Questions on the architecture

[Bruce M Simpson]

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