Thursday, March 27, 2008

libsecondlife callback twice

I've found that quite a decent amount of folks arrive on this blog with the search terms "libsecondlife callback twice" - I assume that in libsl there is a condition where the chat callback gets called twice during the chat...

I'll describe what I see on the network with the "classic" client and then you can go and debug the libsl, if it has a bug or not :-)

When the user starts to type, the viewer sends the packet "ChatFromViewer" with the type equal to 4 and empty message - this is a sign that the user has started typing, and I'd suppose that this also starts various typing animations and typing sounds.

When the user finishes typing the message, then this message is sent within the packet of the same kind, but with the type 1.

Afterwards, always, there is a packet with the type 5 - which, it seems, signifies the "end of the typing business" from this user - if I start typing and then backspace out the characters - then I get the type 5 packet.

What is interesting is that depending on the network (or on the client itself?) I've seen the type 5 arrive before type 1.
I do not yet properly deal with the resequencing of the packets and seen this only once - so do not know whether it is a bug on the client, in my code, or on the loopback interface (even though the second is the most probable).

Possibly the sim sends similar kinds of packets, and the libsl does not fully handle them (or does not handle the out-of-order scenario - which obviously might be symmetric. I'd suggest to do the packet debugging on the libsl with the slproxy and capture which packets trigger the condition - then you might be closer to finding the cause of the problem.

If there are "genuine" duplicates - well, that might be a problem... Of course, one can keep a queue of the "recently seen packets" and throw away the repetitions, but then you will not be able to handle some corner cases (a user very frequently typing the same stuff - could be needed for whatever odd scenario).


That's what I have to say about this topic - maybe you find it useful, maybe not - but without a better problem description it's hard to say - so feel free to write up something in the comments on whether I guessed the problem correctly, and if you find some solution in libsl for it :) good luck!

4 comments:

Anonymous said...

This is one of the downfalls of UDP. You don't really control the schedule of packets.

Dalien said...

Right. Neither you know about their delivery. Although I think the packets should have the sequence - so barring the bugs, there should be no big issue. But another thing I could think of is the ACK from the libsl being lost, and thus the server will resend the packet - although why this would happen only with the chat packets is a mystery :) (but again, this post in its entirety is a pure speculation based just on the three search terms :)

Anonymous said...

Put it in mantis.

http://bug.openmv.org/

Dalien said...

Baba: I can't do it because this post is merely a speculation on what the folks see. Maybe someone drops a note on what the *actual* symptom is - preferrably on mantis you mentioned, and then includes the link to the bug here.