sending error on corrupt data

[Avery Pennarun]

On 19/11/2007, Havoc Pennington <hp at redhat.com> wrote:
> 1) Sending an error requires a message serial to reply to. Otherwise,
> nobody will get the error. But the message was corrupted.
> Possible solution: only send an error if the corruption is after we read
> the reply serial, in _dbus_header_load(). There are various possible
> corruptions before that point, but I don't know how to send errors for
> those.

Any kind of message that could get sent back over the socket at all
would be helpful.  The actual sending application, which is so
crappily written that it's sending your corrupted packets, will not
know what to do when it gets a well-directed error anyhow.  (Well,
what *should* it do?)

When debugging my own dbus transmitter it would have been really nice
to get a packet back before disconnection saying what kind of
corruption dbus thought it had seen, though. (In my case, I think it
was mostly missing serial numbers or sender strings, but I forget.)

> 2) Currently, all the code for writing out messages relies on pulling
> messages from the outgoing queue. It's an ugly layering violation to
> call _dbus_connection_send_unlocked_no_update() from dbus-transport.c,
> but I don't really have a better idea. It would be a mess to try to
> support writing out a message directly instead of putting it in the
> queue first.

You can't just add it to the queue and then flush the queue?  Buggy
applications are likely to reveal their bugginess long before they
start blasting huge amounts of data across the link.  As a bonus, you
get to deliver some of the perfectly valid enqueued responses before
you rudely hang up on the caller.

With that in mind, perhaps what you need is a
no-more-sending-or-receiving flag on each socket, where you let the
usual code flush the output queue and *then* close the socket when the
queue is empty.

> - print a warning to stderr instead of trying to talk to the
>    remote app (I don't like this idea much)

This would have helped me debug my own client, but not very much.
What I did instead (recompile dbus-daemon with debugging/tracing
enabled and run it inside gdb) was about as useful, and already works.

Have fun,

Avery