Archived

This topic is now archived and is closed to further replies.

wing_majin

proper use of UDP

Recommended Posts

Does anyone know how to implement the UDP protocol using winsock so that it''s reliable? TCP ensures that that data sent will be received (in the absence of sufficiently abnormal network occurances) yet UDP simply drops the datagrams if anything goes wrong right? It seems as though a UDP sender should wait for a conformation of the peer''s receival of its data before continuing. However the data has the chance of being lost either on the initial send to the recipient or on the way back to the original sender (the confirmation) so doesn''t this just create a situation of infinite checking and re-checking where it''s impossible to be sure one side received something? How can this be avoided and reliable (or at least more reliable) data exhange occur over UDP?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by wing_majin
Does anyone know how to implement the UDP protocol using winsock so that it''s reliable? TCP ensures that that data sent will be received (in the absence of sufficiently abnormal network occurances) yet UDP simply drops the datagrams if anything goes wrong right? It seems as though a UDP sender should wait for a conformation of the peer''s receival of its data before continuing. However the data has the chance of being lost either on the initial send to the recipient or on the way back to the original sender (the confirmation) so doesn''t this just create a situation of infinite checking and re-checking where it''s impossible to be sure one side received something? How can this be avoided and reliable (or at least more reliable) data exhange occur over UDP?


By using TCP.

Share this post


Link to post
Share on other sites
you can give each packet a unique sequential id (i.e. the first packet is 1, the second is 2, etc etc), and have the client relpy with an "i got packet #x" packet when it is received. if the server doesn''t get an acknowledgement for any certain packet after a specified amount of time, send it again.

this way, you get both the "guarenteed delivery", and can easily put the packets in order based on the ID.

that''s a simplified description, but you could find lots of info about this in the networking forum.

Share this post


Link to post
Share on other sites
I''m with the AP on this one, just use TCP. IMHO it''d be a waste of time to implement a reliable UDP protocol when TCP already exists.

quote:
Original post by wing_majin
It seems as though a UDP sender should wait for a conformation of the peer''s receival of its data before continuing.


That defeats the whole purpose of UDP. It would have to keep each packet saved until it got an acknowlegement from the peer, which is what TCP does.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
TCP, like UDP, is built on IP. TCP adds reliability and flow control to the protocol by having the sender resend a message that didn''t make it to its destination. If you are trying to add this feature to UDP, then its probably a good idea to just use TCP. However, if you want to create your own (most likely inferior) version of TCP, you can look at <a href="">RFC 793: TRANSMISSION CONTROL PROTOCOL</a> to find out how they did it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
TCP, like UDP, is built on IP. TCP adds reliability and flow control to the protocol by having the sender resend a message that didn''t make it to its destination. If you are trying to add this feature to UDP, then its probably a good idea to just use TCP. However, if you want to create your own (most likely inferior) version of TCP, you can look at <a href="http://www.ibiblio.org/pub/docs/rfc/rfc793.txt">RFC 793: TRANSMISSION CONTROL PROTOCOL</a> to find out how they did it.

Share this post


Link to post
Share on other sites
Sorry guys I forgot there is a networking forum here, but I''ve made networking posts here before so I guess I didn''t think to look.
I''m not really looking to re-implement TCP. I know that''s rediculous. Also, I''m not trying to pose any argument for using UDP over TCP, I know that''s also rediculous. I''ve used TCP and implemented everything I want to do and now I''m just trying to make UDP work as sort of a "backup" protocol for reasons I don''t really have to get into. I''d respond to krez''s post but I''ll take it to the networking forum. Thanks guys.

Share this post


Link to post
Share on other sites
I would suggest u check out 3rd party solutions (some free) such as HawkNL or RakNet. From my knowledge, HawkNL would support reliable UDP in its nxt beta version, NL2.0.

However if for some obscure reasons that u would wan to implement reliable UDP urself, then u would have to look at the following:
- Can u ensure ur implementation works better than TCP/IP? If u cannot, u might as well stick to TCP.
- To guarantee ordered and reliable transmission, TCP''s byte count overhead per packet is abt 50+ bytes. Is this too painful for u? From wat i know, it is painful for some games that need to send many many packets (<10bytes) in quick-fire sequence, and the overhead for each packets stacks up badly, thats why they choose UDP over TCP.
- If u can live wif the overhead, why not implement a packeted-TCP scheme instead. U get order, reliability and packet based communication, best of both worlds.
- What is ur applications needs??? I do not believe in the myth of a general purpose networking library. This is the same UNICON of general graphics library. Both DOES NOT EXIST. If a networking core is be to written, there are millions of ways to optimize it for different applications such as games or webservers. U need to think deep abt this. General networking library ALWAYS EQUATES TO Unperforming/unoptimized networking library. Same goes for graphics rendering libraries.


- Hun Yen Kwoon

Share this post


Link to post
Share on other sites
Use TCP for connections that need all the data, eg. when a client initially connects to a game server and needs to send username/password and receive game information, number of games, players playing etc. Then the client needs to create an account or pick a player type, etc. It can also be used for data that isn''t time-critical, for example if you allow chatting in your game the chat messages can go over the tcp connection.

Use UDP for data that can be lost, eg. if your game informs the client of the NPC''s or other game state around the player 4 times per second, the client doesn''t need to receive that, it can just wait for the next update.

Your client can open both an UDP and TCP connection to the server, and use them both for different types of messages.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The problem with TCP is that it only provides certain type of reliable transfer: Everything must be transferred reliably. But in a game, only *the most recent* info must be delivered reliably. Suppose player''s energy drops to 50. Server tries to send this as a packet to player. The packet gets lost. Then the server sends it again until the player acknowledges that it has been received. But then, take a scenario where the energy first drops to 50, then the packet is sent and lost, and meanwhile the energy has dropped to 30. TCP would still send *both* energies 50 & 30, even though only 30 is meaningful for the client. So while the transfer must be reliable, it doesn''t need to be reliable in the same sense as TCP is.

And if some data is reliable (even in TCP sense) and some is unreliable, sending them all using the same UDP allows you to merge packets better, resulting in less traffic.

Share this post


Link to post
Share on other sites