On Tue, May 09, 2006 at 11:23:11AM -0700, MenTaLguY wrote:

On Tue, 9 May 2006 10:44:31 -0700, Bryce Harrington <bryce@...961...> wrote:

...

Also, given our recent experience, it might be wise to do a bit more testing against test jabber servers, and make inkboard a bit more robust. Getting inkboard stable enough for us to use reliably on our own chat servers will give us confidence in recommending it for others to use.

This sounds more like an issue of the robustness of the jabber server rather than inkboard per se.

Of course, what I meant was "make the inkboard/jabber client-server system a bit more robust."

Effectively, in a client-server system it doesn't matter whether the fault lies with the client or the server; if the system as a whole is not robust, the user's experience will be poor.

If the issues are limited to this particular server, then it would be good to know, so we can recommend a better server. However, if inkboard is triggering bugs in other servers as well, then we've got a larger issue, and it may be worth adjusting inkboard to avoid putting servers into those situations if possible.

Bryce

On Tue, May 09, 2006 at 01:59:48PM -0500, Bob Jamison wrote:

MenTaLguY wrote:

...

On Tue, 9 May 2006 10:44:31 -0700, Bryce Harrington <bryce@...961...> wrote:

...

Also, given our recent experience, it might be wise to do a bit more testing against test jabber servers, and make inkboard a bit more robust. Getting inkboard stable enough for us to use reliably on our own chat servers will give us confidence in recommending it for others to use.

This sounds more like an issue of the robustness of the jabber server rather than inkboard per se.

-mental

I agree. Likely Jabberd1 has always been tested with the same set of small, uniform size chat packets that everyone normally uses. Maybe it has never been given the stress of something like Inkboard before, with a rapid series of large packets. Sometimes they can be -very- large, like when an embedded image uses the xlink:href="data:stuff" attribute. Jabberd2 might be better, but who knows?

However, we should probably look at how to get Inkboard to play nicely with all Jabber servers, even the marginal and outdated ones. Like making the protocol itself be smart/efficient enough to consume less bandwidth and require fewer packets. Something like how TCP/IP uses fragmentation to traverse less-than-optimal links, or how NFS has gone through considerable evolution to make it less chatty. For example, Jabber has a streaming extension for transferring streams or large objects.

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?)

Jabber server owners would hunt us down in angry mobs with torches and pitchforks if we released Inkscape into the wild on millions of CD's in a form that wreaks havoc on their machines and networks.

Yup.

As an aside: Since all of the traffic goes through the login Jabber server no matter which conference server is hosting the MUC room, people testing Inkboard should remember to log in to the test server directly.

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.

Longer term, we'd probably want a smarter mechanism to remember servers and such, but this would at least address immediate needs, and let us put off the better but more complex solution until later.

Bryce

-----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

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.

I commited a patch from Botty(sp?) in jabber which remembers the servers / login info on use, of course its easy to add a default one in there

I think a testing server hosted by inkscape is a good idea, for now ive stopped testing as its really annoying for everyone else to keep bringing down gristle muc

Currently there are 2 main problem for testing,

muc wont work on pretty much any server ive tested aside gristle, the verification code in there is a bit of a hack because seemingly old muc servers didnt provide the rosters correctly, hopefully ill get this fixed by tomorrow

Authentication with jabber.org is problematic, loudmouth initialise a stream with the host string including the resource (/Inkboard) in the name, most servers ignore it, jabber.org doesnt (the spec suggests that jabber.org is right to), however, leaving out the resource means poeple logged in to the same account on both their chat client of choice, and inkboard. get their inkboard messages recieved by their chat client as a pm, which is no good.

Ill send of an email to the loudmouth list to hopefully get a fix for that

Dale