Re: White Pine 3.1.1 Final Release

Larry Chace (RLC1@etnainstruments.com)
Thu, 2 Jul 1998 08:23:06 -0400


Jason recently wrote:
>
>As far as the chat spew is concerned...my thoughts on it (spurred on by
>Brian Godette after having talked to him last night)..
>
>Back when Larry Chace admitted there was a current glitch in aux-data that
>went unnoticed into just a couple of months ago, Steve Edgar fixed it with
>the 1.0 version. I believe that problem had to do with chat recovery. Up
>until 1.0, chat recovery never worked. Now that it does work, it seems
>there's some more problems. But I'm not sure if the fix that Steve
>applied to the 1.0 version was also applied to the White Pine version.
>That would explain some of the inconsistencies perhaps. My guess is that
>the latest White Pine 3.X clients don't "see" the chat spew because that
>chat spew is recovered chat. Since chat recovery never worked with the
>White Pine version, it wouldn't see the problems with the recovered chat.
>
>It's an interesting problem...now I'm more inclined to think that Brian
>Godette is right...it's a legacy problem from aux-data. Hmm..if only
>formal methods and proofs were easier to deal with, problems in protocols
>could be detected before the implementation phase.

As the designer and coder of the Aux Data Transporter in Cornell's Mac and
Windows versions of CU-SeeMe, I had posted to this list on 5/8/98 a message
about an error recovery problem, saying:

>The effect is that a Windows recipient of an Aux Data item (such as a line
>of Chat) might fail to receive the item. Short items like Chat lines are
>actually sent 3 times, and so if the recipient fails to receive all 3
>copies but does manage to later recieve a report that the item had been
>sent, then the recipient will construct an invalid request for
>re-transmission of the item.

>Since the error report is invalid, the original sender will ignore it and
>will not re-send the missed item.

>Note that for this to happen, the recipient must have missed all 3 original
>copies but still got the later "availability" report. The likelihood of
>this happening is "small" (for some values of "small")! ;-)

The careful reader will notice several inconsistencies between Jason's
conjectures and my comments. If some client is "spewing", then that is
totally unrelated to the error recovery bug I described, and so fixing that
bug can have no effect upon the "spewing".

To claim that "recovery never worked" is incorrect. I believe (but cannot
be certain), that the once-published Web pages with the CU-SeeMe packet
formats also included a detailed description of the Aux Data Transporter
mechanism (the vehicle that is used to send and receive "chat" data as well
as other types that are not video and not audio).

Perhaps I'm being too sensitive, but it really bugs me to see conjecture
being promoted as "fact", particularly when clear and specific information
has already (but not too long ago) been published.

I do not know if the White Pine versions of CU-SeeMe use the very same Aux
Data Transporter code that I wrote. If, in fact, it is true that only the
White Pine clients send out the "spew", then, perhaps, White Pine has made
some changes and those changes need to be examined.

In a more general sense, it is also true that the none of the "Chat" or
"Talk" code (that I have examined) has really bothered to take advantage of
various features in the Aux Data Transporter that were included
specifically to try to help deal with the myriad of problem that can occur
in a CU-SeeMe conference. Of course, when we were developing CU-SeeMe we
were concentrating on video first, audio second, and "chatting" as a
distant third. It was amazing (and somewhat disappointing) to see that in
may instances CU-SeeMe was just being used as a fancy chat problem, and
much of the chat information (at least on the Cornell reflector) seemed to
be such meaningless drivel (at least to this observer). Sigh!

Larry Chace <RLC1@etnainstruments.com>