[e2e] Protocols for tightly synchronised multicast?

[Jonathan M. Smith]

This is actually a very interesting problem in another context. I talked to 
a company in the early 90s
that was in the fixed income securities data distribution business. There 
were issues of market
fairness if the data didn't get to all the players at the same time, since 
a relative delay offered
a trading disadvantage to those getting data "late". I have no idea whether 
or how they solved the
problem, but there were certainly large enough financial incentives......

                                                                                         -JMS


At 04:36 PM 8/14/2001 -0600, Hilarie Orman wrote:
>My challenge problem for networks: nationally distributed musicians
>playing in concert.
>
>Hilarie
>
> >>> Simon Spero <ses at tipper.oit.unc.edu> 08/14/01 03:49PM >>>
>Does anyone have any suggestions for a multicast transport capable of
>delivering packets to applications on multiple clients synchronised to
>within a few milliseconds?
>
>The idea is to try and build a distributed virtual sound-system; a single
>source would send a single stream of audio data; this data would be
>recieved by multiple clients, with the data sent to each clients speakers
>with a fixed delay relative to some global clock (the delay would be based
>on the client's physical distance from the center of the virtual system,
>
>I can see how one could roll ones own using timestamps and NTP, but it'd
>be nice if I could use an existing transport
>
>Thanks for any suggestions
>
>Simon