My understanding is that shutdown(1) sends the "FIN" segment, which signals the other end that you are finished writing data. The other end should send back an "ACK" segment and perform a passive close on the socket.

  What happens next is the other end sends back a "FIN" segment of it's own. Your end then sends back a final "ACK", and the socket is completely closed.

  The confusing part is why you are using shutdown if you are expecting more data on the line. The model of socket communication I have seen designates that you don't send a "FIN" until you've received the data you want. (This allows more than one request per connection.)

  It sounds to me like the other end is enterpreting the initial "FIN" as the end of all communication, and is dropping any data that hasn't been sent yet. Whether this is happening on the socket level, or the application level, I couldn't tell you without seeing the code on the other end. To get around it, just hold off on using shutdown until you've received the data you requested, or until the other end initiates a shutdown.

  In a perfect world, every socket connection would follow the specification to the letter, but it doesn't happen. The above method should still work for both of your existing socket connections as well if you need to use just one bit of code for all three connections.

  I hope that helps...

  Update: I just checked W. Richard Stevens tome of sockets knowledge; "Unix Network Programming", and my thoughts are confirmed. In order to follow sockets specifications you shouldn't shutdown until you've received your requested data, or the other side begins the socket shutdown process. The fact that your original code works with the other two socket connections just means that they have coded their application to flush all data before performing the final close of the socket. A good idea, but not necesarily required.

  Update2: I guess I'm saying there should be some query string you send across the socket that warrents a response from the other end. Closing the socket is a poor way to signal you're done sending/requesting data, but it's used often enough that I guess we have to live with it.


Nuke
nuke@nuke3d.com
www.nuke3d.com

In reply to Re: Socket dilemma - sending EOF by Nuke
in thread Socket dilemma - sending EOF by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.