Open GoogleCodeExporter opened 9 years ago
I suspect this may be because there is no control flow for closing a wave
session / mux, so it may be that two muxs are competing over the same channel,
and somehow conflicting?
Original comment by hearn...@google.com
on 29 Oct 2010 at 3:40
Problem found.
Since there is no mechanism in the old protocol for a client to close a wave
session, then after opening a wave for the second time, the server sends
duplicate updates. One is an ack, one is an incoming delta. Since the
client-side socket layer demultiplexes these messages based on wavelet name,
then both messages go to the new mux, and the channel dies.
Client-side solution seems possible: the updates are distinguishable by channel
id. Updates that come in for closed channels can just be ignored by the client.
Original comment by hearn...@google.com
on 29 Oct 2010 at 4:39
Tried to notify David after I saw his related post here
http://groups.google.com/group/wave-protocol-code-discuss/msg/7a68d3c6b378ddf5
that the described bug is most likely already reported here
http://code.google.com/p/wave-protocol/issues/detail?id=100. Just in case
nobody noticed.
Original comment by horst.an...@gmail.com
on 29 Oct 2010 at 9:06
Issue 100 has been merged into this issue.
Original comment by hearn...@google.com
on 29 Oct 2010 at 10:19
Update: this issue has been patched over for now, with some client-side
filtering.
Once the new protocol is rolled out, the ability for the client to close wave
streams should fix this issue properly. Leaving this issue open until then.
Original comment by hearn...@google.com
on 7 Nov 2010 at 12:52
Original issue reported on code.google.com by
hearn...@google.com
on 29 Oct 2010 at 3:03