TCP/IP for MMPOGs?
Author
I was just reading some information on Zona''s SDK (www.zona.net), which appears to be using TCP/IP for all of it''s communications. I thought that TCP/IP was too "slow" (in a loose sense of the word) for massively multi-player games, and that multicast was the way to go for distributing object states? I''m putting together a little prototype on networking for an MPOG and I''m planning on using TCP/IP for system control and multicast for general game communications.
So what''s the story here? Thanks
TCP/IP is a "suite" of protocols, not a single protocol. It so happens the two of TCP/IPs protocols are called TCP and another is called IP. There is also one called UDP which you may have heard of. There are a bunch of other protocols in the TCP/IP suite as well.
It is the actual TCP protocol that people say is too slow for games, not the whole TCP/IP suite. I would guess that zona uses the UDP protocol of the TCP/IP suite.
IMO Multicast would definately not be the way to go for MMOG, because multicast assumes you want to send all data to every person connected to the multicast adress, and a MMOG needs much finer control over what data it send to who.
Also remember that Multicast isn''t standard on the internet yet, even if you set up a multicast server on your end, many people behind old-fashioned ISP''s may not be able to join the multicast group.
Hope theres some useful info in there for you
BTW, what does the P stand for in MPOG?
It is the actual TCP protocol that people say is too slow for games, not the whole TCP/IP suite. I would guess that zona uses the UDP protocol of the TCP/IP suite.
IMO Multicast would definately not be the way to go for MMOG, because multicast assumes you want to send all data to every person connected to the multicast adress, and a MMOG needs much finer control over what data it send to who.
Also remember that Multicast isn''t standard on the internet yet, even if you set up a multicast server on your end, many people behind old-fashioned ISP''s may not be able to join the multicast group.
Hope theres some useful info in there for you
BTW, what does the P stand for in MPOG?
Author
The ''P'' stands for Player.
I thought with Multicast you could send data to a specific group of clients?
I thought with Multicast you could send data to a specific group of clients?
Kinda...
If i remember correctly...
The server creates/signs up a multicast address, and then clients can register with that multicast address. So you could have many multicast addresses, but (depending on how you design your game) you are going to dynamically change the groupings for your clients. You would probably find it more efficient to just handle the groupings on your server and send info to the appropriate clients...especially since you would have to host the multicast server yourself anyway (AFAIK).
If i remember correctly...
The server creates/signs up a multicast address, and then clients can register with that multicast address. So you could have many multicast addresses, but (depending on how you design your game) you are going to dynamically change the groupings for your clients. You would probably find it more efficient to just handle the groupings on your server and send info to the appropriate clients...especially since you would have to host the multicast server yourself anyway (AFAIK).
According to what I have read, you want to use UDP to send game updates to the clients. UDP is not guaranteed to arrive but it is faster, partially because it doesn''t require confirmation and resending of failed packets. For stuff like user logins and really important ''must arrive'' packets, you would use TCP because that requires arrival confirmation and resend of lost packets. I don''t know what multicast is but from the sounds of several different posts, you probably want to avoid it.
Author
quote:Original post by Anonymous Poster
Kinda...
If i remember correctly...
The server creates/signs up a multicast address, and then clients can register with that multicast address. So you could have many multicast addresses, but (depending on how you design your game) you are going to dynamically change the groupings for your clients. You would probably find it more efficient to just handle the groupings on your server and send info to the appropriate clients...especially since you would have to host the multicast server yourself anyway (AFAIK).
That''s what I was thinking. But common thought is that this isn''t the best way.
First, a little nitpicking about protocols: UDP is not part of TCP, both UDP and TCP are part of IP. So you could say UDP/IP or TCP/IP. TCP is actually built on top of UDP.
Second, multicast uses UDP and works pretty much like the previous poster said. And also as they said, basically multicast won''t work over the internet, there isn''t enough support for it yet.
Also multicast sends the exact same packet to everyone in the multicast group, which depending on your game, is probably not that useful. Since as players move around, they will have to join other multicast groups, which would probably require a large number of multicast addresses per server.
Now about whether to use UDP or TCP,
Basically if you need speed our of you game as in it requires realtime response (ie. an action game) you will need to use UDP in order to reduce lag. UDP works well for getting user input and sending positional information to the client, and not very well for other things.
You will also have to have some form or reliable transport, because there will be some things that the client must receive, inorder and completely.
So, if your game is action based, you will need to use UDP and TCP (or your own protocol that uses UDP, to ensure inorder and reliable transport, which is A LOT of work).
If your game is not action based, you can probably get away with TCP, and save yourself some headaches.
Second, multicast uses UDP and works pretty much like the previous poster said. And also as they said, basically multicast won''t work over the internet, there isn''t enough support for it yet.
Also multicast sends the exact same packet to everyone in the multicast group, which depending on your game, is probably not that useful. Since as players move around, they will have to join other multicast groups, which would probably require a large number of multicast addresses per server.
Now about whether to use UDP or TCP,
Basically if you need speed our of you game as in it requires realtime response (ie. an action game) you will need to use UDP in order to reduce lag. UDP works well for getting user input and sending positional information to the client, and not very well for other things.
You will also have to have some form or reliable transport, because there will be some things that the client must receive, inorder and completely.
So, if your game is action based, you will need to use UDP and TCP (or your own protocol that uses UDP, to ensure inorder and reliable transport, which is A LOT of work).
If your game is not action based, you can probably get away with TCP, and save yourself some headaches.
Author
Thankyou for the info and nit-picking. Very useful.
quote:Original post by Anonymous Poster
First, a little nitpicking about protocols: UDP is not part of TCP, both UDP and TCP are part of IP. So you could say UDP/IP or TCP/IP. TCP is actually built on top of UDP.
Second, multicast uses UDP and works pretty much like the previous poster said. And also as they said, basically multicast won''t work over the internet, there isn''t enough support for it yet.
Also multicast sends the exact same packet to everyone in the multicast group, which depending on your game, is probably not that useful. Since as players move around, they will have to join other multicast groups, which would probably require a large number of multicast addresses per server.
Now about whether to use UDP or TCP,
Basically if you need speed our of you game as in it requires realtime response (ie. an action game) you will need to use UDP in order to reduce lag. UDP works well for getting user input and sending positional information to the client, and not very well for other things.
You will also have to have some form or reliable transport, because there will be some things that the client must receive, inorder and completely.
So, if your game is action based, you will need to use UDP and TCP (or your own protocol that uses UDP, to ensure inorder and reliable transport, which is A LOT of work).
If your game is not action based, you can probably get away with TCP, and save yourself some headaches.
quote:TCP is actually built on top of UDP.
Sorry about the nitpicking, but I do not believe this to be true. The two protocols have different segment headers and you can not get a properly formatted TCP header by just appending some info to a UDP header.
TCP is built on top of IP, hence TCP/IP. UDP is also built on IP. You very rarely see UDP/IP for some reason. TCP is *not* build on UDP.
Please get the word "slow" out of your head. There is nothing inherently slow about TCP. The reason many people prefer UDP is because it gives you more control over the data stream when the network is being flakey and dropping packets or delivering them out of sequence. If the Internet was perfect there would be no reason not to use TCP.
-Mike
Please get the word "slow" out of your head. There is nothing inherently slow about TCP. The reason many people prefer UDP is because it gives you more control over the data stream when the network is being flakey and dropping packets or delivering them out of sequence. If the Internet was perfect there would be no reason not to use TCP.
-Mike
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
