Professional Web Applications Themes

close and O_NONBLOCK on TCP/IP socket in Linux - UNIX Programming

Hi How can i make sure that all data queued for write on a socket with O_NONBLOCK set is transmitted (or timeout reached) with a multiplexd application using select()? My problem is that if i call close with O_NONBLOCK set, the pending tx data is discarded. If i call close with O_NONBLOCK cleared and SO_LINGER set, my process blocks making it unresponsive to other sockets. Ideally i would want the kernel to keep trying to send data after close until a timeout and silently deallocate the socket after send completion or timeout. Close manpage says: "If the O_NONBLOCK or O_NDELAY ...

  1. #1

    Default close and O_NONBLOCK on TCP/IP socket in Linux

    Hi

    How can i make sure that all data queued for write on a socket with
    O_NONBLOCK set is transmitted (or timeout reached) with a multiplexd
    application using select()?

    My problem is that if i call close with O_NONBLOCK set, the pending tx
    data is discarded. If i call close with O_NONBLOCK cleared and
    SO_LINGER set, my process blocks making it unresponsive to other
    sockets.

    Ideally i would want the kernel to keep trying to send data after
    close until a timeout and silently deallocate the socket after send
    completion or timeout.

    Close manpage says: "If the O_NONBLOCK or O_NDELAY
    flag is set, or if there are any pending signals, close()
    does not wait for output to drain, and dismantles the STREAM
    immediately."

    socket manpage about SO_LINGER: "When enabled a close(2) or
    shutdown(2) doesn't return until all queued messages for the socket
    have been successfully sent or the linger timeout has been reached."

    My problem is: if i use linger my process will block, if i use
    O_NONBLOCK, my data will be discarded.

    regards,
    Torsten
    Torsten Guest

  2. #2

    Default Re: close and O_NONBLOCK on TCP/IP socket in Linux


    "Torsten" <dk> wrote in message
    news:google.com...
     

    By closing down the connection gracefully.
     

    Where did you see that?
     

    Correct.
     

    Which 'close' manpage is that? That's definitely not standard behavior.
     

    I guess you'll have to call 'shutdown' and then wait for the shutdown to
    complete in a non-blocking way. This is what you should be doing anyway,
    otherwise what happens if other side sends some more data just before you
    call 'close'?

    DS


    David Guest

  3. #3

    Default Re: close and O_NONBLOCK on TCP/IP socket in Linux

    "David Schwartz" <com> wrote in message news:<c1jdfo$re2$webmaster.com>... 
    >
    > By closing down the connection gracefully.

    >
    > Where did you see that?

    >
    > Correct.

    >
    > Which 'close' manpage is that? That's definitely not standard behavior.[/ref]


    Can't remember where. This one says the same:

    http://www.scit.wlv.ac.uk/cgi-bin/mansec?2+close

    Maybe i read it wrong. I guess the above behaviour only aplies to
    STREAMS-based FD's (whatever that is).

    I had another error in my program that made me think the problem was
    with the way i called close, but now close appears to do what i want
    it to do.
     
    >
    > I guess you'll have to call 'shutdown' and then wait for the shutdown to
    > complete in a non-blocking way. This is what you should be doing anyway,
    > otherwise what happens if other side sends some more data just before you
    > call 'close'?
    >
    > DS[/ref]

    I guess they would get broken pipe, which is what they should get if i
    disconnect. Obviously i do not close the stream before i have finished
    reading what i am interested in from the peer.

    I have searched the web but failed to find out how to "wait for the
    shutdown to
    complete in a non-blocking way.". Maybe i should just wait for select
    to report the FD as writable after nonblocking shutdown of write?. But
    then again, my info page (redhat 7.2 info pages:
    Libc->Sockets->Open/Close Sockets->Closing a Socket) says about
    shutdown:

    quote

    - Function: int shutdown (int SOCKET, int HOW)
    The `shutdown' function shuts down the connection of socket
    SOCKET. The argument HOW specifies what action to perform:

    `0'
    Stop receiving data for this socket. If further data
    arrives,
    reject it.

    `1'
    Stop trying to transmit data from this socket. Discard any
    data waiting to be sent. Stop looking for acknowledgement
    of
    data already sent; don't retransmit it if it is lost.

    `2'
    Stop both reception and transmission.

    end quote

    My program does what i want it to if i call close after finishing
    write (no shutdown), but i would prefer not to rely on behaviour that
    is not explicitly stated in the manual. I am trying to find some
    doentation that confirms that what i am doing is correct. In my
    info pages i could find nothing about handling of pending transmit
    data during close of a nonblocking socket.

    Torsten
    Torsten Guest

  4. #4

    Default Re: close and O_NONBLOCK on TCP/IP socket in Linux

    In article <google.com>,
    dk (Torsten) wrote:
     

    You can't. If you need to be sure that the remote application has read
    all the data before you close, you should implement this in the
    application protocol.

    --
    Barry Margolin, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Guest

  5. #5

    Default Re: close and O_NONBLOCK on TCP/IP socket in Linux


    "Torsten" <dk> wrote in message
    news:google.com... [/ref]

     


    Actually, they'll get 'connection reset by peer', which will lead them
    to believe that an error took place.

     


    No, keep selecting for 'read' and wait until 'read' returns zero. That's
    how a closed connection is indicated to a non-blocking program.

     

    If and only if the other side does not try to send any data before you
    call 'close'.
     


    Don't close the socket, shut it down and then wait for it to complete
    the shutdown. Then and only then release the socket descriptor.

    DS



    David Guest

  6. #6

    Default Re: close and O_NONBLOCK on TCP/IP socket in Linux

    On 2004-02-26, David Schwartz <com> wrote: [/ref]
    >

    >
    >
    > Actually, they'll get 'connection reset by peer', which will lead them
    > to believe that an error took place.[/ref]

    Just to be clear in that. After local side is closed, remote shall get
    FIN. If they don't read, but only write, then they won't see FIN, and
    then they won't see Reset By peer and as final measure they will get
    Broken pipe. If they read then they shall see FIN and stop sending.
     
    >
    >
    > No, keep selecting for 'read' and wait until 'read' returns zero. That's
    > how a closed connection is indicated to a non-blocking program.
    >
    >[/ref]
    [...] 
    >
    > If and only if the other side does not try to send any data before you
    > call 'close'.[/ref]

    Strange statement. This is true only if the application of OP is
    interested in the data that remote sends. But according to the words of
    OP the socket is closed after he got what he wanted. The rest of stuff is
    not interesting for him. I assume that application of OP has done all
    necessary things to warn remote side that connection will be closed
    (this is the matter of politness though, not technical requirement).
     
    >
    >
    > Don't close the socket, shut it down and then wait for it to complete
    > the shutdown. Then and only then release the socket descriptor.[/ref]

    This is not absolutely necessary. It highly depends on the protocol.
    Take for example HTTP 1.0. Client sends request and then to mark end of
    request it does shutdown for write and keeps reading the socket. Server
    after sending the response simply closes connection because it shall not
    read anything else from client.

    In SMPP protocol the side that wants to close the socket sends special
    PDU to the peer, after getting response to that PDU, again it simply
    closes the socket, without using shutdown, because there shall be
    nothing else coming from the peer, and if someting comes then it is
    problems of the peer.

    The main point here is this. After application calls 'close' on the
    stream socket, kernel makes sure that all the data in the buffers, and
    the FIN packet are delivered to the peer. All incoming data for that
    connection shall be thrown away and RST shall be sent (after the FIN was
    sent). This is the behaviour of Linux 2.4.x. I can't speak for other
    operating systems. The best for the OP would be to check man pages for
    his system and not for unknown system in the internet.

    Andrei
    Andrei Guest

Similar Threads

  1. #40041 [NEW]: fsockopen doesn't close socket at timeout
    By nhnui dot mail at gmail dot com in forum PHP Bugs
    Replies: 1
    Last Post: January 6th, 04:45 PM
  2. socket handling (LINUX)
    By matt.williams in forum Macromedia Flash Player
    Replies: 0
    Last Post: October 24th, 11:28 AM
  3. UDP socket close problem
    By Mark in forum UNIX Programming
    Replies: 9
    Last Post: December 8th, 09:13 AM
  4. odd perl & linux socket query problem.....
    By Fark in forum PERL Beginners
    Replies: 3
    Last Post: October 6th, 08:19 PM
  5. How to force a socket to close ?
    By Paul LAURENT in forum UNIX Programming
    Replies: 8
    Last Post: July 8th, 01:20 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139