On Mon, Jun 23, 2008 at 12:47:29PM +1000, Ken Foskey wrote:
> I have a need for a server to send out messages to every client on the
> local network. I was thinking of UDP however multicast might be a
> better fit http://en.wikipedia.org/wiki/Multicast.
Low data volumes means multicast isn't going to be such a big win.
> I have read multicast and I cannot work out if it is like UDP (just
> packets) or like IP (sessions and retransmissions at network level).
I'm pretty sure it's an IP-level thing. Obviously you can't run a protocol
over the top that assumes a point-to-point connection (like TCP), since
multiple remotes all trying to ack packets at once wouldn't be so hot...
> My system is one person scoring sport at bottom feeding multiple
> machines on a small network. They have to keep in sync and have ability
> to request catchup transmissions if something is missing. Data volumes
> would not be huge.
With those requirements, multicast *really* isn't for you. The only problem
multicast solves is how to get a stream of packets from point A to points
(B..n) without having to send n copies of it from A.
You really want something a bit more reliable for your protocol. A pubsub
mechanism could work to do the updates, but the resync requirement is still
unsolved. The short answer is that data replication is a hard problem.
<grin>
Assuming that there's a "state" that you want all machines to be in, you
could identify each state with a unique number, and send out "state updates"
that say "from state X, change <foo> to be in state Y". Then you send out
those updates to each client. Each client keeps it's own state data and the
ID of that state. If it sees a "from state X" message and it's on state Z,
then it goes "bugger, I probably missed one" and asks the server for a
complete state dump, which has all the data and the ID associated with it.
Defining what counts as state and how you describe your transitions is
completely and utterly app-specific, of course.
> There are heaps of unanswered questions like how do you allocate the
> address of the multicast?
Pick one, I believe, is the usual methodology. For "public" streams you
need to do some extra jiggery-pokery to "register" one, but if you were
doing multicast-in-the-LAN I don't think that's a real problem.
- Matt
--
"Ah, the beauty of OSS. Hundreds of volunteers worldwide volunteering their
time inventing and implementing new, exciting ways for software to suck."
-- Toni Lassila, in the Monastery
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
