<?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: Socket communication problem in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844499#M37573</link>
    <description>&lt;P&gt;Hi!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Did you set KEEPALIVE for the socket ?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 23 Mar 2016 10:11:03 GMT</pubDate>
    <dc:creator>Ruslan R. Laishev</dc:creator>
    <dc:date>2016-03-23T10:11:03Z</dc:date>
    <item>
      <title>Socket communication problem</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844450#M37572</link>
      <description>&lt;P&gt;I am playing around with TCP socket communication using $QIO and ASTs.&lt;BR /&gt;My program looks like this:&lt;/P&gt;&lt;P&gt;- initialize local socket&lt;BR /&gt;- connect to remote system&lt;BR /&gt;- set up $QIO(READVBLK) triggering ReadAst on completion&lt;BR /&gt;- build message to send&lt;/P&gt;&lt;P&gt;- send the message using this code snippet&lt;BR /&gt;rtc = sys$qio ( EFN$C_ENF,&lt;BR /&gt;WriteAstParam.channel,&lt;BR /&gt;IO$_WRITEVBLK,&lt;BR /&gt;WriteAstParam.iosb,&lt;BR /&gt;(void *)&amp;amp;TcpWrittenAst,&lt;BR /&gt;0,&lt;BR /&gt;WriteAstParam.buf,&lt;BR /&gt;WriteAstParam.buflen,&lt;BR /&gt;0, 0, 0, 0 );&lt;/P&gt;&lt;P&gt;on completion of this IO, TcpWrittenAst is triggered,&lt;BR /&gt;where I check the IOSB (it is global), both status and count.&lt;/P&gt;&lt;P&gt;This works fine as long as the physical connection (cable) exists,&lt;BR /&gt;but after removing the cable to the remote peer, and trying to&lt;BR /&gt;send the next message, TcpWrittenAst is triggered immediately&lt;BR /&gt;and iosb.status is 1 and iosb.count=number of bytes to be sent.&lt;/P&gt;&lt;P&gt;tcptrace shows, that there is no ACK message from the remote computer,&lt;BR /&gt;so the message will never be received by the remote system although&lt;BR /&gt;my program "believes" that the message has been sent successfully.&lt;/P&gt;&lt;P&gt;TCP/IP stack retries to send the message until the keepalive mechanism&lt;BR /&gt;fires ReadAst, where I get an appropriate iosb.&lt;/P&gt;&lt;P&gt;That's far too late !&lt;/P&gt;&lt;P&gt;Is there a chance to be informed earlier about the existence&lt;BR /&gt;of a connection problem ?&lt;/P&gt;&lt;P&gt;This behaviour has been verified on&lt;/P&gt;&lt;P&gt;VAX/VMS v7.3 with TCP/IP v5.3 ECO 4&lt;BR /&gt;AXP/VMS v7.3-2 with TCP/IP v5.4 ECO 7&lt;BR /&gt;AXP/VMS v8.4 with TCP/IP v5.7 ECO 4&lt;BR /&gt;I64/VMS v8.4 with TCP/IP v5.7 ECO 5&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 23 Mar 2016 07:31:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844450#M37572</guid>
      <dc:creator>dschwarz</dc:creator>
      <dc:date>2016-03-23T07:31:31Z</dc:date>
    </item>
    <item>
      <title>Re: Socket communication problem</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844499#M37573</link>
      <description>&lt;P&gt;Hi!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Did you set KEEPALIVE for the socket ?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 23 Mar 2016 10:11:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844499#M37573</guid>
      <dc:creator>Ruslan R. Laishev</dc:creator>
      <dc:date>2016-03-23T10:11:03Z</dc:date>
    </item>
    <item>
      <title>Re: Socket communication problem</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844656#M37574</link>
      <description>&lt;P&gt;Are you also checking the SYS$QIO immediate return status in '&lt;SPAN&gt;rtc'?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Testing IOSB in the ast function is the critical part, and the AST will not fire if the SYS$QIO call itself failed, but maybe there is an informational or something?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Is it possible to attach a larger code snippet with some variable and function definitions, ideally post enough for someone to change thet target and run a test, if they have the time and opportunity.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Hein&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 23 Mar 2016 15:57:29 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844656#M37574</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2016-03-23T15:57:29Z</dc:date>
    </item>
    <item>
      <title>Re: Socket communication problem</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844667#M37575</link>
      <description>&lt;P&gt;Welcome to the usual sorts of fun with TCP. &amp;nbsp; &lt;A href="http://www.linuxquestions.org/questions/linux-networking-3/how-to-detect-broken-connection-before-sending-data-with-sockets-840988/" target="_blank"&gt;What you're experiencing is expected&lt;/A&gt;&amp;nbsp;and &lt;A href="http://www.gnugk.org/keepalive.html" target="_blank"&gt;unfortunately common&lt;/A&gt;&amp;nbsp;misbehavior of the &lt;A href="http://www.codeproject.com/Articles/37490/Detection-of-Half-Open-Dropped-TCP-IP-Socket-Conne" target="_blank"&gt;half-open&lt;/A&gt; morass. &amp;nbsp;&amp;nbsp;Your message really was sent, as far as the sender can&amp;nbsp;determine. &amp;nbsp; Whether or not the message might ever arrive, if/when the disconnect is detected and/or resolved?&lt;/P&gt;&lt;P&gt;For this case, set&amp;nbsp;&lt;SPAN&gt;TCPIP$C_KEEPALIVE on the connection, and — given you're using ASTs and $qio — also have a look at the semi-related&amp;nbsp;&lt;/SPAN&gt;TCPIP$C_MSG_NBIO while you're looking at the code. &amp;nbsp; Also at moving to TLS, given expectations of security and integrity.&lt;/P&gt;&lt;P&gt;Expect to have to get a response from the other end to confirm reception, too — which tends to lead toward the use of &lt;A href="http://the-paper-trail.org/blog/consensus-protocols-paxos/" target="_blank"&gt;Paxos&lt;/A&gt; or some other 2PC or 3PC scheme.&lt;/P&gt;&lt;P&gt;Some of the other common pitfalls with TCP and IP networking:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;TCP doesn't do datagrams, it does streams. &amp;nbsp; UDP and DTLS do datagrams, though not with guaranteed delivery.&lt;/LI&gt;&lt;LI&gt;Do NOT assume one message sent means one message arriving. &amp;nbsp;Receivers can be handed anything from&amp;nbsp;one byte to the whole "datagram", and it wouldn't surprise me to receive several "datagrams" together in one big wad, depending on the protocol design.&lt;/LI&gt;&lt;LI&gt;Do NOT assume that sending the message means it will be received.&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;So as mentioned earlier, if you want to know when the connection drops, then you're going to be using keepalive.&lt;/P&gt;</description>
      <pubDate>Wed, 23 Mar 2016 16:16:55 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844667#M37575</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2016-03-23T16:16:55Z</dc:date>
    </item>
    <item>
      <title>Re: Socket communication problem</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844923#M37576</link>
      <description>&lt;P&gt;Keepalive is enabled.&lt;BR /&gt;The immediate return status of sys$qio is checked and is always ok - as expected.&lt;/P&gt;&lt;P&gt;This program works fine for more than 10 years as long as the network connection is not broken.&lt;BR /&gt;This does not happen very often at our site, in fact it never did in the last 10 years.&lt;BR /&gt;A collegue of mine has found this behaviour during some tests of another piece of software he is working on&lt;BR /&gt;and has been concerned about this.&lt;/P&gt;&lt;P&gt;To be sure that the "messages" really reach the recipient, I have to introduce some confirmation layer of my own.&lt;/P&gt;&lt;P&gt;Thank you very much&lt;/P&gt;</description>
      <pubDate>Thu, 24 Mar 2016 11:33:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/socket-communication-problem/m-p/6844923#M37576</guid>
      <dc:creator>dschwarz</dc:creator>
      <dc:date>2016-03-24T11:33:32Z</dc:date>
    </item>
  </channel>
</rss>

