Re: Restrictions on transimssion rates if isdn used with cuseeeme?

Mark Badger (
Mon, 10 Feb 1997 14:24:00 -0800

Brian O'Shea wrote:

> -This is a very simple concept, and should be easy to implement, tho it would
> -require changes to both the reflector and the client. The new reflector
> -code would check the version of the client, and if it's new enough and has
> -the capability, then the adjustment messages would be sent. If the client
> -is too old, then you would just get the same old "Please adjust..." message.
> We're making sure the upcoming 3.0 client has this functionality so that when
> the 3.0 reflector comes out later on, the 3.0 clients will automatically
> adjust to the reflectors settings.

why perform these adjustments at the client end ? as you say yourself,
this leads to a versioning problem. much better to do it in the
reflector, then it is controlled "at source" and it will be compatible
with any client ?

so: if a reflector is set up to accept a client rec cap of 30, and a
client connects with a rec cap of 200, the stream the client gets sent
is as if the client had connected at 30 ? hey presto ?

i can see that the problem is perhaps trickier with the send cap, but
the same principal may well apply equally as effectively ?

what seems to be a problem with the strategy, as outlined, is that White
Pine are effectively improving the behaviour of their reflector/client
relationship without solving the issue at hand in a manner that is
compatible with any client.