message lost if dbus_connection_close() follows send() too quickly

[dbus at eehouse.org]

I'm working on a bug in a client/server pair communicating over dbus
via dbus-daemon.  The server sends periodic messages to the client
using dbus_connection_send().  The client eventually sends one message
and quits, calling dbus_connection_send(), dbus_connection_flush(),
and then dbus_connection_close() before exit().  Expected behavior is
that the server still receives the message, and in fact that's what we
see 99% of the time, but occasionally it does not.  When it doesn't
it's because the dbus-daemon attempts to write one of the server's messages
to the client's socket, detects that it's no longer writable, and
closes the connection -- without ever trying to read from it.

tcpdump shows that the client's message is making it to the
dbus-daemon when this happens.

As I understand TCP, when a socket is closed on the remote end, it
remains readable locally while the rx buffer still contains data.  And
in fact dbus seems to expect this: in socket_handle_watch(), it will
not disconnect a transport on seeing DBUS_WATCH_HANGUP unless the
DBUS_WATCH_READABLE bit is *not* set.

I thought the problem was in do_writing(), where an error from
_dbus_write_socket() results in a call to do_io_error() (which calls
_dbus_transport_disconnect()) without checking whether the socket is
readable.  But removing the call to do_io_error() does not help.  We
wind up back in socket_handle_watch() and find that DBUS_WATCH_HANGUP
is set but DBUS_WATCH_READABLE is not. (DBUS_WATCH_WRITABLE is.)  It's
as if TCP were misbehaving.

I've been able to work around this problem by adding a very short
usleep() before calling dbus_connection_close() in my client, but
wonder if there's a better way.

Thanks,

--Eric
-- 
******************************************************************************
* From the desktop of: Eric House, xwords at eehouse.org                        *
*        Crosswords 4.1.4 for PalmOS now ARM-native: xwords.sourceforge.net  *
******************************************************************************