SCTP in MMO Development
Author
I'm a researcher at the University of Delaware. Specifically in the Protocol Engineering Lab of the Dept. of Computer and Information Science. We are exploring the usefulness of the Stream Control Transmission Protocol (SCTP) to the development/scalability/performance of MMO games.
SCTP is a connection oriented protocol (TCP-like), and also message based (UDP-like). SCTP also has TCP-friendly congesstion control. Of particular interest to MMO development, is a feature known as PR (Partially Reliable service). It gives a sender the ability to allow a message to time-out while it is still in the outbound queue at the sender's end.
However, as a research group, none of us have coded an MMO or are even that sure of how the clients and servers communicate (bytes/sec, msg formats, avg. round trip times, etc).
If I could get feedback here on the forums or possibly in-depth via email that would be great.
For SCTP reference please see:
http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/
http://www.sctp.org/sctpoverview.html
http://www.ietf.org/rfc/rfc2960.txt
And specifically for SCTP Partially Reliable Extention:
ftp://ftp.rfc-editor.org/in-notes/rfc3758.txt
Thanks,
~Ethan Giordano
Last time I looked at SCTP, it wasn't widely adopted, and didn't solve the actual needs for a real-time interactive game.
The most important thing to understand about interactive games is that they are real-time, low-latency data. For the vast majority of the traffic, if the packet doesn't make it to the destination within a very small window (range of 50 ms to 500 ms depending on architecture), the data is stale, and you'll be better off just dropping the packet and sending a newer, fresher state the next time you update. It's not dis-similar to VOIP needs, really -- low latency, and real-time.
Games often have some small data channel of "reliable" or "sequenced" packet streams, such as text chat, or mandatory game state updates; these are typically implemented ad-hoc using packet acknowledgement piggybacking on an unreliable underlying real-time connection (i e, UDP). Some games use TCP for these, and UDP for real-time updates. It is often useful for games to still pay attention to out-of-order updates, too.
A typical game will also have a fixed scaler between quality and bandwidth. Typical games will settle on a single bandwidth (or make this a static configuration option), and then support a certain quality of interaction. A really smart game will use various packet loss metrics to try to scale quality based on available/observed throughput -- but to do that, you need to get reliable data about how your packets are making it through, which in this context means application-level acknowledgement processing. This means that the application does data rate throttling/adaptation -- thus, any packet queued on the network interface is expected to immediately make it out onto the internet, and the upper-layer protocol deals with the fact that this packet may be delayed, re-ordered, duplicated or lost.
If this short overview doesn't help, there are references in the Forum FAQ to various resources on how different kinds of games do networking.
The most important thing to understand about interactive games is that they are real-time, low-latency data. For the vast majority of the traffic, if the packet doesn't make it to the destination within a very small window (range of 50 ms to 500 ms depending on architecture), the data is stale, and you'll be better off just dropping the packet and sending a newer, fresher state the next time you update. It's not dis-similar to VOIP needs, really -- low latency, and real-time.
Games often have some small data channel of "reliable" or "sequenced" packet streams, such as text chat, or mandatory game state updates; these are typically implemented ad-hoc using packet acknowledgement piggybacking on an unreliable underlying real-time connection (i e, UDP). Some games use TCP for these, and UDP for real-time updates. It is often useful for games to still pay attention to out-of-order updates, too.
A typical game will also have a fixed scaler between quality and bandwidth. Typical games will settle on a single bandwidth (or make this a static configuration option), and then support a certain quality of interaction. A really smart game will use various packet loss metrics to try to scale quality based on available/observed throughput -- but to do that, you need to get reliable data about how your packets are making it through, which in this context means application-level acknowledgement processing. This means that the application does data rate throttling/adaptation -- thus, any packet queued on the network interface is expected to immediately make it out onto the internet, and the upper-layer protocol deals with the fact that this packet may be delayed, re-ordered, duplicated or lost.
If this short overview doesn't help, there are references in the Forum FAQ to various resources on how different kinds of games do networking.
A friend in our group was looking into sctp, not sure exactly where that one went.
His past work wasn't on mmo's though. It was progressive mesh transmission. I think he was looking into multimedia middleware. I will see when i talk to him next.
His past work wasn't on mmo's though. It was progressive mesh transmission. I think he was looking into multimedia middleware. I will see when i talk to him next.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
