Q: Network Socket Design

Q: Network Socket Design

Post by kc » Sun, 18 Jun 1995 04:00:00



Hi,

        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
ie.,

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 ?
Are we really achieving throughput increase with more listening
ports ? 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).
While that link is active does that preclude other subsequent client
requests from being serviced immediately ? 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 ?  

        Any thoughts or suggestions are appreciated !

Keith

 
 
 

Q: Network Socket Design

Post by Rene Pijlma » Mon, 19 Jun 1995 04:00:00



>Hi,

>    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
>ie.,

>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
>ports?

No.

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.

Quote:>    Any thoughts or suggestions are appreciated !

>Keith

HTH,
-Ren\'e Pijlman-                      _-^^-_

                                   //   _ -  /
On no account allow a Vogon       || \  -  /\\
to read poetry at you.            ||  \___/ ||
- Hitchiker's Guide to the Galaxy ||       //|\
------------------------------------------------

 
 
 

1. sockets v/s Message Qs

Hi:
I have  a simple client server situation, with the client and server
ensured to be running in the same host. Could you please help me trying
to decide between TCP sockets and Message Qs. All teh communications
will be in the form of 1 request followed by a response to it. That way
there is no need to keep the connection open. I m looking an answer
from an efficiency other issues point of view.

Thanks
Sony

Sent via Deja.com http://www.deja.com/
Before you buy.

2. CD Image software for Linux

3. networking systems - lots of Qs

4. Sendmail

5. Server design using sockets & IPC

6. SVGAlib - How to use it...

7. How to use socket to design a server which check a table in the database

8. INFO REQ: Please Clarify About Memory Management

9. Help on Design: Socket, fdopen, alarm()

10. hardware design or digital design

11. Chip Design on Linux with the OCEAN IC design system

12. Network sockets... without network!

13. source code from Unix networking programming Networking APIs:Sockets and XTI