Jump to content
  • Advertisement

Archived

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

proper use of UDP

This topic is 5299 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!