Efficent handling of sockets

Dave Cramer davec-zxk95TxsVYDyHADnj0MGvQC/G2K4zDHf at public.gmane.org
Thu Feb 19 15:45:34 UTC 2009


Have him look at postgresql's server code. The bit that does socket handling
is pretty easy reading.

Although handling thousands is a stretch

Dave

On Thu, Feb 19, 2009 at 10:33 AM, Ken Burtch <ken-8VyUGRzHQ8IsA/PxXw9srA at public.gmane.org> wrote:

>
> Any socket gurus out there?
>
> I had a question from a guy at work writing his own socket server in C. He
> is writing an application which needs to handle thousands of users.
>
> He would like to know the most efficient way of servicing sockets.
>  Although he blocks on sockets with a select(2) call to the kernel, he must
> still search thorugh the select list to determine which socket needs to be
> serviced.  He would like to know if there is a more efficient way to handle
> the socket stack.  In particular, he heard that there is a way to have the
> kernel call a C function to processess particular sockets but he doesn't
> know how to set that up nor is he certain if he has to use a custom kernel
> module to achive this.  Can anyone give him pointers on how to make
> searching through the select(2) results more efficient or give him a more
> efficient alternative to select(2) for managing large numbers of sockets?
>
> Thanks,
> Ken B.
>
>
> -----------------------------------------------------------------------------
> Ken O. Burtch                                       Phone/Fax: 905-562-0848
>  "Linux Shell Scripting with Bash"                  Email: ken-8VyUGRzHQ8IsA/PxXw9srA at public.gmane.org
>  "Perl Phrasebook"                 Blog: http://www.pegasoft.ca/coder.html
>
> -----------------------------------------------------------------------------
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/legacy/attachments/20090219/8ebe50b7/attachment.html>


More information about the Legacy mailing list