I intend to write a server in this fashion.

1)Create a socket, bind it and listen on it.
2)Fork 'n' number of childs and pass the socket descriptor as
argument.
3)Each would would then do an accept on that socket descriptor.
4)when a request comes to any of the childs, the child would create a
thread to handle it.

This is just the outline. Is this a correct/good design and in right
direction? Can i replace step 1 of this with openSSL create call for
adding security?

Thanks,
Balaji.

[ Post a follow-up to this message ]

kasthurirangan.balaji@gmail.com wrote:
> I intend to write a server in this fashion.
>
> 1)Create a socket, bind it and listen on it.
> 2)Fork 'n' number of childs and pass the socket descriptor as
> argument.
> 3)Each would would then do an accept on that socket descriptor.
> 4)when a request comes to any of the childs, the child would create a
> thread to handle it.
>
> This is just the outline. Is this a correct/good design and in right
> direction? Can i replace step 1 of this with openSSL create call for
> adding security?

As a basic, low volume server, that should work fine.

google C10K if you want an interesting article on all kinds of server
architectures.

[ Post a follow-up to this message ]

In article <1193405730.288499.190460@19g2000hsx.googlegroups.com>,
kasthurirangan.balaji@gmail.com wrote:

> I intend to write a server in this fashion.
>
> 1)Create a socket, bind it and listen on it.
> 2)Fork 'n' number of childs and pass the socket descriptor as
> argument.
> 3)Each would would then do an accept on that socket descriptor.
> 4)when a request comes to any of the childs, the child would create a
> thread to handle it.
>
> This is just the outline. Is this a correct/good design and in right
> direction? Can i replace step 1 of this with openSSL create call for
> adding security?
>
> Thanks,
> Balaji.

If you're going to create new threads when the requests come in, why
fork N processes in the first place?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

On Oct 26, 6:35 am, kasthurirangan.bal...@gmail.com wrote:

> This is just the outline. Is this a correct/good design and in right
> direction? Can i replace step 1 of this with openSSL create call for
> adding security?

You really can't sensibly share an OpenSSL context across processes.
You might be able to get each process to use its own context, but at a
minimum, session resumption won't work.

I would suggest that a hybrid design of threads and processes is
probably more effort than it's worth. You would likely do better
segregating code into processes only if there is a functional reason
to do so. (For example, you may want to run CGIs in their own process
so it can't hurt the main server process.)

But your overall architecture seems contradictory. If you don't care
about performance, why the complexity? If you do care about
performance, why have a thread-per-connection underneath all the
complexity?

It's hard to imagine a set of requirements for which this would be the
right solution. (Perhaps if the web server were a text-only 'middle
piece' between a local caching reverse proxy and a back end? In that
case, each request's lifetime would be limited as the reverse proxy
would suck the data up virtually immediately)

DS

[ Post a follow-up to this message ]