Re: Warning: Mac CU-SeeMe 3.1.0.xx

Brian Godette (
Wed, 04 Mar 1998 19:17:46 -0700

At 07:22 PM 3/4/98 -0500, you wrote:
>Ok lets put this to rest.
>I have been looking into the events of what happened here and had not
>responded until I had the full story.
> Basically
>a change occurred between the last betas in our bandwidth manager, which
>we had been working on significantly for MeetingPoint and CU-SeeMe to better
>handle changing conditions on the network (Latency and packet loss). In
>the progress of doing this and working with our internal queues a bug was
>introduced in caching this end packet information. The significance of
>the change in the queuing was underestimated, in it's effect of the gray
>scale codec.

Fair enough. Just a guess at how you're doing this, but I gather you encode
a frame, check to see if there's bandwidth available to send it, then split
it into roughly equal sized packets < 1024 bytes, and send them out, but
had neglected to mark the last packet as an EOF for the B&W codec. Easy
enough to see the oversight considering that all the other codecs don't
have EOF's and rely on sequence numbers and total frame length.

>Last note, if anyone is still interested, is that the only conscious thing
>we did with serial numbers is when we went from 2.1 to 3.0 we deployed
>a significantly more complicated encoding scheme so that
>the industrious crackers of the world would not distribute programs that
>generated numbers for our software.
I seem to remember the serial numbers changing between 2.0 and 2.1, tho it
didn't look like the encoding scheme had changed (much anyways). Which
brings up the question about video over aux update on first open. Why was
it decided to send the video as client-to-client AUX instead of
client-to-client video? Had it been sent as client-to-client video, it
wouldn't have caused all 32bit WP 2.0.* PC clients to GPF whenever they
opened vid on a 2.1 client. Yes it can be considered a "bug" in the 2.0
client not being able to handle unknown or malformed AUX packets, but
still... it should have been sent as client-to-client video.