Re: server structure

[email protected] Fri, 21 Oct 2005 21:25:28 +0000
Newsgroups gmane.comp.lib.state-threads.devel,gmane.comp.lib.state-threads.user
Message-ID <102120052125.9895.43595CC80004FD80000026A72200735446089C0A020A09@comcast.net>
> - pls comment on the structure below and/or recommend something as the
> server example is somewhat different - i.e. can i just accept &
> read "ahead" or should i st_poll() across all connections?

The structure makes sense. You don't need to poll across all connections since
you have one thread per connection.

> - if one st thread reads & then sends on to a number of connections, if
> one of these is slow, then i presume this st_thread will block,
> preventing any further writes from happening until it has finished - how
> can i deal with this?

There are several ways to deal with this. In the simplest case when your
message sizes are not too big, you can just set socket output buffer size
to a large value (setsockopt(SO_SNDBUF)), e.g. 1MB. Then just use
non-blocking writes (not st_write()s) directly.  It'll return an error when
socket output buffer is full (at that point you may want to discard outgoing
message).

> - how can i benefit from additional processors when i can only listen to
> one port in a single physical thread?

You fork processes after you create listening socket. Also see
http://state-threads.sourceforge.net/docs/faq.html#cpus

> - how should a client close be properly managed?

reading thread should take care of a client close (st_read() will return 0, at this
point you should close connection and remove it from your list).

Hope it helps,
Gene




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl