🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
networking design idea
Author
hey, this is my idea for doing the networking aspect of my game. i''m gonna use winsock.
basically, u connect to the server using 2 sockets. 1 uses the tcp/ip protocol and the other uses the UDP protocol. i will send the "important" information over the slow, but guaranteed tcp/ip and the notsoimportant info over the udp socket. i.e: player logins/logouts, shots fired, chatting, is done over tcp/ip. (x,y) and directional info is send over UDP b/c it is just going to be send over and over and over, so it doesn''t matter if u lose some of it here and there.
does this sound like a good idea?
also, UDP sockets are connectionless. can u connect them and use the send() function, or do u always have to do the sendto(), recvfrom() functions?
any suggestions/hints whatever would be appreciated
All you have to use sendto - you always need to tell it who to send the packet to and never need to connect.
How many players do you want to have logged onto the same server? It may overwhelm it to have 1000''s of tcp ports open at the same time. With UDP, only one server port is open, not one per connection/player.
Also, the TCP protocol always tries to use all the bandwidth (if there''s enough data to send) so it''ll always drop a packets as it tries to go faster than the connection can handle - this is a bigger problem with streaming media applications than games.
UDP traffic gets priority on the internet, which is another good reason to use it on MMOGs for everything.
You would need to implement your own mechanism for delivery notification if you use solely UDP, i.e. guarantee the packet was received.
[moved from Game Programming]
How many players do you want to have logged onto the same server? It may overwhelm it to have 1000''s of tcp ports open at the same time. With UDP, only one server port is open, not one per connection/player.
Also, the TCP protocol always tries to use all the bandwidth (if there''s enough data to send) so it''ll always drop a packets as it tries to go faster than the connection can handle - this is a bigger problem with streaming media applications than games.
UDP traffic gets priority on the internet, which is another good reason to use it on MMOGs for everything.
You would need to implement your own mechanism for delivery notification if you use solely UDP, i.e. guarantee the packet was received.
[moved from Game Programming]
Author
do u know of any places that have tutorials on how to do delivery notification? that sounds like it would be a pain to do
>> UDP traffic gets priority on the internet >>
Do you have any references to back this up? I have seen debates about which, if any, protocol gets priority on the internet many times, but I have yet to see any solid info backing either side.
Henry
Do you have any references to back this up? I have seen debates about which, if any, protocol gets priority on the internet many times, but I have yet to see any solid info backing either side.
Henry
Once your networking traffic is on the net, it doesn''t matter if it''s UDP or TCP or whatever. A router only sees IP packets, it''s only once it reaches the destination computer that the IP packet is dismatled and the computer works out if it''s a TCP or UDP packet. TCP and UDP are one layer above what the "outside world" sees of your packet (the outside world being everything but the two computers doing the communication), so clearly, there''s no way that one or the other can be given "priority".
Also, if you use connect() on a UDP socket, you don''t need to use sendto() or recvfrom(), you can just use send() and recv() and it''ll use the destination you set up in the connect() call.
Finally, I don''t think it''s a good idea to use two sockets for your communication. It''s possible, just not very efficient. A more efficient way would be to use UDP for everything and just create your own "gauranteed" protocol. It''s not that difficult, and any networking text will show you how. Basically, it''s just a matter of resending packets until you get an ACK from the other side. The other side will send an ACK for every packet it receives (even duplicates) but only uses the first duplicate (obviously). You detect duplicates using a simple counter, name each packet 0, 1, 2, etc.
codeka.com - Just click it.
Also, if you use connect() on a UDP socket, you don''t need to use sendto() or recvfrom(), you can just use send() and recv() and it''ll use the destination you set up in the connect() call.
Finally, I don''t think it''s a good idea to use two sockets for your communication. It''s possible, just not very efficient. A more efficient way would be to use UDP for everything and just create your own "gauranteed" protocol. It''s not that difficult, and any networking text will show you how. Basically, it''s just a matter of resending packets until you get an ACK from the other side. The other side will send an ACK for every packet it receives (even duplicates) but only uses the first duplicate (obviously). You detect duplicates using a simple counter, name each packet 0, 1, 2, etc.
codeka.com - Just click it.
IP does have a priority field in the header. However, its setting
a) is independent from the upper layer protocols - it doesn''t matter whether it''s TCP or UDP and
b) is often ignored by routers
cu,
Prefect
One line of sourcecode says more than a thousand words.
a) is independent from the upper layer protocols - it doesn''t matter whether it''s TCP or UDP and
b) is often ignored by routers
cu,
Prefect
One line of sourcecode says more than a thousand words.
I read that in a MSDN article about the Windows Streaming Media server and SDK. Now that I think about it they didn't give any specifics either, and like Prefect say, it's probably ignored by most routers.
Perhaps they meant UDP _can be given priority over TCP traffic for LAN/WAN/MAN networks.
Here it is
Data Delivery: "As a bonus, because of the back-off policies implicit in the TCP protocol, UDP traffic gets higher priority than the TCP traffic on the Internet"
If you think about it, it does make sense. TCP is guaranteed to drop packets, so dropping a UDP packet is a bigger deal.
...
Well, that's why there's DirectPlay
Edited by - Magmai Kai Holmlor on October 14, 2001 6:20:37 PM
Perhaps they meant UDP _can be given priority over TCP traffic for LAN/WAN/MAN networks.
Here it is
Data Delivery: "As a bonus, because of the back-off policies implicit in the TCP protocol, UDP traffic gets higher priority than the TCP traffic on the Internet"
If you think about it, it does make sense. TCP is guaranteed to drop packets, so dropping a UDP packet is a bigger deal.
...
quote:
do u know of any places that have tutorials on how to do delivery notification? that sounds like it would be a pain to do
Well, that's why there's DirectPlay
Edited by - Magmai Kai Holmlor on October 14, 2001 6:20:37 PM
No, the reason using UDP for a streaming media application is because it''s not all that important if you drop a packet - you''ll just miss a frame (or even just part of one) which is OK since it''s running at 30 FPS anyway.
The reason TCP is slower than UDP is that protocol requires the receiver to send ACK packets back to the server for every packet it receives - that''s not the case with UDP. You just send a packet and if it reaches the receiver, then that''s good, if it doesn''t, then too bad.
There''s nothing special about TCP, out "on the net", a TCP packet looks exactly like a UDP packet (to the routers at least), and if a TCP packet is lost, then the sender will have to send it again. Plus, I doubt there''s a router out there that takes any notice of the priority flag in the IP header. If you look at the IPv6 standard, they''ve dropped the priority field for just that reason.
codeka.com - Just click it.
The reason TCP is slower than UDP is that protocol requires the receiver to send ACK packets back to the server for every packet it receives - that''s not the case with UDP. You just send a packet and if it reaches the receiver, then that''s good, if it doesn''t, then too bad.
There''s nothing special about TCP, out "on the net", a TCP packet looks exactly like a UDP packet (to the routers at least), and if a TCP packet is lost, then the sender will have to send it again. Plus, I doubt there''s a router out there that takes any notice of the priority flag in the IP header. If you look at the IPv6 standard, they''ve dropped the priority field for just that reason.
codeka.com - Just click it.
There's a 8 bit protocol field in the IP header that indicate what kind of packet it is. UDP, TCP, ICMP, etc... rfc760 and here's the list
Every router knows exactly what kind of packet it's dealing with (unless someone's purposefully messing with the IP header)
Precisely the reason why dropping a UDP packet is a bigger deal than dropping a tcp packet. If you drop a tcp packet, it'll be resent. If you drop a UDP packet, it'll never arrive. TCP uses as much bandwidth as it can. If UDP (and in fact all other protocols) were not given priority over TCP, a loaded router would drop non-TCP packets like mad.
Now, I don't know how internet routes are setup, but based on everything I've read I think UDP needs to have priority over TCP.
Maybe there's something about this on www.ietf.org
Edited by - Magmai Kai Holmlor on November 3, 2001 6:04:06 PM
Every router knows exactly what kind of packet it's dealing with (unless someone's purposefully messing with the IP header)
quote:
The reason TCP is slower than UDP is that protocol requires the receiver to send ACK packets back to the server for every packet it receives - that's not the case with UDP. You just send a packet and if it reaches the receiver, then that's good, if it doesn't, then too bad.
Precisely the reason why dropping a UDP packet is a bigger deal than dropping a tcp packet. If you drop a tcp packet, it'll be resent. If you drop a UDP packet, it'll never arrive. TCP uses as much bandwidth as it can. If UDP (and in fact all other protocols) were not given priority over TCP, a loaded router would drop non-TCP packets like mad.
Now, I don't know how internet routes are setup, but based on everything I've read I think UDP needs to have priority over TCP.
Maybe there's something about this on www.ietf.org
Edited by - Magmai Kai Holmlor on November 3, 2001 6:04:06 PM
I worked for an ISP. There is no "out of the box" configuration for the devices powering the internet to provide UDP priority.
However, there is a current push towards QoS, or Quality of Service. Since most of the QoS pushes are for streaming media, IP Telephony and such, there usually is higher priority given to UDP packets vs TCP/IP. But, I wouldn''t count on it to make your design faster. It really is dependent upon the ISP, their customer base, and their business goals, not on any standard. Also, rarely would an ISP say, "All UDP packets get priority." Reality is that only certain UDP port numbers and sometimes source/destination addresses will be set up on the network equipment for higher priority.
Also, please note that you don''t need a seperate port for each client that connects. Often, people will "hand off" the new connection to a new port to keep the incoming connection queue length down and because their code is more effective that way, but it doesn''t have to be done that way either. You can get the Source IP address and Port from the incoming connection and decide Who sent What from that information, effectively serving many clients from different IPs (and maybe different ports) but to the same server IP and Port. Depends on your design and what you think is best for your application.
R
However, there is a current push towards QoS, or Quality of Service. Since most of the QoS pushes are for streaming media, IP Telephony and such, there usually is higher priority given to UDP packets vs TCP/IP. But, I wouldn''t count on it to make your design faster. It really is dependent upon the ISP, their customer base, and their business goals, not on any standard. Also, rarely would an ISP say, "All UDP packets get priority." Reality is that only certain UDP port numbers and sometimes source/destination addresses will be set up on the network equipment for higher priority.
Also, please note that you don''t need a seperate port for each client that connects. Often, people will "hand off" the new connection to a new port to keep the incoming connection queue length down and because their code is more effective that way, but it doesn''t have to be done that way either. You can get the Source IP address and Port from the incoming connection and decide Who sent What from that information, effectively serving many clients from different IPs (and maybe different ports) but to the same server IP and Port. Depends on your design and what you think is best for your application.
R
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
