-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
MenTaLguY wrote:
On Tue, 9 May 2006 13:58:23 -0700, Bryce Harrington <bryce@...961...> wrote:
For what it's worth, I have a suspicion that possibly the thing that may have broken it was selecting a number of items with many nodes, cut and pasting them, and then moving them around a lot. This process seemed to generate a ton of messages, and the server bogged down trying to send that out to others in the conference room. This seems like a pretty common usage situation, so if this is what causes a lot of the traffic, perhaps there's an optimization trick that could be done? (E.g., transmitting the operation to perform on the object(s) rather than the objects themselves, and then syncing up the objects later once traffic has become quiescent again?)
Currently we simply serialize the same transaction logs we use for undo/redo, so it's just a stream of operations. As far as I know we never send objects directly. I think it's a pretty good design (and usually the most efficient), but in a few cases (like pasting a large subtree) it might be more efficient to explicitly send an XML fragment rather than a series of deltas describing its makeup.
Yeah, at the moment, the only things that are sent are serialized XML::Events.
Something else about Inkboard's sending behavior: Inkboard aggregates as many of these serialized XML::Events as possible into one XMPP message of some pre-determined length, and then send that out. (The code that handles that is in jabber_whiteboard/message-aggregator.cpp.)
The rationale for that behavior was as follows: the current version of Inkboard checks for new messages using a signal that is triggered every 10ms or so. Having many small messages with one event each means that we spend only a little bit of time processing events and most of the time sitting around waiting for the trigger to fire again; having many events in one message allows us to do more work in fewer timer events.
The maximum size for an aggregate event is fixed at 16 kB. This was originally supposed to be set by Inkboard probing the Jabber server for its limits, but I never got around to implementing that.
I don't know if this is contributing to the MUC death, but it seems relevant.
This gives an idea - what about if we set up our own jabber server for logging into, and put that as the default in the dialog box? This would kill two birds: It will encourage users to avoid servers other than our known good one (they'd have to do extra work to override it), plus would make life easier for testers, who currently have to re-type all the login info each time they re-login. Plus, hardcoding default text into widgets is very easy.
Yes! That's a very, very good idea.
I agree.
-mental
- - David