quote:

---

Imho, the strength of UDP is not that it's faster (it isn't)

---

Actually, speed IS the main reason we use udp in real-time networking. In many cases, udp is faster and much more responsive than TCP. Notice I didn't say 'better' than TCP. Each protocol has its uses - learn them for yourself and don't take the word of others. Dropped packets with UDP are expected. With TCP however, dropped packets can be a latency nightmare.

quote:

---

Packet acking is not a big issue.

---

Actually, it is. The delayed acks algorithm potentially introduces a huge per-packet latency (~200 ms in most implementations) that cannot be disabled.

A very informative google string for the ill-informed:
"delayed ack nagle karn tcp udp"

To the original poster: The book you bought is actually the first book I've seen that presents anything close to a usable networking framework for real-time games (it's still lacking quite a bit, but it presents the right concepts).

quote:

---

you can check the specs for RFC908 (it's old, but well described so you adapt some ideas from it)

---

It (rfc 908 - "RDP") is in wide use today actually. RDP is used by RealNetworks streaming servers/clients (although RN has a slightly modified version, they DO use standard RDP for QuickTime video support). Also, I believe VoIP uses RDP as well. As cbenoi said, adapt concepts for your usage, as it isn't particularly suited for use in gaming.

[edited by - fingh on January 21, 2004 3:04:37 PM]

fingh, it''s not the acking itself that''s an issue, it''s the particular algothithm that TCP uses that you are objecting to.

*any* reliable protocol has to have acking. If you use an appropriate sized window and piggyback acks on other packets as much as possible then the overhead is pretty much insignificant unless net conditions are so bad that you''re not going to be able to communicate effectively no matter what you do.

TCP uses sliding window, cumulative ACKs etc. to keep the pipe full, from that perspectiveit is as good as any UDP based reliable delivery. However TCP uses flow control( a packet loss halves your transmit rate) which you may not want(we dont care about congestion do we?)

Someone brought up a VERY good point, relative versus absolute values (for postion) what would you do? relative? or absolute? or even some relatives and then an absolute every say 10 packets? i dunno maybe im on the wrong track alltogether

Relative and Absolute values are somewhat useless (also known as Delta)

I mean, you wouldn''t for example just send how much a player moves unless you know that amount can be stored in a smaller amount of space. For example, if you know the maxumim something can move is +255, maybe use a char instead of sending the entire x posiion (say it''s an int).

But if you are working with floats, most likely just send the position updates as one. This keeps from relying heavily on packet order alot of games can play and just discard packets that are received in incorrect order (UDP only).

If you used delta, you could be relying on packet order, which would require you to wait for the right packet.

As I''ve just big-upped it in another thread, I thought I''d mention that RakNet is a very easy to deploy network layer that encapsulates winsock UDP with a reliability layer, and is a piece of p--- to deploy.

See http://www.rakkarsoft.com.

www.coldcity.com
code, pics, life

quote:

---

Original post by psykr
TCP''s acknowledgement packet takes a while; it has to send a packet, then decide that enough time has passed without an acknowledgement, then send the same packet again. It can''t send the next packet until it has recieved the client''s confirmation.

---

TCP/IP have some optimisation, it suppose that the packet ack will arrive and send next one without waiting. If the ack is never received the packet is re-send.