On 19/11/2007, Havoc Pennington 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 _______________________________________________ dbus mailing list dbus@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dbus