zhouhui at wam.umd.edu
Tue Feb 1 11:31:41 PST 2005
On Tue, Feb 01, 2005 at 11:25:27AM -0700, Gerard Beekmans wrote:
>On Tue, 2005-02-01 at 08:30, James Robertson wrote:
>> new tool is programmed in. I just want it to work. Here are my
>> thoughts on the matter to start discussion.
>I would choose plain old C for the server too. It doesn't do anything
>fancy: listen on a port for a TCP connection, authenticate, validate,
>run whatever it's given without question.
For maintain the connection and fork server, I can code it in C or
perl or python within minutes.
Authentication is tough. I suggest trust based authentication. Define
a key or ip(or many) on the server and instruct the server only
listens to those. That's easy. Others takes a professional to
implement and make sure it's secure.
Validataion, I assume we are talking about command parsing. The
easiest protocol is ascii based and with a regex engine, it is very
easy to implement. Binary protocol can be more efficient of course,
but the development cycles esclates.
>But we want the server process to be fast and responsive. Not every
>system will be a 3 GHz system out there.
You probably won't find it much slower if a human is sitting on the
server :) instead of a program.
Do you realize that only thing the server does is parse the command
and run other programs.
>Python and Perl speeds might be
>circumspect on the slower machines. Then again..if it takes a minute to
>start a server process...compared to a build that would take 20 hours,
>would anybody care?
It takes miliseconds to start a server process. Hundreds of processes
is another problem.
More information about the alfs-discuss