sockets: How to know when your data is sent

Jp Calderone exarkun at divmod.com
Thu Nov 11 16:05:00 CET 2004


On 11 Nov 2004 06:46:45 -0800, mederis at hotmail.com (Marc Ederis) wrote:
>Richie Hindle <richie at entrian.com> wrote in message news:<mailman.6214.1100100615.5135.python-list at python.org>...
> > If you want to ensure that all the data has been sent before *closing* the
> > socket, which sounds like Marc's requirement, you can use
> > setsockopt(SO_LINGER):
> > 
> >        SO_LINGER
> >               Sets  or gets the SO_LINGER option. The argument is
> >               a linger structure.
> > 
> >               struct linger {
> >                   int   l_onoff;    /* linger active */
> >                   int   l_linger;   /* how many seconds to linger for */
> >               };
> > 
> >               When enabled, a close(2) or  shutdown(2)  will  not
> >               return  until  all  queued  messages for the socket
> >               have been successfully sent or the  linger  timeout
> >               has been reached. Otherwise, the call returns imme�
> >               diately and the closing is done in the  background.
> >               When  the  socket  is closed as part of exit(2), it
> >               always lingers in the background.
> > 
> > (from the GNU manpages).  I don't believe that's true for shutdown() on
> > all platforms, but I do believe it's true for close() / closesocket().
> > Calling it from Python is a bit of a chore involving the struct module,
> > and is left as an exercise for the reader.  8-)
> 
> SO_LINGER... Interesting, I'll keep that in mind for the future. In
> the end, acknowledging receipt of the data, as it was arriving at the
> server, turned out to be the best solution for me. I wanted to be able
> to show a progress bar (at the client) of the data being sent.
> 

  All this talk of fun socket options is neat, but I'd like to suggest you stick with your current instinct, as you decided for now and in the future.

  SO_LINGER only lets you know that the peer has ACK'd your data.  This means, typically, that it reached a kernel buffer.  It says nothing about the application level, and the application level is all you really care about.

  Doing application-level ACKs is the only really reliable way to know if your data was received.

  Jp



More information about the Python-list mailing list