HP OpenVMS Systems

Use of TCP/IP socket REUSEADDR? (DUPLNAM)

» close window

The Question is:

 
 
Hi,
 
I am experiencing a problem with TCP/IP, after
upgrading to OpenVMS V7.2-1, and TCP/IP 5.0.
 
We were able to run multiple UDP - multicast
receivers on the same node (with VMS 7.1 and UCX 4.2). This used to be very
 helpful because
we have several team-members working separately
with the same multicast feed.
 
Once we upgraded to Open VMS 7.2 and TCP/IP 5.0
we are not able to run multiple receivers on the same IP-Addr - port.
 
The $QIO returns SS$_DUPLNAM in the I/O status block.
 
1. Assign channel to UCX$DEVICE - success
 
2. create socket type (IO$_SETMODE
   protocol: UCX$C_UDP, type: INET_PROTYP$C_DGRAM, family: AF_INET) - success
 
3. set socket options: UCX$M_REUSEADDR - IO$_SETMODE - success.
 
4. Trying to bind the socket..... fails:
 
        saddr.sin_family =
            AF_INET;
        saddr.sin_addr.s_addr =
            htonl( INADDR_ANY );
        saddr.sin_port=
            htons( atoi( &port[0]  ) ); /* mcast port  */
 
        sts =
            sys$qiow(
                 0
                ,chan
                ,IO$_SETMODE    /* func.v */
                ,&iosb          /* iosb.r | 0 */
                ,0, 0           /* astadr, astprm: UNUSED */
                ,0, 0           /* p1, p2  UNUSED */
                ,&adrs          /* p3.d Socket bind parameter */
                ,0, 0, 0        /* p4, p5, p6 UNUSED */
                );
 
 
 
The above $QIO returns success in the return status, but the condition value in
 the IOSB is SS$_DUPLNAM ... when there is already a receiver job running on
 that I/P Addr and  port, from another user account).
 
 
One more interesting observation:
If we try to create a telnet session using telnet/create_session.... fails with
 the same
error!
 
EF101> telnet /create_session ef 2024 12
%TELNET-E-INTERNAL, Internal error: Failed to set device characteristics
-SYSTEM-F-DUPLNAM, duplicate name
EF101>
 
Any work-arounds? Suggestions??
 
Thanks in advance!
 
Regards,
Ganga.
 
 

The Answer is :

 
  First, please move to TCP/IP Services V5.0A.
 
  You will want to set the SO_REUSEADDR (or the prefered SO_REUSEPORT)
  socket option before attempting to bind to that port.  During typical
  debugging -- particularly with frequent server stops and restarts --
  this technique can avoid having to wait for the timout before you
  reconnect.  You may also find that the order that the parameters to
  the $qio are processed is not necessarily what you might want, and you
  really want the REUSEADDR (or REUSEPORT) option to be processed first
  for this case -- and this means you need to specify it via a separate
  $qio call.  For details on this ordering and on the multiple $qio calls,
  please see REUSEADDR in the file:
 
     TCPIP$EXAMPLES:TCPIP$TCP_SERVER_QIO.C  ! V5+
     UCX$EXAMPLES:UCX$TCP_SERVER_QIO.C      ! <V5
 
  The bit value for TCPIP$C_REUSEPORT is 0x200, and the definition for
  this bit is expected to be included in the V5.1 and later definition
  files.  This option is present in V5.0 and later.
 
  The reported "last listener" behaviour is expected and normal for
  unicast (and for multicast) addresses.
 
  Then, if this re-sequencing fails, please contact the Compaq Customer
  Support Center.
 
 

  

     

     
answer written or last revised on ( 13-JUL-2000 )
     
» close window