Very Computer

How can I setup FreeBSD 2.2.x to allow a single process to call
select() with more than 256 fd?  This is for a chat server and I need
to keep constant connections and select() for descriptors ready to
read/write.  In the past I have run Linux systems and have had to hack
the kernel to accomplish this.

This is my first FreeBSD system to setup and I find the performance as
a server to be somewhat better than Linux so far especially in the
area of disk access.  I looked through the FreeBSD kernel source
briefly but nothing jumped out and bit me.

Is there an easy way (or pre-existing way) to get select() to work
with more than 256 fd?

Also, are there any known drawbacks to running a server in this
manner?  Each connection is generally only transferring about 70 bytes
per second so the connections are pretty "light".  I guess I'm asking
if there are any lower level TCP/IP stack issues I should be concerned
with or keeping in mind.

Thanks!

Daniel Walton

Quote:>How can I setup FreeBSD 2.2.x to allow a single process to call
>select() with more than 256 fd?  This is for a chat server and I need
>to keep constant connections and select() for descriptors ready to
>read/write.  In the past I have run Linux systems and have had to hack
>the kernel to accomplish this.
>This is my first FreeBSD system to setup and I find the performance as
>a server to be somewhat better than Linux so far especially in the
>area of disk access.  I looked through the FreeBSD kernel source
>briefly but nothing jumped out and bit me.
>Is there an easy way (or pre-existing way) to get select() to work
>with more than 256 fd?

The occasional thing (like some DNS resolver functions) will
cry if you try to use FDs above 256 with them.  This can be
resolved by either keeping some low FDs free (see the ap_slack
code in Apache 1.2.4 for an example of how) or recompiling libc
with an increased FD_SETSIZE.  This only applies, of course, if you
have to use those particular functions.

Quote:>Also, are there any known drawbacks to running a server in this
>manner?  Each connection is generally only transferring about 70 bytes
>per second so the connections are pretty "light".  I guess I'm asking
>if there are any lower level TCP/IP stack issues I should be concerned
>with or keeping in mind.

I can't remember exactly how I did it, but I think it was just a simple
change to the kernel config file.

Gary
--

Key fingerprint =  0C FB 60 61 4D 3B 24 7D  1C 89 1D BE 1F EE 09 06

Another alternative is missed:

Don't use

        fd_set fdsr;

        FD_ZERO(&fdsr);

        FD_SET(fd, &fdsr);
        ...
        select(whatever, ...
        ...

Instead use

        fd_set *fdsrp;

        fdsrp = calloc(howmany(maxfd+1, NFDBITS, sizeof(fd_mask));

        FD_SET(fd, fdsrp);
        ...
        select(maxfd+1, ...
        ...
        free(fdsrp);

Suddenly you can have as large an fd_set as you like.  Of course this
assumes your kernel's select() can handle large nfds parameters.  Some
kernels can, some cannot.

By the way, it gets even worse if you use RPC code in the same
programs...  Fixing libc/rpc to handle > FD_SETSIZE descriptors is
(_was_) really hard.  When I say "RPC code", I mean something like YP.

--

www.OpenBSD.org -- We're fixing security problems so you can sleep at night.
(If it wasn't so fascinating I might get some sleep myself...)

Looking further, it appears like it was fixed in 2.2-stable in late June.
Must have missed it.