dcb136b2
XPost: comp.arch.embedded, comp.os.linux.networking
From: tw@dionic.net
karthikbalaguru
wibbled on Sunday 21 February 2010 08:33
>
> Linux !
OK - Stop worrying until it becomes a problem then tune the kernel. Make
reasonable efforts to make the server app efficient but don't kill yourself
unless you are writing something so outlandishly loaded that special
considerations are needed. BTW - this is quite a rare requirement in
practice.
>
> Great. But, Is there a C language version of the same that can help
> in plain sailing with a multliplexed server ?
Honestly don't know. C++ might have something?
But you have the freedom now to implement any of the strategies. How about a
worker pool of processes with a master doing the listen() and handing off
each new connection to an idle worker child? This would be good if the
connections have little interaction with each other. If the interaction is
heavy, you could either:
a) Use processes with IPC;
b) Use threads;
c) Do multiplexed;
or
(sometimes overlooked - depends on the releative weight of the server's non
mutually interactive code with the interactive bit)
d) Make the server processes totally non interactive and move the
interactive logic to another server process which communicates with the
first server over unix domain sockets (these are quite efficient in linux).
Just another idea.
> I searched the internet to find the features available with perl's
> IO::Multiplex .
> It seems that IO::Multiplex is designed to take the effort out of
> managing
> multiple file handles. It is essentially a really fancy front end to
> the select
> system call. In addition to maintaining the select loop, it buffers
> all input
> and output to/from the file handles. It can also accept incoming
> connections
> on one or more listen sockets.
> It is object oriented in design, and will notify you of significant
> events
> by calling methods on an object that you supply. If you are not using
> objects,
> you can simply supply __PACKAGE__ instead of an object reference.
> You may have one callback object registered for each file handle, or
> one
> global one. Possibly both -- the per-file handle callback object will
> be
> used instead of the global one. Each file handle may also have a
> timer
> associated with it. A callback function is called when the timer
> expires.
>
> Any equivalent C language package available ?
You'll have to wait for someone else or google a bit more.
If you can read perl (even if you don't really use it) you could rip off
IO::Multiplex and make a C or C++ library that implements exactly the same
API. It's fairly easy to do a line by line translation of perl to C or C++.
If you're feeling nice you could even opensource your library.
License issues may exist if you do a direct line by line rip off without
opensourcing it - I'm not a lawyer, just be aware.
But either way, you should be on reasonably safe ground taking inspiration
from it.
Multiplexing servers work well for servers that process connection data fast
and deterministically without blocking for long (or not at all). If your
process may block talking to a database (for example) then you will face the
problem of blocking the whole server if you're not careful. In which case
there is much to be said for forking or threaded servers as at least the
kernel will help you out.
Cheers
Tim
--
Tim Watts
Managers, politicians and environmentalists: Nature's carbon buffer.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
