On 2/7/07, Steve <[EMAIL PROTECTED]> wrote:
Ok fine, it's not fedex, it's the pony express :D
And the semi-realtime aspect as well as the ability to push MOST of
the work onto the client, is the reason for the design decisions.
The fact that the data arrives, arrives out of order, or arrives not
at all is irrelevant. The design copes with that by sending complete
present state information about itself, rather than informational
deltas( we send x=5 rather than (x+=2)). And then we interpolate
between last packet and current packet, on the client. We timestamp
all information and discard packets that arrive out of order by
looking at it's timestamp first, if it's older than the last packet,
it's just tossed anyways.
Hopefully that makes sense, I can't possibly be the first person to go
this route, but I'm not seeing anyone doing anything similar or who
has done anything similar, so that kind of worries me.
Regards,
"I see", said the blind man, as he picked up his hammer and saw. I get it.
If a user is around other users -- or activity of some kind -- that
user is effectively subscribed to, and will receive messages about,
the area. Complete messages (not deltas) are transmitted to all
clients in a given virtual area to notify them of activity within
their proximity. If a packet is lost, it doesn't really matter
because newer/more relevant data will be coming shortly. If something
is time sensitive, you have time stamps to prevent back-to-the-future
weirdness (probably older messages that come after newer messages will
just be discarded).
TCP wouldn't be the worst thing in the world, but most of the
qualities of TCP are actually unwanted in your app. Waiting for
retransmits of lost packets is a waste of time, because better data is
coming. Windowing/throttling isn't needed because the messages are
small and transmission is spares. Session management isn't needed
because the client maintains its own state and processes messages
relative to itself.
Using TCP would work fine, but it is more chatty and requires slightly
more kernel time to process packets.
This sounds like a great job for UDP. I'm on your side now :-).
-Bryan
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
