On Tue, 2005-04-10 at 00:12 +0200, fons adriaensen wrote:
> Hi all,
>
> working on the strict MVC-fication of Aeolus (a precondition
> for its OSC-fication), I'm again confronted with a problem
> that has been discussed a number of times on this list.
>
> It has been stated that the model should send updates to
> all clients except the one that originated a parameter change.
> While this will work if all communication is synchronous,
> it will go wrong easily when there are delays, e.g. over
> a network.
>
> Imagine an M and to CV clients, A and B. There are two
> transmission paths: A -> M -> B, and B- > M -> A. If the
> two ever intersect in time, the originator of the final
> value used by M will end up displaying the other one.
>
> So the only solution seems to echo parameter updates to
> all clients, including the one that requested them. In that
> way (and assuming messages remain in order), all clients
> will have the value used by M. If messages do not remain
> in order, the solution is to have a serial number set by
> M on each update and included in all messages. Finally,
> if the communication is unreliable as well, M should
> broadcast periodic updates of its state, or at least
> of those parts that have recently changed.
After much fiddling around with ugly schemes to not send replies to
certain clients in Om, I just echoed back /everything/ to all registered
clients, and left it up to the client to deal with it. The comm layer
is much simpler and understandable because of it.
> Of course this may create some problems, e.g. when a GUI
> client's slider is being dragged, and it receives 'old'
> update values while this is happening. The solution seems
> to be simple: while dragging, ignore all updates but keep
> the most recent one. Execute this one when the slider is
> released. It may be a good idea to extend the 'ignore state'
> by a small time (e.g. 0.1 s) after release.
This is what I do in my gtk client. I need to do the small time delay
thing still though, as there is a problem with dragging and releasing a
slider very quickly (it jumps a bit afterwards). I'm not sure this is
the best solution, but it's worked well enough so far. Generally when
given the choice I'll choose complexity in the client over complexity in
the engine any day. YMMV.
It's not a very fun problem by any means.. I guess sending everything to
everyone is less efficient in terms of network load, but it's simpler at
least.
-DR-
Received on Tue Oct 4 04:15:06 2005
This archive was generated by hypermail 2.1.8 : Tue Oct 04 2005 - 04:15:06 EEST