Cause of chat spew found.

Brian Godette (bgodette@idcomm.com)
Mon, 06 Jul 1998 12:56:19 -0600


After thinking up reasons for why chat spew was happening and how, I made
modifications to ERef to cause it to happen and verify my theories. As a
result I know now what chat spew is and what causes it, and that is that
technically the clients (both Cornell and WP) are working as they should,
however not really how the end user would like to see it.

What happens is if a client A receives hole reports (recovery requests)
from multiple clients at the same time, client A will broadcast (send to
kGroup) the recovered item instead of sending it directly to the client
that requested it (kClient). Since the recovered packet is sent to all
clients in the conference as kGroup and is marked as a recovered item, it
redisplays the item (which is technically correct according to the
technical specs for aux).

So it looks like part of my original guess was correct and what the clients
*should* do is check to see if it has received the aux item already for
CUtk recovered items, or not fill multiple hole reports as a broadcast for
CUtk items (which would be a backwards compatible fix).

And of course the reason why chat spew wasn't seen until recently was
because aux recovery was broken on non Mac cornell clients until 1.0 and on
WP versions earlier than 3.0.