It's really pretty simple:

Use TCP for things that aren't time-critical. Use UDP for everything else.

With TCP, you get a guarantee that the packet *will* be delivered, but there's no time guarantee. And the notorious resending algorithm can make this insanely long.

Unless you're writing a turn-based game, most things are time-critical, so you end up using UDP. Nearly all multiplayer games these days use UDP with home-grown guarantee mechanisms.

And never, ever, use DirectPlay.

Bob

[edited by - eeaiguy on April 3, 2002 8:03:59 AM]

quote:

---

Original post by eeaiguy
And never, ever, use DirectPlay.

---

Don''t say that without giving a reason....

quote:

---

Original post by Ironside
This is where your a little bit off bud True, the Client does need to send an ACK for every delta state packet it receives. But the server does not need to resend state packets that the client misses. Why? because every packet sent from the server represents the delta between the last ACK''ed client state and the current server state.

---

Ahhhh, I see.


...
UDP also scales far better than TCP does.

quote:

---

Original post by eeaiguy
And never, ever, use DirectPlay.

---

Why not use directplay? Please explain.

quote:

---

Original post by Ironside
This is where your a little bit off bud True, the Client does need to send an ACK for every delta state packet it receives. But the server does not need to resend state packets that the client misses. Why? because every packet sent from the server represents the delta between the last ACK''ed client state and the current server state.

---

if the ACK is lost what happens then?

quote:

---

Original post by Avater
if the ACK is lost what happens then?

---

It's not really a big deal, because the next packet the client receives from the server will bring it up to the current gamestate on the server. It will send a new ACK when it receives this packet. Eventually one of these ACKS will get delivered to the server and the server can flush out all previous delta gamestates it was storing with sequence numbers prior to that ack.

If in it's next iteration, however, the server has not recieved an ACK but also does not have any delta state information to send, it will just re-transmit the last packet until it recieves an ack, or there is a new delta packet to send.

If you go for long periods of time without an ACK.. say like in a situation where the client disconnected abruptly. Then you can monitor the size of the state cash associated with that connection, as it grows large... say were delta packets are larger then the MTU for your game (or the protocall) then you could mark the client as disconnected on the server, and clean up all residual state information.




[edited by - ironside on April 4, 2002 12:19:07 PM]

Alright - you can use DirectPlay if you''re also using TCP. That is, if your game doesn''t have any time-critical paths.

DirectPlay doesn''t give you guaranteed UDP, which is what most games need to implement.

So, you may ask, why not use DirectPlay for game matching?

DirectPlay game matching uses TCP, which has already been shown in this thread to cause game-killing delays. Trust me - even in a game lobby atmosphere (not even in the game proper), players will not take kindly to some of the timeouts you''ll get with DirectPlay.

Bob Scott

quote:

---

Original post by eeaiguy
DirectPlay doesn''t give you guaranteed UDP, which is what most games need to implement.

---

Hmmm...That''s not what I''ve heard...But I don''t know for a fact.

Do you mean directplay 8 eeaiquy?

Some quotes:

quote:

---

TCP/IP service provider
A service provider that uses Windows Sockets to communicate over the Internet or local area network (LAN), using the TCP/IP protocol. It uses User Datagram Protocol (UDP) packets for nonguaranteed messaging and TCP for guaranteed messaging. Using TCP/IP, a single computer can host multiple Microsoft® DirectPlay® sessions.

---

One of the flags for the send method:

quote:

---

DPNSEND_GUARANTEED
Send the message by a guaranteed method of delivery.

---

so as you can see it is easily to switch between UDP and TCP

How often should one resend the packets, using UDP? Do you resend all the packets you haven''t gotten ack''s for, each game loop?

A - Always
B - Be
C - Coding

quote:

---

How often should one resend the packets, using UDP? Do you resend all the packets you haven't gotten ack's for, each game loop?

---

You do not resend that packet. You include the data(delta gamestate) of that packet in the next packet.












[edited by - Avater on April 5, 2002 11:53:11 AM]