CU-SeeMe UDP communications thread...

Ko Stoel (
Wed, 11 Jan 1995 05:22:11 -0500

Bart: 10jan
>I know,
>ce-seeme is not designed for these low lines (something which I think should
>be addressed...)

Ko: 16dec
>For hurds of (potential) users, 28k8 (maybe 30+ in future) is the most
>bandwidth they can afford

Michael: 10 jan
>Get a faster connection.
>to punch eight video
>streams over a 2400 baud modem
You watch them and select the interesting one keeping one left, this can be
of interest too.

Bart: 10 jan
>The modem is smoking
>So, while all this extremely heavy traffic (more then 30 kbps constant) goes
>on, my only open video window stays un-updated, with a transfer rate of zero.
>what the hell is the Reflector sending to me?????

I asked the question some weeks ago too!
Yes Yes I want to know too. The Good thing of the 'modem' CUSM users is
that that they are most likely confronted with CUSM com-limits thus
revealing possible com flaws. So don't feel ashamed not being in government
funded state-of-the-art hightech DigneyLand; it doesn't mean you have no

>try and cut
>back on any non-video related overhead
Is it overhead ? Suppose the stats in a CUSM window are not reliable or the
still video is send but the pixars are dubbed . Did you look at the
packet-loss stat?
If it is overhead What is it?? If we get some feedback we can have some
insight on a higher level dear 'dev team'

>Now, what happens here is that during a SLIP (or PPP) connection, incoming
>packets which are coming in at the UNIX Server faster then they can be send
>over the SLIP line, are being *QUEUED*!

Clogging up before a bottle-neck
Ah ..the UDProtocole
Maybe this is happening: (we have to guess: If you guess right You win a
free copy of CUSM from the 'dev team' :)

UDP packets are pumped into the net regardless they arive or not;
so on a higher level (the application pumping i.e. CUSM or Reflector) this
communication must be scaled to what is actualy deliverable . This is done
with UDP too I think. You can observe the 'packet-loss stat' in your
window, if it's not 100% some down-scaling has been done, correct?

But what can happen is that both UDP path's (receive and send) still become
glogged-up and the scale-down control can't come through. Hmmm... in my
case I am sending nothing so my scale-down feedback to the Reflector should

Scale-down must mean omitting parts of the image or images as a whole not
image queing (for a to long time-length) Maxheadroom can be so amusing :)

Aren't wishes nice; like:
A VU meter on datacom per sound , per video, per control

Ko Stoel

For info on CU-SeeMe