proper use of UDP
Author
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?
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.
Author
Very Funny. If that was the answer I don''t think I would''ve asked this question. Does anyone have any real insight?
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.
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.
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.
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.
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.
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.
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.
Author
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.
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.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
