Hello JHHL,
It appears that by opening the server specifically on the box's
address, it no longer responds to the loopback address. I wasn't
expecting that;
I'm surprised that you weren't expecting that. If you think about it,
it makes sense, and it's doing exactly what you asked it to do!
IP addresses are assigned to network interfaces, not to a particular
computer. I say this because you reference "the box's address", but it's
important that you not think of it in terms of one address per box. It's
one address per network interface. The loopback/localhost network
interface is a different interface (it's software-only, and is optimized
for communications between programs on the same box -- if you think
about it's internals, it works very differently than a physical network
interface).
Anyway, since you bound to a specific interface, it makes perfect sense
that you can't handle requests that are on a different interface.
is there a workaround, other than modifying the
shutdown utility to allow a port to be specified there as well?
I don't understand what you mean by "allow a port to be specified". You
haven't changed the port, have you? You'd need to allow the shutdown
utility to specify an IP address (and/or host name) instead of assuming
127.0.0.1
And that's problematic as well, because you don't want "just anyone" on
the network to be able to send a shutdown request. Otherwise, any
miscreant can shut down your server.
If you want to accept connections on BOTH 127.0.0.1 and the other
network interface -- that's a little ugly. You'll have to use two
sockets in that case, one bound to the physical interface, and one bound
to 127.0.0.1. And instead of simply calling accept(), you'll have to
use select() to multiplex between the two sockets, then call accept() on
the appropriate one.
A possibly better idea (the way I do it, anyway) is to NOT use the
socket to indicate shutdown. Instead, I suggest checking for SIGTERM,
and then shutting down nicely when it's received. That way your
shutdown utility can either send SIGTERM to the process, or can use
ENDJOB OPTION(*CNTRLD) to end the server. Likewise, existing tools such
as WRKACTJOB, ENDSBS *CNTRLD, PWRDWNSYS *CNTRLD, et al, will cause your
job to end correctly and under it's own control.
So using SIGTERM solves the problem, somewhat alleviates the problem of
people ending it improperly, and makes it more intuitive, all at the
same time.
That's my 2 cents, anyway. I'm sure Crispin will argue with me.
midrange.com
