<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: UDP programming - how to specify a read timeout using io$readvblk in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6617384#M46208</link>
    <description>&lt;P&gt;Looks nice, Jess, but note that on Itanium with default compiler options that timeout will be S_FLOAT, not F_FLOAT, which might not do what you intended when passed to LIB$CVTF_TO_INTERNAL_TIME&lt;/P&gt;</description>
    <pubDate>Mon, 15 Sep 2014 19:01:46 GMT</pubDate>
    <dc:creator>Craig A Berry</dc:creator>
    <dc:date>2014-09-15T19:01:46Z</dc:date>
    <item>
      <title>UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6610466#M46201</link>
      <description>&lt;P&gt;Is it possible to specify a read timeout on a UDP socket&lt;/P&gt;&lt;P&gt;using&amp;nbsp;a sys$qiow (IO$READVBLK) like one can do using select()/recv()&lt;/P&gt;&lt;P&gt;using C-socket programming style?&lt;/P&gt;&lt;P&gt;Do I need to call some sort of sys$qiow (IO$SETMODE) with an appropriate&lt;/P&gt;&lt;P&gt;item list?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks a lot in advance.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Giovanni&lt;/P&gt;</description>
      <pubDate>Thu, 11 Sep 2014 15:09:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6610466#M46201</guid>
      <dc:creator>gmala</dc:creator>
      <dc:date>2014-09-11T15:09:25Z</dc:date>
    </item>
    <item>
      <title>Re: UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6610864#M46202</link>
      <description>&lt;P&gt;Giovanni,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&amp;nbsp; Some drivers implement a timeout option IO$M_TIMEOUT, some don't. If you haven't found it&amp;nbsp;documented for your driver, you can assume your driver doesn't have one.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp; If that's the case, you can implement your own timeout using "crossed ASTs". The idea is to have a timer with an AST that cancels the I/O, and specify an AST on the I/O that cancels the timer. In pseudo code&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;$SETIMR daytim=TimeoutInterval astadr=CancelIO reqidt=MyTimer
$QIOW chan=MyChan func=IO$READVBLK iosb=IOSB astadr=CancelTimer astprm=MyTimer (other parameters as required)



routine CancelIO
  $CANCEL chan=MyChan
end

routine CancelTimer(timerID)
  $CANTIM reqidt=timerID
end&lt;/PRE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;After the $QIOW look at your IOSB. If it is successful, the I/O "won" the race, and the timer will have been cancelled. If the timer won, the IOSB will be SS$_CANCEL or SS$_ABORT, depending on how far the I/O had progressed. There are no race conditions, either the I/O will complete or it will get cancelled.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This mechanism also works for $QIO (asyncronous) I/Os, you just have to think a bit harder about the completion paths and how you manage them.&lt;/P&gt;</description>
      <pubDate>Thu, 11 Sep 2014 22:00:54 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6610864#M46202</guid>
      <dc:creator>John Gillings</dc:creator>
      <dc:date>2014-09-11T22:00:54Z</dc:date>
    </item>
    <item>
      <title>Re: UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6610952#M46203</link>
      <description>&lt;P&gt;From what I can tell of the documentation, there's no timeout available on the TCP/IP Services $qio IO$_READVBLK call.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;As an alternative to the approach that&amp;nbsp;Mr Gillings&amp;nbsp;describes, you can also use $qio and ASTs and just leave the read hanging until something UDP happens, or until you're done with the networking.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;It's entirely possible to issue these $qio reads in a self-requeuing loop, and where the AST passes the arriving packets off to the mainline code &amp;nbsp;via an in-memory interlocked queue and (for instance) a $wake call, and the mainline processes until its done, and then issues a $hiber.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Put another way, it can be&amp;nbsp;easier to use an aio-style asynchronous program on VMS, &lt;A target="_blank" href="http://labs.hoffmanlabs.com/node/829"&gt;using ASTs and $hiber and $wake&lt;/A&gt;, rather than trying to mimic a synchronous sequence. &amp;nbsp;(Threads can also work here, but &lt;A target="_blank" href="http://h71000.www7.hp.com/wizard/wiz_6099.html"&gt;mixing threads and ASTs is tricky&lt;/A&gt;, and TCP/IP Services $qio calls will mean you're using ASTs for at least some of your processing.)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Traditional wrinkles: &lt;A target="_blank" href="http://stackoverflow.com/questions/3712151/udp-ip-fragmentation-and-mtu"&gt;packet sizes&lt;/A&gt;, fragmentation, applications&amp;nbsp;getting "stuck" if a UDP message gets lost, and UDP messages can get lost.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;$hiber and $wake wrinkles: if you use $hiber and $wake here, issue a $schdwk call as a backstop, and that'll force the mainline to wake up (maybe every 10 seconds or so) and check the queue — this is ugly, but can avoid a deadlock.&lt;/P&gt;</description>
      <pubDate>Fri, 12 Sep 2014 01:03:16 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6610952#M46203</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2014-09-12T01:03:16Z</dc:date>
    </item>
    <item>
      <title>Re: UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6611306#M46204</link>
      <description>&lt;P&gt;First of all thanks to you and Mr Gillings for your answer and suggestion.&lt;/P&gt;&lt;P&gt;Coming to my original question,&amp;nbsp;it look like &amp;nbsp;it is possible to fill-in a socket-options descriptor&amp;nbsp;like the following:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;sockopt_itemlist.length = sizeof(tmo_itemlist);&lt;BR /&gt;&amp;nbsp;sockopt_itemlist.type = TCPIP$C_SOCKOPT;&lt;BR /&gt;&amp;nbsp;sockopt_itemlist.address = &amp;amp;tmo_itemlist;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;pointing to an itemlist like&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;tmo_itemlist.length = sizeof(tmo);&lt;BR /&gt;tmo_itemlist.type = TCPIP$C_RCVTIMEO;&lt;BR /&gt;tmo_itemlist.address = &amp;amp;tmo;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;where tmo is a structure containing seconds/microseconds you want to wait (pieces of codes I found&lt;/P&gt;&lt;P&gt;somewhare&amp;nbsp;in this same blog).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Then&amp;nbsp; I wonder if passing all this stuff to a call like the following, before calling the actual sys$qiow(IO$READVBLK), could do the trick.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;status = sys$qiow(0, conn_channel, IO$_SETMODE, &amp;amp;iosb, 0, 0, 0, 0, &amp;amp;sockopt_itemlist, 0 );&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Now, TCPIP$C_SOCKOPT should apply to both TCP and UDP sockets.&lt;/P&gt;&lt;P&gt;TCPIP$C_RCVTIMEO is described (in the TCPIP programming guide) as:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P align="left"&gt;TCPIP$C_RCVTIMEO For HP use only . Sets the timeout value for a recv() operation. The argument is a pointer&lt;/P&gt;&lt;P align="left"&gt;to a timeval structure containing an integer value specified in second&lt;/P&gt;&lt;P align="left"&gt;(I'm a little bit worried about that "For HP use only").&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P align="left"&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Many thanks in advance for what you&amp;nbsp;can elaborate on this.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Giovanni&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 12 Sep 2014 10:28:18 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6611306#M46204</guid>
      <dc:creator>gmala</dc:creator>
      <dc:date>2014-09-12T10:28:18Z</dc:date>
    </item>
    <item>
      <title>Re: UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6611326#M46205</link>
      <description>&lt;P&gt;Ask HP support directly. &amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;With HP, things here probably weren't going to change all that much, so you could test that and then reasonably assume whatever&amp;nbsp;current behavior was observed would probably persist. &amp;nbsp;Now with VSI involved, it's anybody's guess what happens with the "reserved to..." stuff.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Or use the approaches that John and I have described, which are supported.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I've gotten burned by timeouts on more than a few occasions; races in the cancellation logic can be far too easy to create, and ugly to replicate. &amp;nbsp; I've found it's much simpler&amp;nbsp;to be AST-based, and to leave the $qio outstanding, and to detect when I don't care about the read response anymore within the code of the completion AST (via an interlocked bitflag or such), and to save the $cancel for when I'm shutting down the channel or the application.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 12 Sep 2014 11:01:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6611326#M46205</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2014-09-12T11:01:59Z</dc:date>
    </item>
    <item>
      <title>Re: UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6616674#M46206</link>
      <description>&lt;P&gt;Hi !&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;A target="_blank" href="http://starlet.deltatel.ru/~laishev/aaa-vms/pmas_radius.c"&gt;http://starlet.deltatel.ru/~laishev/aaa-vms/pmas_radius.c&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;		/*
		** Prepare to timeout processing
		*/
		if ( !(1 &amp;amp; (status = sys$setimr(EFN$C_ENF, &amp;amp;delta_tmo,timer_ast,&amp;amp;reqidt,0))) )
			break;

		/*
		** Wait for an answer to request from RADIUS server
		*/ 
		if ( !(1 &amp;amp; (status = sys$qiow (EFN$C_ENF,chan,IO$_READVBLK,&amp;amp;netiosb,0,0,
                                        &amp;amp;ibuf,sizeof(ibuf),&amp;amp;rem_host,0,0,0))) )
			break;

		/*
		** Check status, byte count, and remote IP address 
		*/
		if ( netiosb.iosb$w_bcnt &amp;amp;&amp;amp; (netiosb.iosb$w_status &amp;amp; 1) &amp;amp;&amp;amp;
			(auth_ans-&amp;gt;radpkt$b_id == auth_req-&amp;gt;radpkt$b_id) &amp;amp;&amp;amp;
			sock_host.sin_addr.s_addr == ipaddr )
			break;
		}

	sys$cantim(&amp;amp;reqidt,0);&lt;/PRE&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 15 Sep 2014 09:19:20 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6616674#M46206</guid>
      <dc:creator>Ruslan R. Laishev</dc:creator>
      <dc:date>2014-09-15T09:19:20Z</dc:date>
    </item>
    <item>
      <title>Re: UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6617320#M46207</link>
      <description>&lt;P&gt;I like to work on VMS programs that use ASTs;&amp;nbsp; I really do.&amp;nbsp; AST-based code, when done correctly, is frequently more efficient and less prone to race-condition issues than any non-AST solution.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;But I also recognize the fact that many users coming to VMS from other OSs may not be entirely comfortable using ASTs.&amp;nbsp; So just in case you would prefer a non-AST solution, I have attached a C&amp;nbsp; routine to this post routine as a .TXT file.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I wrote SYNCH_WITH_TIMEOUT.C back in 1993.&amp;nbsp;&amp;nbsp; Originally we used it for programs that did data-transfers using the terminal driver.&amp;nbsp; Yes, I know that the VMS terminal driver has a built-in time-out function.&amp;nbsp;&amp;nbsp; See comments about that below.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Since then I have used it for many other applications, on Alpha and IA64, and it has always worked reliably.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;A call to the synchronous SYS$QIOW() system service is documented as being identical to a call to the aynchronouse SYS$QIO() service followed immediately by a call to the SYS$SYNCH() service.&amp;nbsp;&amp;nbsp; My routine works just&amp;nbsp; like SYS$SYNCH() but it has two additonal arguments.&amp;nbsp; The I/O channel being used, and a F format floating point value for the timeout in units of&amp;nbsp; seconds. &amp;nbsp; (It would be easy to change the code to accept an integer value in .01 seconds units instead.)&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 15 Sep 2014 17:57:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6617320#M46207</guid>
      <dc:creator>Jess Goodman</dc:creator>
      <dc:date>2014-09-15T17:57:49Z</dc:date>
    </item>
    <item>
      <title>Re: UDP programming - how to specify a read timeout using io$readvblk</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6617384#M46208</link>
      <description>&lt;P&gt;Looks nice, Jess, but note that on Itanium with default compiler options that timeout will be S_FLOAT, not F_FLOAT, which might not do what you intended when passed to LIB$CVTF_TO_INTERNAL_TIME&lt;/P&gt;</description>
      <pubDate>Mon, 15 Sep 2014 19:01:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/udp-programming-how-to-specify-a-read-timeout-using-io-readvblk/m-p/6617384#M46208</guid>
      <dc:creator>Craig A Berry</dc:creator>
      <dc:date>2014-09-15T19:01:46Z</dc:date>
    </item>
  </channel>
</rss>

