From: mailrus!gatech!mit-eddie!liverpool.media.mit.edu!testarne@uunet.UU.NET (Thad E Starner)
Subject: Re: TECH: Synchronized communications between various machines
Date: Tue, 14 Apr 1992 01:46:14 GMT
Organization: MIT Media Laboratory


	When you're dealing with something as low bandwidth as an RS-232 line
you may want to consider all sorts of cheats.  A lot depends on what your data
is going to look like.

(1) For many of the methods already suggested, you may want to degrade the
    graphics on the lower end machines.  For instance, use lower resolution.
    If the user wants better, let him buy a better system.

(2) If your data is relatively sparse (low bits per graphics object, not 
    saturating your bandwidth), you may just want to flood information to the
    machines as fast as possible.  If a machine gets behind, it throws away
    all except the most recent set of states that have come across.

(3) If you have a known max graphics delay, you can just send updates at that
    speed. While the lag may seem bad at first, you can compensate by using
    predictive filters (yeah, I know, get off my soapbox) to send your best guess
    at what the world will look like in 1/nth of a second in the future.  We use
    Kalman filters for our polhemi, but for many applications, simple prediction 
    based on velocity or velocity and acceleration without the noise reduction
    could be OK.  These extra processes tend to take little process time.

(4) In general I recommend making things asynchronous, but for some applications
    this may be not feasible (big lags).  However, it allows the people willing
    to sink money into good machines to have better quality, which is a good
    technology pusher.

(5) Split things up into several processes.  Many multi-tasking operating
    systems do the right thing (or a first approximation to it) so that this
    works much better than you would think.  You have to watch tight loops
    though.  BTW, is it true POSIX still does not have select()?

							Thad