> I am designing a server, as an interface to an Voice
>Response System and it has been suggested that there be a total
>of 8 socket listening ports used to achieve optimum communication
>through-put. Thus, the client voice response system will have 8
>socket ports to choose from when contacting my server box for
>DB data requests. This will result in multiple entries inside my
>inetd.conf file for the same daemon executable (If I use inetd
>as the listening super server) each with uniquely named services
>my_server1 stream tcp nowait root /bin/my_server my_server
>my_server2 stream tcp nowait root /bin/my_server my_server
> . . . . .
> . . . . .
> . . . . .
>my_server8 stream tcp nowait root /bin/my_server my_server
> Does this seem redundant to anyone else, besides myself ?
Definitely. It's nonsense.
Quote:>Are we really achieving throughput increase with more listening
Quote:>Since inetd simply listens on the port defined inside
>/etc/services anyhow won't this listening port be freed immediately
>following inetd's accept() and subsequent spawning of the new socket
>for that communication channel (and then forking the daemon server).
The port will not be freed, but that doesn't matter. A port is an abstract
concept, it doesn't have physical throughput constraints.
Quote:>While that link is active does that preclude other subsequent client
>requests from being serviced immediately?
Yes and no. It depends on what you mean with 'immediately'. While the inetd
is processing a connection request (select, accept, fork) it cannot
process other requests. That's why there's a queue of connection requests
(see the description of the 'backlog' parameter of the listen(2) system call).
Normally this suffices to give all clients the impression of immediate
service. It doesn't help to have multiple entries for a single server in
inetd.conf, since the inetd can still process only one connection request
at the time. Note that the limitation only applies to processing simultaneous
connection requests. Once the inetd has forked, it can continue to process
connection requests while the forked server is active. I have never seen a
situation where the inetd is overrun with connection requests (except once
with the inetd equivalent on a thrashing VAX :-) ).
The handling of connection requests by the inetd has nothing to do with the
throughput of the connections to your server. What is your real problem?
Are clients receiving ECONNREFUSED errors when the server is busy? Does it
take too long to start a server? Is the throughput to your server too low?
Quote:>How does the rlogin service achieve this with one entry in the inetd.conf
>file ? Obviosily many people can log into the same Unix system simultaneously
>without obvious loss of response?
That's right. One entry in inetd.conf is the normal setup. Just forget about
the 8-ports suggestion.
> Any thoughts or suggestions are appreciated !
-Ren\'e Pijlman- _-^^-_
// _ - /
On no account allow a Vogon || \ - /\\
to read poetry at you. || \___/ ||
- Hitchiker's Guide to the Galaxy || //|\