Problem with UCX QIOW IO$_SETMODE
Ferry Bolhar
I habe a self-written TCP/IP server, listening on a specific port. Before
the server is started, a DCL scripts reads some symbols from a config file
and then starts the server image. Within the image, I use the LIB$GET_SYMBOL
RTL function to obtain the symbol values and process the requests sent to
the server accordingly. Works as expected.
When a special request is sent to the server, the image terminates, the DCL
procedure gains control, reads the config file again and restarts the image.
This allow changes in the server configuration by simply editing the config
file and sending a reconfig request. There is no need to restart the entire
software.
However, when running the image, the second (and further) times, the iosb of
the QIOW IO$_SETMODE request, which is used to set the socket parameters,
returns in iosb[0] the return code SS$_DUPLNAM. According the documentation,
this means that a process tries to listen on a TCP port which another
process already is listening on. However, this isn't the case here - the
image has terminated and the bg: device which represented the listening port
(can be shown with UCX SHOW DEVICE) disappeared.
However, after waiting for a minute, the QIOW call succeeds.
Well, I could insert a WAIT 0:1 in the script, but this would make the
server unusable for a minute after each reconfiguration request. This isn't
what I'm looking for.
Can some explain me what happens here? And provide a solution?
BTW: It's OpenVMS V6.2, UCX V4.2. Occurs on VAX and Alpha.
MTIA and kind greetings from Vienna,
Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: b...@adv.magwien.gv.at
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: b...@adv.magwien.gv.at
Carl Perkins
}When a special request is sent to the server, the image terminates, the DCL
}procedure gains control, reads the config file again and restarts the image.
}This allow changes in the server configuration by simply editing the config
}file and sending a reconfig request. There is no need to restart the entire
}software.
}
}However, when running the image, the second (and further) times, the iosb of
}the QIOW IO$_SETMODE request, which is used to set the socket parameters,
}returns in iosb[0] the return code SS$_DUPLNAM. According the documentation,
}this means that a process tries to listen on a TCP port which another
}process already is listening on. However, this isn't the case here - the
}image has terminated and the bg: device which represented the listening port
}(can be shown with UCX SHOW DEVICE) disappeared.
}
}However, after waiting for a minute, the QIOW call succeeds.
}
}Well, I could insert a WAIT 0:1 in the script, but this would make the
}server unusable for a minute after each reconfiguration request. This isn't
}what I'm looking for.
}
}Can some explain me what happens here? And provide a solution?
}
}BTW: It's OpenVMS V6.2, UCX V4.2. Occurs on VAX and Alpha.
}
}MTIA and kind greetings from Vienna,
}
}Ferry
See the example file:
SYS$COMMON:[SYSHLP.EXAMPLES.TCPIP]TCPIP$TCP_SERVER_QIO_2ND.C;1
Particularly the parts after the comment that looks like this:
*
**
** Set Socket Options:
**
** Inform the network driver that we want to reuse this port address right
** away.
**
** There might be some old messages still on the network destined for the
** last server that used this port. To avoid delivering these straggling
** messages to the wrong server the network imposes a timeout that must
** expire between the time a server finishes using a port and that port can be
** can be assigned to another server. The following call will override this.
**
** The benifit of overriding this time out is, we do not have to wait before
** we can reuse the port address. The down side is, we might get messages
** that were not ment for this server.
**
*/
After that is the setup for a QIO call that uses the TCPIP$M_REUSEADDR item.
--- Carl
Valentin Likoum
> "Ferry Bolhar" <b...@adv.magwien.gv.at> writes...
[snip]
> }However, when running the image, the second (and further) times, the iosb of
> }the QIOW IO$_SETMODE request, which is used to set the socket parameters,
> }returns in iosb[0] the return code SS$_DUPLNAM. According the documentation,
> }this means that a process tries to listen on a TCP port which another
> }process already is listening on. However, this isn't the case here - the
> }image has terminated and the bg: device which represented the listening port
> }(can be shown with UCX SHOW DEVICE) disappeared.
> }However, after waiting for a minute, the QIOW call succeeds.
> ** Set Socket Options:
> **
> ** Inform the network driver that we want to reuse this port address right
> ** away.
> **
> ** There might be some old messages still on the network destined for the
> ** last server that used this port. To avoid delivering these straggling
> ** messages to the wrong server the network imposes a timeout that must
> ** expire between the time a server finishes using a port and that port can be
> ** can be assigned to another server. The following call will override this.
> **
> ** The benifit of overriding this time out is, we do not have to wait before
> ** we can reuse the port address. The down side is, we might get messages
> ** that were not ment for this server.
> **
> */
>
> After that is the setup for a QIO call that uses the TCPIP$M_REUSEADDR item.
>
> --- Carl
Hmm.. I have been using this option since UCX 4.2 and now
on TCPIP 5.1, but it seems never happens to work. Option is
definitly set accordinly to UCX SHOW DEVICE/FULL output. But
I always get SS$_DUPLNAM after server restart if I don't
disconnect all the clients before server shutdown.
Other options enabled on server' socket are KEEPALIVE and
FDPX_CLOSE.
--
Best regards,
Valentin
valentin.likoum at ncc dot volga dot ru
Ferry Bolhar
> Hmm.. I have been using this option since UCX 4.2 and now
> on TCPIP 5.1, but it seems never happens to work. Option is
> definitly set accordinly to UCX SHOW DEVICE/FULL output. But
> I always get SS$_DUPLNAM after server restart if I don't
> disconnect all the clients before server shutdown.
The trick is that, with the QIO interface, you must not specify all
parameters in one call because it seems that they are processed in an
unsuitable sequence. The BG: driver processes them starting with p1, next
p2, p3 and so on, whatever was not passed as zero. This means that parameter
p3 which is used to bind the socket to a specific port is processed _before_
parameter p5 which is used to set socket options. Therefore, because the
UCX$_REUSEADDR option isn't yet set at the time parameter p3 is processed,
the binding fails with SS$_DUPLNAM.
Like shown in the examples in SYS$EXAMPLES:[.UCX] (Thanks to Carl Perkins
for his suggestion), I have splitted now the QIO call into three calls: the
first only uses P1 to set the socket creation parameters, the second uses
only P5 to set the socket option
UCX$_REUSEADDR, and the third specifies P3 to bind the socket to a local
address and P4 to specify a queue length for incomming connection requests
Although the manual says that you can specify all parameters in a single qio
call, this isn't the case here. Anyway, now it works as epxected.
May be that you can specify p1 and p5 together in a single QIO call and p3
and p4 in a second.
Greetings, Ferry
---
Ing. Ferry Bolhar-Nordenkampf
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: b...@adv.magwien.gv.at
"Wenn hier einer schuld ist, dann immer nur der Computer."
Valentin Likoum
> Valentin Likoum wrote:
>
>>Hmm.. I have been using this option since UCX 4.2 and now
>>on TCPIP 5.1, but it seems never happens to work. Option is
>>definitly set accordinly to UCX SHOW DEVICE/FULL output. But
>>I always get SS$_DUPLNAM after server restart if I don't
>>disconnect all the clients before server shutdown.
>
>
> The trick is that, with the QIO interface, you must not specify all
> parameters in one call because it seems that they are processed in an
> unsuitable sequence. The BG: driver processes them starting with p1, next
> p2, p3 and so on, whatever was not passed as zero. This means that parameter
> p3 which is used to bind the socket to a specific port is processed _before_
> parameter p5 which is used to set socket options. Therefore, because the
> UCX$_REUSEADDR option isn't yet set at the time parameter p3 is processed,
> the binding fails with SS$_DUPLNAM.
Bingo! The devil was in the details, as always. Thank you
VERY much.