[OT] Handling multiple UDP clients through NAT
bryan.sant at gmail.com
Wed Feb 7 15:31:15 MST 2007
On 2/7/07, Steve <smorrey at gmail.com> 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.
"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 :-).
More information about the PLUG