unknown
1970-01-01 00:00:00 UTC
1. increasing serial numbers on OSC messages (between two particular hosts)
2. receivers periodically announce the last serial number they saw to the
sender (Extended Highest Serial Number Received: EHSNR).
3. the sender adds a "recovery journal" with every message sent (from EHSNR
to present)
In RTP midi, the journal only contains recovery messages when a lost of
message would produce an "indefinite" artifacts (ever lasting note, wrong
volume) as opposed to a transient artifact (missing note). With the general
aspect of what will be transmitted with oscit, I think it is hard to filter
out any event and thus the recovery journal should contain all messages.
Bandwidth can be reduced if the client notifies the server more often with
it's EHSNR.
This change would mean that we send bundles instead of raw messages and
without much overhead, we could also add the timestamp (see latest CNMAT
paper).
This change would add an important overhead on the sender side (keeping a
journal for every connected device) but I think it could work even for the
embedded case as long as the journal does not grow too much.
wifi) but I think you have a good point here: we need to solve the packet
recovery/lost issue right at the start because it will be harder to add when
we encounter less stable environments.
and the race condition (fight for value) should be made explicit with proper
visual feedback (I am still holding the slider with the mouse but it moves).
We must not forget that changing a control can also happen from some
internal object sending messages and that the changes can be continuous,
therefore locking the resource forever.
I have experimented changing control values in Rubyk with multiple
interfaces (Mimas for iPhone and desktop Mimas) and it works fine without
locking.
Still many thanks for the constructive pointers. I will re-read the paper
from CNMAT on timestamping issues and update the wiki with these new ideas
(timestamp, serial number, recovery journal) unless someone has strong
issues with these developments.
Cheers,
Gaspard
--0016367b6e8c0d24c6048e533dea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Ross,<div><br></div><div>(replies below)</div><div><br><div class="gmail_quote">On Sat, Aug 21, 2010 at 8:41 AM, Ross Bencina <span dir="ltr"><<a href="mailto:rossb-***@audiomulch.com" target="_blank">rossb-***@audiomulch.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#ffffff">
<div><font face="Arial" size="2">Hi Gaspard</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">First a couple of points:</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">1. Real-time synchronisation of distributed
state is a problem that has been widely studied. Not least in the
VR/simulations/gaming sphere and also in the CSCW community. A number of
solutions have been proposed and we can run through some of them if you like.
There are similar issues addressed in real-time transport of multimedia data
(John Lazzaro's RTP MIDI packetisation and Nack-Oriented Reliable Multicast are
two examples). TUIO (a widely used OSC-based protocol) draws on ideas from
Lazzaro's RTP MIDI packetisation for example -- it has been used in distributed
applications (such as the distributed reacTable at ICMC 2005) and worked well
between Barcelona and Linz, in spite of packet loss.</font></div></div></blockquote><div><br></div><div>Thanks for the pointers. I read the part concerning packet recovery in RTP midi and added the links on the xdif wiki on the "set/get" page.
2. receivers periodically announce the last serial number they saw to the
sender (Extended Highest Serial Number Received: EHSNR).
3. the sender adds a "recovery journal" with every message sent (from EHSNR
to present)
In RTP midi, the journal only contains recovery messages when a lost of
message would produce an "indefinite" artifacts (ever lasting note, wrong
volume) as opposed to a transient artifact (missing note). With the general
aspect of what will be transmitted with oscit, I think it is hard to filter
out any event and thus the recovery journal should contain all messages.
Bandwidth can be reduced if the client notifies the server more often with
it's EHSNR.
This change would mean that we send bundles instead of raw messages and
without much overhead, we could also add the timestamp (see latest CNMAT
paper).
This change would add an important overhead on the sender side (keeping a
journal for every connected device) but I think it could work even for the
embedded case as long as the journal does not grow too much.
Please let me know what you think. If you are basing this whole project on
the assumption that UDP is a reliable transport (or that the protocol you're
designing requires a reliable transport) then I think stakeholders need to
understand that -- it's a pretty fundamental assumption and one that I would
prefer not to make.
My only assumptions was that we can solve simple setups first (local LAN, nothe assumption that UDP is a reliable transport (or that the protocol you're
designing requires a reliable transport) then I think stakeholders need to
understand that -- it's a pretty fundamental assumption and one that I would
prefer not to make.
wifi) but I think you have a good point here: we need to solve the packet
recovery/lost issue right at the start because it will be harder to add when
we encounter less stable environments.
Finally, you also raised the potential of multiple clients that can send
/set messages on objects but you havn't specified any method for resolving
1. Can two users be manipulating the slider at once? (and hence fight
against each other/create race conditions) or is there some kind of lock
negotiation which grants one user exclusive access to changing values while
the slider is down? This would require some kind of locking (perhaps
distributed locking) protocol so that only one writer has access to a value
at once.
Yes, this is important: two users can move the same slider at the same time/set messages on objects but you havn't specified any method for resolving
1. Can two users be manipulating the slider at once? (and hence fight
against each other/create race conditions) or is there some kind of lock
negotiation which grants one user exclusive access to changing values while
the slider is down? This would require some kind of locking (perhaps
distributed locking) protocol so that only one writer has access to a value
at once.
and the race condition (fight for value) should be made explicit with proper
visual feedback (I am still holding the slider with the mouse but it moves).
We must not forget that changing a control can also happen from some
internal object sending messages and that the changes can be continuous,
therefore locking the resource forever.
I have experimented changing control values in Rubyk with multiple
interfaces (Mimas for iPhone and desktop Mimas) and it works fine without
locking.
2. With regard to broadcast updates for value changes: Remember, UDP
packets can be reordered by the network, so it's possible for clients (say
user interface sliders) to recieve update messages out of order, and hence
different sliders stabilise with different values. One way to resolve this
is to use value serial numbers (every value also has an integer serial
number) that way clients can discard all but the most recent (highest
numbered) update.
Using a solution similar to RTP midi would also help with this issue.packets can be reordered by the network, so it's possible for clients (say
user interface sliders) to recieve update messages out of order, and hence
different sliders stabilise with different values. One way to resolve this
is to use value serial numbers (every value also has an integer serial
number) that way clients can discard all but the most recent (highest
numbered) update.
Still many thanks for the constructive pointers. I will re-read the paper
from CNMAT on timestamping issues and update the wiki with these new ideas
(timestamp, serial number, recovery journal) unless someone has strong
issues with these developments.
Cheers,
Gaspard
--0016367b6e8c0d24c6048e533dea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Ross,<div><br></div><div>(replies below)</div><div><br><div class="gmail_quote">On Sat, Aug 21, 2010 at 8:41 AM, Ross Bencina <span dir="ltr"><<a href="mailto:rossb-***@audiomulch.com" target="_blank">rossb-***@audiomulch.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#ffffff">
<div><font face="Arial" size="2">Hi Gaspard</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">First a couple of points:</font></div>
<div><font face="Arial" size="2"></font> </div>
<div><font face="Arial" size="2">1. Real-time synchronisation of distributed
state is a problem that has been widely studied. Not least in the
VR/simulations/gaming sphere and also in the CSCW community. A number of
solutions have been proposed and we can run through some of them if you like.
There are similar issues addressed in real-time transport of multimedia data
(John Lazzaro's RTP MIDI packetisation and Nack-Oriented Reliable Multicast are
two examples). TUIO (a widely used OSC-based protocol) draws on ideas from
Lazzaro's RTP MIDI packetisation for example -- it has been used in distributed
applications (such as the distributed reacTable at ICMC 2005) and worked well
between Barcelona and Linz, in spite of packet loss.</font></div></div></blockquote><div><br></div><div>Thanks for the pointers. I read the part concerning packet recovery in RTP midi and added the links on the xdif wiki on the "set/get" page.