Jim Starkey wrote:

> Lester Caine wrote:
>> Multicast streaming would not be a lot of use if you got the punch line
>> before the joke. Given that a lot of big money companies are now looking
>> to use broadband to provide pay viewing I don't see any problem with
>> sequential multicast. ( Roman provided the fine detail )
>
> Could you explain how arrival order from x clients on a LAN broadcasting
> independently to y servers on a LAN could possibly have deterministic
> receive ordering on all servers? Probability is not your friend -- one
> out of order SQL statement and the game is up.

Multicast only has one source, but multiple streams can be synced to
maintain their time relation as with multi-lingual feeds with a single
video track. You are right that multiple client streams are the problem
but surely the question is rather "How do we maintain time sync across
the 'cluster'.

Personally I'm just looking for a stable core of masters across multiple
sites which should simplify the problem? Rather than an unlimited array
of machines. I've used multicast on my systems for years, if the first
master does not respond then the second master takes over, and I could
not see any way to remove the multicast element, but there is a single
master running at any time, the backup machines just mirror the master.
Pull the power on the master and everything keeps running as a backup
takes over. So even if we loose a whole signal box, the rest of the
network just carries on and catches up later when the missing element is
restored. ( Actually the system can also replace the signalling system
by tracking movement via each station server, but that is not 'approved'
from a safety point of view )

Somewhere we need a stable master clock which can be used to timestamp
activity and order processing based on that master clock. I'm not saying
clustering is the answer to the problems, but I've not kicked it into
touch just yet. I think 'distributed' processing is probably the more
stable solution. A set of servers handle sections of the commits, and
replicate the answers, but an 'order' to buy stock only becomes a
problem when you have more orders than stock. A train can't be in two
places at once so my problems are relatively easy and time well
controlled. If everybody is trying to buy one product, the usual
practice is to share the stock around suppliers and one may sell out
while others still have stock. This is the time that we need to then
start sharing transactions so that we do not have complaints that X
bought something after Y was told it was out of stock.

As you have said Jim, we need to define the problem. Simply saying it
will not work is not the helping layout a plan as to what can and can't
be made practical?

--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php