|
Post by Leif Bloomquist on May 8, 2006 14:34:45 GMT -5
|
|
|
Post by Leif Bloomquist on May 8, 2006 14:35:50 GMT -5
I didn't explicitly say it on the charts, but it's assumed we're using UDP.
|
|
|
Post by Leif Bloomquist on Nov 5, 2006 20:57:04 GMT -5
I'd like to make a slight change/clarification here. Where it says "send health packet" - I think my simplistic protocol might get confused if both sides send a packet at once. Both will need to do so, because either player could get damaged.
For simplicity, and to enforce the "one packet in flight at one time" assumption, I think the current player should send the packet first, followed by the target. Sound reasonable?
|
|
|
Post by Leif Bloomquist on Nov 9, 2006 9:58:12 GMT -5
I just realized I've overlooked something major....consider this scenario:
-Player 1 (say) sends an announce packet with received flag = 0. -Player 2 receives Player 1's packet -Player 2 sends an announce packet with received flag = 1. -Player 1 receives Player 2's packet, sees that the flag is 1, and then exits to the main game.
Player 2 will never see a packet that has the flag=1, so it will sit and wait indefinitely, because Player 1 is not sending packets anymore.
And even if it did send a few more, it still might fail because UDP packets might get lost in the network. So I'll need to revamp this, possibly following the TCP SYN/ACK model. Or can anyone suggest an easier approach?
|
|
|
Post by Leif Bloomquist on Nov 14, 2006 10:12:24 GMT -5
OK, I've revamped the entire way the initial sync-up works. In fact, it mimics the TCP three-step handshake almost verbatim:
0. Player 2 sits and listens on the UDP port. 1. Player 1 sends an Announce packet and waits for an ACK. 2. Player 2 sends an ACK packet followed by its own Announce Packet. 3. Player 1 ACKs Player 2's Announce packet.
While I really wanted a true peer-to-peer system, I think the TCP designers knew what they were doing. It's one extra keystroke when starting the game, not too bad I guess.
|
|