Re: Socket server opening multiple remote ports -- RPG400-L

GKern@xxxxxxxxxxxxxxxx wrote:

Sigh.... I should have been a plumber....

I could use a good plumber!

Last week I mentioned some 'flaky-ness' with a socket server program.
This is a multi-connection socket server, and I determined that the
reason the connections weren't behaving as expected was because I
wasn't using non-blocking mode. Hence the program appeared to 'hang'
while waiting to receive data.

What do you mean by "multi-connection"? I typically write my servers using one of three different models:

a) Spawning Server -- spawns (or submits) a new job for each new connection. (the FTP server and TELNET server on i5/OS are examples of this.)

b) Handoff Server -- Uses a pool of active jobs to handle each new connection. Every time a new connection is made, it's handed off to the next available job in the active job pool. (The HTTP server on i5/OS is an example of this.)

c) Multiplexing Server -- A single job handles multiple simultaneous connections by using the select() API to determine which ones are readable or writable, and switching between them. This is often used for proxies, chat applications or games... any time you need all of the sockets to be able to communicate with one another.

In my attempt to correct this problem I added code to set the socket
to non-blocked mode. In doing so, I found that after accepting a
connection (which is always 'up'), even though no data is currently
being sent (data will come as it becomes available), I exit my socket
read/write loop, without dropping the socket connection and return to
the outer loop which (I thought) should enable me to check for
incoming data on another connection (ie server shutdown request).

That sounds like a multiplexing server.

in doing this I found (via netstat *cnn) that multiple remote ports
(from the same remote client) are connecting to the socket server.

The server doesn't control that. That's controlled by the client program -- the client side is using multiple sockets, and calling the connect() API on each one. (Possibly by running multiple copies of the same program, or possibly the client program is giving up and starting a new connection without properly closing the previous one.)

As a side note, my listen function is set to one, although I suspect
it should be set to two, so that it can listen to the remote client,
and also listen for a shutdown request from a different source (the
local iSeries).

In a multiplexing server model, I would set the backlog parameter of the listen() API to the same number as the number of sockets your program can handle at once. So I would expect this to be larger than 2!!

In a handoff model, I typically set this to about five times as many as I have worker jobs, figuring the others can queue up and wait, since handoff servers typically don't take long to finish their transactions.

In a spawn model, I just set it to a high number...

But as it is now, it will shut down while connected
to the remote client and I connect locally to issue the shutdown
request with the listen value set to one.

I don't follow this. Why would the listener shut down if you're handling multiple sockets at once. It sounds like this is designed to handle only one connection at a time from this description...

So this morning I changed the listen value to two, shut down and
restarted and things appeared to be okay for 2.5 hours (only one
connection from the remote client showing in netstat), but when I
got back from lunch I now see two connections on different ports from
the same IP address. The remote should only be establishing one
connection should only be sending on one port.

This is happening because the client is connecting more than once. It's possible (depending on how the software works) that you're doing something to trigger the client to do this -- but that would mean that there's code in the client designed to reconnect based on some event. Without knowing more about that scenario, I can't tell you what's causing it. I'd have to know how the client works.

In a typical scenario, however, a server program can't cause this to happen. Only the client can.