Re: Disconnect:How to ?

Michael Sattler (msattler@jungle.com)
Thu, 9 Feb 1995 16:35:38 -0500


At 06:56 2/9/95, Peter Fabian wrote:

>After disconnecting from the CU-SeeMe,it starts "polling"
>the IP adresses and keeps connecting and connecting and ...
>Is it normal behaviour ?

Normal? Yes. Desirable? No. Known? Yes. Read on:

<!-- ----------------------------------------------------------- --><HR>
<H3>Why does a reflector sometimes continue to send to me even after I've
disconnected?</H3>

<CITE>Tim Dorcey (T.Dorcey@cornell.edu) said:</CITE><P>

When you close a connection, the applications sends a repetative series of
"Close Connection" messages. Hopefully, at least one of these gets through,
but on a bad connection, they might all be lost. Hence, the reflector will
also kill a connection if it hasn't received anything from a participant
for some time. Now, it is the nature of the CU-SeeMe protocol that the
control packets used to maintain a connection are indistinguishable from
those used to initiate it. So, when an application closes a connection, it
ignores anything from that same address for some period of time, to prevent
any left-over (maintenance) packets from the original connection from being
interpreted as initiation of a new connection. The different time-out
parameters are chosen so that, in theory, the reflector time-out should
occur before the application begins accepting packets from that address
again. With a bad connection or a bogged down reflector, this logic
apparently fails, and we need to re-examine it. As a work-around you
can:<P>

<OL>
<LI> Connect immediately to some other reflector, or
<LI> Quit the application
</OL><P>

A similar problem that occurs with bad connections is that video windows
that you close keep popping back open. What happens here is you close a
window, but then, as a result of packet loss, you hear nothing from that
participant for some time and "time them out." When something does happen
to get through from them, it is treated as a new participant and their
window is automatically opened (as it is for all "new" participants).
In the recently released version 0.70b1, there is a preferences item where
you can set the maximum number of windows that you want displayed at any
time. With a low capacity connection, this should be set to a very low
number. You can then select the partipant(s) you want to watch from the
Participants menu. Note that the packet-loss/time-out phenomenon will still
occur, but the participants will be coming and going from the menu instead
of your monitor.<P>

Another source of reflector mis-behavior to look for is a full file system
where the reflector is writing its log file. This generates a system error
each time the reflector tries to update the log and slows it down enough to
disrupt the connection protocol. If you don't specify a LOG-LIMIT in the
reflector configuration file, the default is 10,000 lines.
Make sure you have room for it on your system.<P>

-----------------------------------------------------------------------+
Michael Sattler <msattler@jungle.com> San Francisco, California |
Digital Jungle Consulting Services http://www.jungle.com/msattler/ |
|
You couldn't get a clue during the clue mating season in |
a field full of horny clues if you smeared your body with clue musk |
and did the clue mating dance. - Edward Flaherty |