udp guaranteed messages algorithm
Author
So there''s lots of discussion about the pros and cons of UDP, but I''ve looked back several months to see if I can find any good links on how best to add a layer on top of UDP where some messages will be guaranteed to be receieved, and will be processed in order, and some will not. Obviously, I''m not going to have much trouble wrapping some functions for the non-guaranteed stuff. What I''m interested in is a tutorial maybe with some pseudocode for a flexible, scalable method of taking care of the rest. While it doesn''t need to be as efficient as possible, something that can elegantly handle dozens or maybe even a hundred or so remote clients is necessary. Have any of you guys come across anything useful?
This post might help. Might not.
It will at least give you some ideas.
http://www.gamedev.net/community/forums/topic.asp?topic_id=139920
I''ve been meaning to write a tutorial on this at some point, but only after I write an game/app that utilizes the code and I can see the real world performance of it.
Just bouncing packets back and forth over LAN its works fine, even with dropping packets from time to time itll recover, but LAN != the internet, so itll have to go thru its paces there first.
-=[ Megahertz ]=-
It will at least give you some ideas.
http://www.gamedev.net/community/forums/topic.asp?topic_id=139920
I''ve been meaning to write a tutorial on this at some point, but only after I write an game/app that utilizes the code and I can see the real world performance of it.
Just bouncing packets back and forth over LAN its works fine, even with dropping packets from time to time itll recover, but LAN != the internet, so itll have to go thru its paces there first.
-=[ Megahertz ]=-
Author
that''s sort of the right direction, but it''s pretty general and only applies directly to one program talking to one other; i''m still not comfortable with my thoughts on how this would be designed in a server situation
What difference does it make? No matter what sort of situation you''re talking about, its still just 2 computers who need to talk to each other reliably.
Maybe you could use two connections per client - one UDP and one TCP. Then if a hundred concurrent TCP connections proves problematic later, you can replace it with a reliable UDP transfer.
What is bad about tcp? I mean when you want a sure connect why try to create your own layer on udp while tpc exists?
quote:Original post by Pilatus
What is bad about tcp? I mean when you want a sure connect why try to create your own layer on udp while tpc exists?
Sometimes even tcp and udp don''t help and only raw ip packets can make it... =) TCP is not always useful for reliable data delivery because it is a stream-based protocol. And if you want packeted data you have to use UDP and build a user protocol on top of the UDP or. Besides, TCP header is 40 bytes minimum, and UDP is only 28. So if your packets are less than 10-20 bytes long it is better to use UDP to preserve traffic and bandwidth.
quote:Original post by markuskidd
i''m still not comfortable with my thoughts on how this would be designed in a server situation
Depends on what kind of app you''re designing. Post more info, and i''ll try to design a guaranteed UDP for you.
"I''ll be Bach!" (c) Johann Sebastian Schwarzenegger
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement