Concurrent, non-(blocking&&threaded&&forking) server

Concurrent, non-(blocking&&threaded&&forking) server

Post by f0 » Fri, 23 Jun 2000 04:00:00



Anyone tried this?

Please tell me If I do this harder than it should be done:
(assume the server and client communicates through a special protocol,
maybe some sort of authorization)
On every connect, you put the new clientfd in som client-struct and
add it to a linked list.
For everything that happens you have states, like STATE_GETPASSWORD - and
because you never know if a recv(8) gets you 8 bytes you have
to have a variable too in this struct telling me ho many bytes of the
password you have gotten.

I _have_ done this, and it works, BUT, this looks much too complicated to me.
I have also done a server using fork() on connect, but if I have a big
program and many connects I guess this is not the best way :)

Any suggestions?? Thank you!!

--

/Daniel ?kerud

 
 
 

Concurrent, non-(blocking&&threaded&&forking) server

Post by Barry Margoli » Fri, 23 Jun 2000 04:00:00




>Anyone tried this?

>Please tell me If I do this harder than it should be done:
>(assume the server and client communicates through a special protocol,
>maybe some sort of authorization)
>On every connect, you put the new clientfd in som client-struct and
>add it to a linked list.
>For everything that happens you have states, like STATE_GETPASSWORD - and
>because you never know if a recv(8) gets you 8 bytes you have
>to have a variable too in this struct telling me ho many bytes of the
>password you have gotten.

>I _have_ done this, and it works, BUT, this looks much too complicated to me.
>I have also done a server using fork() on connect, but if I have a big
>program and many connects I guess this is not the best way :)

>Any suggestions?? Thank you!!

It's certainly possible, but as you noticed, it's very complicated, and
this makes it extremely error-prone.  Complex state machines can be
difficult to program by hand.

Threading allows you to program it similarly to the way you would with
fork(), but since everything is in a single process it could be more
efficient and often simplifies communication among the servers.  On the
other hand, on a multi-processor system it will reduce concurrency unless
the OS implements kernel threading.

--

Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

Concurrent, non-(blocking&&threaded&&forking) server

Post by Andrew Giert » Sat, 24 Jun 2000 04:00:00


 f00> Anyone tried this?

 f00> Please tell me If I do this harder than it should be done:
 f00> (assume the server and client communicates through a special
 f00> protocol, maybe some sort of authorization) On every connect,
 f00> you put the new clientfd in som client-struct and add it to a
 f00> linked list.  For everything that happens you have states, like
 f00> STATE_GETPASSWORD - and because you never know if a recv(8) gets
 f00> you 8 bytes you have to have a variable too in this struct
 f00> telling me ho many bytes of the password you have gotten.

 f00> I _have_ done this, and it works, BUT, this looks much too
 f00> complicated to me.

Well, that's part of the penalty of that particular model. Sometimes
it's worth it: if the various connections interact a lot, then it can
be simpler to use a multiplexed server rather than the simpler
fork-per-connect model. (thread-per-connect is an alternative that may
be worth exploring in some cases)

 f00> I have also done a server using fork() on connect, but if I have
 f00> a big program and many connects I guess this is not the best way
 f00> :)

Depends what you call big. If the _rate_ of new connections is very
high then fork-per-connect may not be the best solution, but don't
underrate it.

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>