DPlay gives the option on whether to insist that a packet has guaranteed delivery. Although this is ideally what is wanted, apparently it''s a big performance hit. Can you tell me how feasible it is to use this method, what kind of hit it causes and whether I''m going to need it in my simple racing game (only 4-6 keys per player but as many players in a game as possible ie >20 hopefully >50) Thanks

Assuming its a fast racing game, you''ll be sending updates all the time, so guaranteed packets are a definite no-no as by the time an update gets to the server and to all the players it will be out of date with a new packet running quickly behind it. Basically for fast paced games spew out unreliable packets like theres no tomorrow

To clarify, reliable delivery (both TCP and DPlay) use whats called ''Sliding Window''. It basically comes down to the network will only send up to a certain number of packets until it receives an acknowledgement that packets were received. ie.
Sliding window of 7:
Server send packets 1-7 then waits
Client receives 1-5 then sends an acknowledgement packet to say "The last packet i received was packet 5" then the client receives 6-7
Server receives the clients acknowledgement and slides it''s window up to packet 6, now it has another 5 slots in it''s window so it sends 8-12. etc.
So the greater the ping time/latency between server/client, the slower tcp (or DPlay) will seem to go, as it has to wait for the acknowledgement to continue sending data. If you are on a very very fast connection (LAN) it is possible you can receive acknowledgements fast enough that you are never waiting for an acknowledgement and the data is fast and constant....but that don''t work over the internet
There are also other issues like timeouts for retransmitting packets (if the server doesn''t receive an acknowledgement within a certain time it will resend the window again, added time = timeout + waiting for another acknowledgement) and the slow start algorithm for heavy network loads.