Ok after finding that out its just mad to have a MMO thats TCP the over head added to each packet for online play with others and in real time is madness. Sure TCP is a reliable Protocol over UDP its not the best used for real time communication with others but could it of been done so the server is not overloaded say a hybrid?
We have NAT traversal that allows for UDP to pass through routers without opening ports this would a allow a hand full of players to connect to each other (could be done dynamically on the fly to nearest player) and udp to the server for everyone else with TCP to the server keeping connections in check but not used as the real time sender or receiver.
I can see that their would be better security doing it the way STO has done it and sure it works with a limit to each instance but a hybrid dynamic solution for MMO is the way to go and load balance off the servers and allows more players to see each other without changing instances.
Well thats just me and thought I share a some what pointless post but STO better keep working the way it does if/when more people get online. :cool:
Have you ever done any game or network programming?
Can a person fix a car but not drive it? Or drive a car but not fix it?
If I didn't know what I'm taking about I wouldn't of posted but your just going to say I didn't answer your question which is no and so you think I don't know anything because I don't know the other.
So can a person fix a car but not drive it have an idea of how to drive it? Yes Or drive a car but not fix it have an idea of how to fix it? Yes.
I know that TCP versus UDP for STO was talking about in IRC #stoqa a few weeks abck. I think there was also a dev post in the forums answering some questions.
You can always hang out in #stoqa and ask one of the devs when they are in there.
So I'm going to go out on a limb and assume you are actually interested in the technical details and not just trolling for dev posts. If this is not the case, just imagine this space is full of cat macros and get back to /b/ post-haste. With that out of the way, why do we use TCP?
To start with, MMOs use very little bandwidth in general (patching aside, but that needs to be TCP anyway for reliability), but we send a lot of small packets very frequently. Also, because we send updates as incremental diffs to minimize bandwidth usage, packets need to arrive in-order, and because user input is important, it needs to be sent reliably. So we now have two needed features: reliability and in-order delivery. This is starting to smell a lot more like TCP, no? Sure, there are some updates that could be structured to use a UDP-style message (such as position updates), but putting in such a huge special case is an enormous headache for very little gain (as we shall see). As for NAT traversal, we have no need since the connection is always client->server anyway.
So then there is question of overhead. Yes, TCP does have additional overhead, however it ends up being far less of an issue than it is made out to be. First we use a single persistent connection. This means the overhead of connection setup is done once and therefore is entirely insignificant (technically we use one connection each time you transfer maps, but on the timescales of networking it doesn't matter). Second, thanks to TCP window scaling, the overhead of ACKs quickly drops off to the minimum needed for your connection speed. And then the biggest argument really, we would have to implement all this overhead ourselves to get reliable, in-order UDP. Lets face it, chances are we can't re-implement TCP and come out with something nearly as good or as fast.
We have actually gone down the reliable-UDP route before, that is what Cities uses. In fact many game companies have used it over the years. Most are slowly switching camps, as we did. The major contributing factor is that on the internet today, latency is the limiting factor instead of bandwidth. Cable modems and DSL are widespread, but processing latency on routers hasn't changed much in the last decade or two.
Hopefully that isn't too wall-o'-texty, and answers some questions about the joys of real-world network programming. Isn't it fun seeing how the sausage is made?
Well this is my 3rd post I think maybe 4th,
Love the reply Dev
Very informative, Thats what I look to see not just about the game but talk aboutt the building blocks and decisions made on a technical level.. I love it when you talk dirty
Speaking as a network engineer, it is better to just go ahead and use TCP. Most MMO's use UDP, but then end up having to manually build up error correction on their own and basically end up with something that resembles TCP, just a lot less reliable (and possibly even ending up with more network/CPU overhead).
The reason for this is UDP has no error correction at all, if a packet is dropped or arrives out of order, there is nothing in the protocol to correct the error, hence the need to build an error correction "hack" to stick on top of it. TCP already has error correction.
Better to standardize on TCP and optimize everything to make it run as smoothly as possible.
Besides, every network device from the NIC to the home router, to every router on the internet is designed with TCP/IP in mind, rather than some hack layered on UDP.
You would be surprised how much of the "lag" experienced in MMOs is generated by the "clever" "error correcting" UDP the Devs wrote, at least as much as the servers.
With there being greater and greater bandwidth available, and faster and faster servers and PC's, I think the days of UDP even being worth considering for an online game should be a thing of the past.
So then there is question of overhead. Yes, TCP does have additional overhead, however it ends up being far less of an issue than it is made out to be. First we use a single persistent connection. This means the overhead of connection setup is done once and therefore is entirely insignificant (technically we use one connection each time you transfer maps, but on the timescales of networking it doesn't matter). Second, thanks to TCP window scaling, the overhead of ACKs quickly drops off to the minimum needed for your connection speed. And then the biggest argument really, we would have to implement all this overhead ourselves to get reliable, in-order UDP. Lets face it, chances are we can't re-implement TCP and come out with something nearly as good or as fast.
Loved the technical explanation - I wish more MMO devs did this. It makes a lot of sense too. Perhaps we'll eventually see 'MMO using UDP!? Still?!' posts in time (on other forums obviously)...
So I'm going to go out on a limb and assume you are actually interested in the technical details and not just trolling for dev posts. If this is not the case, just imagine this space is full of cat macros and get back to /b/ post-haste. With that out of the way, why do we use TCP?
To start with, MMOs use very little bandwidth in general (patching aside, but that needs to be TCP anyway for reliability), but we send a lot of small packets very frequently. Also, because we send updates as incremental diffs to minimize bandwidth usage, packets need to arrive in-order, and because user input is important, it needs to be sent reliably. So we now have two needed features: reliability and in-order delivery. This is starting to smell a lot more like TCP, no? Sure, there are some updates that could be structured to use a UDP-style message (such as position updates), but putting in such a huge special case is an enormous headache for very little gain (as we shall see). As for NAT traversal, we have no need since the connection is always client->server anyway.
So then there is question of overhead. Yes, TCP does have additional overhead, however it ends up being far less of an issue than it is made out to be. First we use a single persistent connection. This means the overhead of connection setup is done once and therefore is entirely insignificant (technically we use one connection each time you transfer maps, but on the timescales of networking it doesn't matter). Second, thanks to TCP window scaling, the overhead of ACKs quickly drops off to the minimum needed for your connection speed. And then the biggest argument really, we would have to implement all this overhead ourselves to get reliable, in-order UDP. Lets face it, chances are we can't re-implement TCP and come out with something nearly as good or as fast.
We have actually gone down the reliable-UDP route before, that is what Cities uses. In fact many game companies have used it over the years. Most are slowly switching camps, as we did. The major contributing factor is that on the internet today, latency is the limiting factor instead of bandwidth. Cable modems and DSL are widespread, but processing latency on routers hasn't changed much in the last decade or two.
Hopefully that isn't too wall-o'-texty, and answers some questions about the joys of real-world network programming. Isn't it fun seeing how the sausage is made?
Be-ing a Network Engineer by trade TCP would be the better way to go in this scenario...Nice description..Very good to know!
So I'm going to go out on a limb and assume you are actually interested in the technical details and not just trolling for dev posts. If this is not the case, just imagine this space is full of cat macros and get back to /b/ post-haste. With that out of the way, why do we use TCP?
To start with, MMOs use very little bandwidth in general (patching aside, but that needs to be TCP anyway for reliability), but we send a lot of small packets very frequently. Also, because we send updates as incremental diffs to minimize bandwidth usage, packets need to arrive in-order, and because user input is important, it needs to be sent reliably. So we now have two needed features: reliability and in-order delivery. This is starting to smell a lot more like TCP, no? Sure, there are some updates that could be structured to use a UDP-style message (such as position updates), but putting in such a huge special case is an enormous headache for very little gain (as we shall see). As for NAT traversal, we have no need since the connection is always client->server anyway.
So then there is question of overhead. Yes, TCP does have additional overhead, however it ends up being far less of an issue than it is made out to be. First we use a single persistent connection. This means the overhead of connection setup is done once and therefore is entirely insignificant (technically we use one connection each time you transfer maps, but on the timescales of networking it doesn't matter). Second, thanks to TCP window scaling, the overhead of ACKs quickly drops off to the minimum needed for your connection speed. And then the biggest argument really, we would have to implement all this overhead ourselves to get reliable, in-order UDP. Lets face it, chances are we can't re-implement TCP and come out with something nearly as good or as fast.
We have actually gone down the reliable-UDP route before, that is what Cities uses. In fact many game companies have used it over the years. Most are slowly switching camps, as we did. The major contributing factor is that on the internet today, latency is the limiting factor instead of bandwidth. Cable modems and DSL are widespread, but processing latency on routers hasn't changed much in the last decade or two.
Hopefully that isn't too wall-o'-texty, and answers some questions about the joys of real-world network programming. Isn't it fun seeing how the sausage is made?
Interesting. I'd love to hear more of the technical side of MMO development. Although, as a mostly database oriented developer, I was disapointed to hear you guys are SQL-phobic
Interesting. I'd love to hear more of the technical side of MMO development. Although, as a mostly database oriented developer, I was disapointed to hear you guys are SQL-phobic
In truth the main difference in usage between UDP and TCP in this kind of apllications is the reaction to packet loss and timeouts. UDP lets you be more lenient against heavy packet loss and lag since you can basically accept (ofc, this is very much in theory) the latest valid packet and start tracking again from that point. The TCP approach means that if you're getting a heavy lag spike you have to fall back and resend (eventually multiple times) packets.
That's why most of the FPSs I know of chose the UDP approach: it's better to lose some data than to have to retrace back all the way to the commands lost since that additional time may actually do more damage than good.
EDIT for clarity: the differences between UDP and TCP are clear. When I said "in this kind of applications" I meant that you're going to have to build reliability and probably also ordering on top of UDP anyway.
Thanks for the info. I'd always like to see technical background information. Info like this (why you did chose solution A over or info about how things work (e.g. an earlier post about what has to be done to 'fire up' the shard).
So I'm going to go out on a limb and assume you are actually interested in the technical details and not just trolling for dev posts.
Yup just interested that all really not saying it really needs to be done another way just that for real time data UDP from what I have learnt is best.
Sure no need for NAT traversal with it being client to server but the idea is to have client to clients by UDP with the server checking the connections by TCP allowing better latency on big groups or auto teaming to run smoother.
I'm just wondering if the STO server (or servers?) has enough bandwidth CPU to handle many large scale actions happening with it all being under TCP?
Thanks for taking the time for saying why its TCP I'm just a pain then a troll.:p
Yup just interested that all really not saying it really needs to be done another way just that for real time data UDP from what I have learnt is best.
Sure no need for NAT traversal with it being client to server but the idea is to have client to clients by UDP with the server checking the connections by TCP allowing better latency on big groups or auto teaming to run smoother.
I'm just wondering if the STO server (or servers?) has enough bandwidth CPU to handle many large scale actions happening with it all being under TCP?
Thanks for taking the time for saying why its TCP I'm just a pain then a troll.:p
Client-to-client comms are out of the question for obvious reasons, we can never trust the client. Cheating would be rife, and there is no way to stop it. Just a limitation of the genre. What I was trying to explain is that what you have been taught it out of date and UDP is not useful to games anymore really :-) TCP doesn't present much in the way of a CPU load, things like fragmention handling is now generally done on the NIC itself.
Client-to-client comms are out of the question for obvious reasons, we can never trust the client. Cheating would be rife, and there is no way to stop it. Just a limitation of the genre. What I was trying to explain is that what you have been taught it out of date and UDP is not useful to games anymore really :-) TCP doesn't present much in the way of a CPU load, things like fragmention handling is now generally done on the NIC itself.
Everything that does not include Coax cabeling, and generally giving me a electricity byzzzz evertime something goes a-wall, I aprove of this thread. Nice to know the background tho. Cheers
Client-to-client comms are out of the question for obvious reasons, we can never trust the client.
And also, what possible use could it be? The other clients don't know anything helpful.
What I was trying to explain is that what you have been taught it out of date and UDP is not useful to games anymore really :-)
That's a bit too broad. It's more that what people are "taught" is really just a few observations on how certain games famously operated, and frequently misunderstood.
UDP was, and still is, better than TCP for implementing Quake. This is the big one which is behind the "UDP is good for games" idea: all the people who say this are talking about Quake and its imitators, because it's one of the tiny handful of major games for which the source has been made publicly available, and because the way it works has been extensively studied. The reasons for this have never had anything to do with overheads. There are specific issues with TCP which make it unsuitable, most importantly the inability to process messages out of order when packets are lost. However, use of UDP is also questionable for the reasons you mentioned earlier. The ideal protocol for these games is SCTP - sadly, uptake has been non-existent.
UDP was never useful for MMOs, MUDs, turn-based games, and anything else where out-of-order processing is impossible.
And also, what possible use could it be? The other clients don't know anything helpful.
That's a bit too broad. It's more that what people are "taught" is really just a few observations on how certain games famously operated, and frequently misunderstood.
UDP was, and still is, better than TCP for implementing Quake. This is the big one which is behind the "UDP is good for games" idea: all the people who say this are talking about Quake and its imitators, because it's one of the tiny handful of major games for which the source has been made publicly available, and because the way it works has been extensively studied. The reasons for this have never had anything to do with overheads. There are specific issues with TCP which make it unsuitable, most importantly the inability to process messages out of order when packets are lost. However, use of UDP is also questionable for the reasons you mentioned earlier. The ideal protocol for these games is SCTP - sadly, uptake has been non-existent.
UDP was never useful for MMOs, MUDs, turn-based games, and anything else where out-of-order processing is impossible.
Multicasting SCTPv6. ::dreams:: We could basically erase 80% of our network layer and state tracking system and just let the OS/routers deal with it. Not that this is likely to happen before the sun is a small chunk of iron, but oh well >_<
Well routers could likely do it today, with very little effort.
SCTP support in operating systems... that's a whole other story.
Routers doing STCP, yes. Using multicast on the internet, no. Last time I saw estimates people were saying something like 2015 before IPv6+multicast is usable on the internet.
Routers don't need any special support for SCTP. The internet protocol model doesn't involve routers at the transport layer. All the major operating systems have support for it now; the only throwbacks are windows and macosx, which fail to ship it by default. Userspace implementations are available for them both, although not very extensively tested - nobody does network stuff with those platforms.
A more existing problem is cheap firewalls embedded into consumer modems, and the awful software not-really-a-firewall things that windows users are so fond of. Far too many of them are misconfigured in ways which break SCTP. There's a workaround to tunnel it over UDP though, so it's not a fatal problem.
There's no particular reason why it can't be used today. People just aren't bothering, usually for no better reason than NIH. Large organisations may also have training costs to get their support people ready, although that's a lesser concern.
Multicast is harder. The technology all works fine, but the corporations which run much of the internet have been running around throwing up policy barriers to prevent it from being used. Getting it working is going to involve bashing their heads together until they stop. It's already up and running on the few non-corporate areas (like janet and geant).
Multicast SCTP does not exist yet. There's a few people doing research on whether it's possible and useful. For the sort of low-bandwidth low-fanout things STO does, it's unclear whether something like that would be beneficial.
Routers don't need any special support for SCTP. The internet protocol model doesn't involve routers at the transport layer. All the major operating systems have support for it now; the only throwbacks are windows and macosx, which fail to ship it by default. Userspace implementations are available for them both, although not very extensively tested - nobody does network stuff with those platforms.
A more existing problem is cheap firewalls embedded into consumer modems, and the awful software not-really-a-firewall things that windows users are so fond of. Far too many of them are misconfigured in ways which break SCTP. There's a workaround to tunnel it over UDP though, so it's not a fatal problem.
There's no particular reason why it can't be used today. People just aren't bothering, usually for no better reason than NIH. Large organisations may also have training costs to get their support people ready, although that's a lesser concern.
Multicast is harder. The technology all works fine, but the corporations which run much of the internet have been running around throwing up policy barriers to prevent it from being used. Getting it working is going to involve bashing their heads together until they stop. It's already up and running on the few non-corporate areas (like janet and geant).
Multicast SCTP does not exist yet. There's a few people doing research on whether it's possible and useful. For the sort of low-bandwidth low-fanout things STO does, it's unclear whether something like that would be beneficial.
Multicast for an MMO would only really be useful when combined with having a gigantic address space, you really need v6 too. The simplest system would basically assign a multicast IP to every single user in the game, and handle things like team and group updates by having the client just start receiving the updates for that user.
1. TCP is not an optimal implementation of a reliable, stream oriented, lossless connection. It's not very "sexy" so vendors tend to ignore it in favor of tuning other features. Besides, the tuning they did do back in 1986 for use with Telnet and FTP aren't really valid in a gaming context.
2. TCP is a stream-oriented design, rather than a datagram-oriented design. It doesn't have any way of marking boundaries between datagrams, so the designer has to implement a way of doing that in their code. TCP reads can return a part of a write from the other side, a whole write, or even multiple writes.
3. TCP retransmission is still bad, even in MMOs. You rilly, rilly, RILLY don't need to see everybody's position updates all the time with a properly written state synchronization. No amount of time flowing under the bridge will change this fundamental truth until the underlying IP system is completely reliable (which will never happen as it's not designed to be), it will never be "out of date". A quaint, and pointless notion.
Example: Three updates are sent, updating the position of some objects. We'll assume for simplicity that each update is updating the position of each object. We'll label these updates A, B, and C, each taking up one IP datagram.
Server: A,B,C!
Network: uh, something.. no.. C.. yeah... and.. uh.. A. maybe.
Client-UDP: C,A (notes timestamp on C is later than A, discards A, places objects at position C)
Client-TCP: What?
...
Server-TCP(OS): no ack? huh... A,B,C...
Network: A, uh, something.. C!
Client-TCP: ack A.. waiting...
...
Server-TCP(OS): no ack for B, C? B, C, dammit!!!
Network: C.
Client-TCP: Where the mog is B?
...
Server-TCP(OS): Packetloss intense. increasing retry delay...
...
Server-TCP(OS): B.
Network: C!!
Client-TCP: Packet duplication!
...
Server-TCP(Game): updates D,E,F,G,H,I,J...
Server-TCP(OS): Transmit Buffer full~ Connection lost.
Network: C!!!!!!!!!
Client-TCP: Oh, just shut up already. I am so switching providers and not using wireless anymore.
4. One thing the above glosses over, but mentions in the example, is that TCP has to wait for the data to be validated before sending it over to the application. With UDP, it passes a basic checksum and is handed off immediately.
5. As I mentioned above about tuning, several features designed to improve the bandwidth of TCP (halfheartedly tacked on lately) often cause major problems with gaming as they are optimizing bandwidth over responsiveness. Ex. the Nagle algorithm, which delays transmissions until an efficient amount of data is available to send. TCP_NODELAY!!!! EEk!!~~
Of course TCP has it's place, for instance, telnet, ssh, most web usage, chats, etc, where you want to see the data in order, and only in order, and not miss anything (snide remarks about the lack of actual content on the internet aside, anyways), regardless of how much extra time it takes.
One has to be careful making assumptions about the underlying quality of the internet, Kerries has some very insider information on certain massively huge tier 1 providers that suggests that a lessez-faire attitude exists amongst the traffic shaping engineers exists (they are even more 'meh' about IPv6, btw, and won't implement it anytime soon, meaning that 50% of the net's traffic will still be tunneling over IPv4 .. forever), and that other tier 1 providers have similar, degenerate attitudes. Also, wireless is NOT a perfect technology, and is often adding a fair bit of packetloss and retransmissions to every connection going over it.
5. As I mentioned above about tuning, several features designed to improve the bandwidth of TCP (halfheartedly tacked on lately) often cause major problems with gaming as they are optimizing bandwidth over responsiveness. Ex. the Nagle algorithm, which delays transmissions until an efficient amount of data is available to send. TCP_NODELAY!!!! EEk!!~~
I don't think I've worked on a network app in the last 15 years that didn't immediately turn off the Nagle Algorithm.
Comments
Can a person fix a car but not drive it? Or drive a car but not fix it?
If I didn't know what I'm taking about I wouldn't of posted but your just going to say I didn't answer your question which is no and so you think I don't know anything because I don't know the other.
So can a person fix a car but not drive it have an idea of how to drive it? Yes Or drive a car but not fix it have an idea of how to fix it? Yes.
You can always hang out in #stoqa and ask one of the devs when they are in there.
Maybe you'll find some interest in this forum?
http://www.gamedev.net/community/forums/forum.asp?vb_id=15
To start with, MMOs use very little bandwidth in general (patching aside, but that needs to be TCP anyway for reliability), but we send a lot of small packets very frequently. Also, because we send updates as incremental diffs to minimize bandwidth usage, packets need to arrive in-order, and because user input is important, it needs to be sent reliably. So we now have two needed features: reliability and in-order delivery. This is starting to smell a lot more like TCP, no? Sure, there are some updates that could be structured to use a UDP-style message (such as position updates), but putting in such a huge special case is an enormous headache for very little gain (as we shall see). As for NAT traversal, we have no need since the connection is always client->server anyway.
So then there is question of overhead. Yes, TCP does have additional overhead, however it ends up being far less of an issue than it is made out to be. First we use a single persistent connection. This means the overhead of connection setup is done once and therefore is entirely insignificant (technically we use one connection each time you transfer maps, but on the timescales of networking it doesn't matter). Second, thanks to TCP window scaling, the overhead of ACKs quickly drops off to the minimum needed for your connection speed. And then the biggest argument really, we would have to implement all this overhead ourselves to get reliable, in-order UDP. Lets face it, chances are we can't re-implement TCP and come out with something nearly as good or as fast.
We have actually gone down the reliable-UDP route before, that is what Cities uses. In fact many game companies have used it over the years. Most are slowly switching camps, as we did. The major contributing factor is that on the internet today, latency is the limiting factor instead of bandwidth. Cable modems and DSL are widespread, but processing latency on routers hasn't changed much in the last decade or two.
Hopefully that isn't too wall-o'-texty, and answers some questions about the joys of real-world network programming. Isn't it fun seeing how the sausage is made?
(im a programmer and web developer)
Love the reply Dev
Very informative, Thats what I look to see not just about the game but talk aboutt the building blocks and decisions made on a technical level.. I love it when you talk dirty
The reason for this is UDP has no error correction at all, if a packet is dropped or arrives out of order, there is nothing in the protocol to correct the error, hence the need to build an error correction "hack" to stick on top of it. TCP already has error correction.
Better to standardize on TCP and optimize everything to make it run as smoothly as possible.
Besides, every network device from the NIC to the home router, to every router on the internet is designed with TCP/IP in mind, rather than some hack layered on UDP.
You would be surprised how much of the "lag" experienced in MMOs is generated by the "clever" "error correcting" UDP the Devs wrote, at least as much as the servers.
With there being greater and greater bandwidth available, and faster and faster servers and PC's, I think the days of UDP even being worth considering for an online game should be a thing of the past.
(and etc.)
Gee thanks, that is fascinating stuff.
Informative post though, coderanger!
Be-ing a Network Engineer by trade TCP would be the better way to go in this scenario...Nice description..Very good to know!
Rule #1 & 2
That's why most of the FPSs I know of chose the UDP approach: it's better to lose some data than to have to retrace back all the way to the commands lost since that additional time may actually do more damage than good.
EDIT for clarity: the differences between UDP and TCP are clear. When I said "in this kind of applications" I meant that you're going to have to build reliability and probably also ordering on top of UDP anyway.
Yup just interested that all really not saying it really needs to be done another way just that for real time data UDP from what I have learnt is best.
Sure no need for NAT traversal with it being client to server but the idea is to have client to clients by UDP with the server checking the connections by TCP allowing better latency on big groups or auto teaming to run smoother.
I'm just wondering if the STO server (or servers?) has enough bandwidth CPU to handle many large scale actions happening with it all being under TCP?
Thanks for taking the time for saying why its TCP I'm just a pain then a troll.:p
So WoW and DAoC are client to client?
Eh 'cept for what I stated. Sadly there still are many users with low bandwidth connections where that issue is quite critical (like me) =/
And also, what possible use could it be? The other clients don't know anything helpful.
That's a bit too broad. It's more that what people are "taught" is really just a few observations on how certain games famously operated, and frequently misunderstood.
UDP was, and still is, better than TCP for implementing Quake. This is the big one which is behind the "UDP is good for games" idea: all the people who say this are talking about Quake and its imitators, because it's one of the tiny handful of major games for which the source has been made publicly available, and because the way it works has been extensively studied. The reasons for this have never had anything to do with overheads. There are specific issues with TCP which make it unsuitable, most importantly the inability to process messages out of order when packets are lost. However, use of UDP is also questionable for the reasons you mentioned earlier. The ideal protocol for these games is SCTP - sadly, uptake has been non-existent.
UDP was never useful for MMOs, MUDs, turn-based games, and anything else where out-of-order processing is impossible.
SCTP support in operating systems... that's a whole other story.
A more existing problem is cheap firewalls embedded into consumer modems, and the awful software not-really-a-firewall things that windows users are so fond of. Far too many of them are misconfigured in ways which break SCTP. There's a workaround to tunnel it over UDP though, so it's not a fatal problem.
There's no particular reason why it can't be used today. People just aren't bothering, usually for no better reason than NIH. Large organisations may also have training costs to get their support people ready, although that's a lesser concern.
Multicast is harder. The technology all works fine, but the corporations which run much of the internet have been running around throwing up policy barriers to prevent it from being used. Getting it working is going to involve bashing their heads together until they stop. It's already up and running on the few non-corporate areas (like janet and geant).
Multicast SCTP does not exist yet. There's a few people doing research on whether it's possible and useful. For the sort of low-bandwidth low-fanout things STO does, it's unclear whether something like that would be beneficial.
1. TCP is not an optimal implementation of a reliable, stream oriented, lossless connection. It's not very "sexy" so vendors tend to ignore it in favor of tuning other features. Besides, the tuning they did do back in 1986 for use with Telnet and FTP aren't really valid in a gaming context.
2. TCP is a stream-oriented design, rather than a datagram-oriented design. It doesn't have any way of marking boundaries between datagrams, so the designer has to implement a way of doing that in their code. TCP reads can return a part of a write from the other side, a whole write, or even multiple writes.
3. TCP retransmission is still bad, even in MMOs. You rilly, rilly, RILLY don't need to see everybody's position updates all the time with a properly written state synchronization. No amount of time flowing under the bridge will change this fundamental truth until the underlying IP system is completely reliable (which will never happen as it's not designed to be), it will never be "out of date". A quaint, and pointless notion.
Example: Three updates are sent, updating the position of some objects. We'll assume for simplicity that each update is updating the position of each object. We'll label these updates A, B, and C, each taking up one IP datagram.
Server: A,B,C!
Network: uh, something.. no.. C.. yeah... and.. uh.. A. maybe.
Client-UDP: C,A (notes timestamp on C is later than A, discards A, places objects at position C)
Client-TCP: What?
...
Server-TCP(OS): no ack? huh... A,B,C...
Network: A, uh, something.. C!
Client-TCP: ack A.. waiting...
...
Server-TCP(OS): no ack for B, C? B, C, dammit!!!
Network: C.
Client-TCP: Where the mog is B?
...
Server-TCP(OS): Packetloss intense. increasing retry delay...
...
Server-TCP(OS): B.
Network: C!!
Client-TCP: Packet duplication!
...
Server-TCP(Game): updates D,E,F,G,H,I,J...
Server-TCP(OS): Transmit Buffer full~ Connection lost.
Network: C!!!!!!!!!
Client-TCP: Oh, just shut up already. I am so switching providers and not using wireless anymore.
4. One thing the above glosses over, but mentions in the example, is that TCP has to wait for the data to be validated before sending it over to the application. With UDP, it passes a basic checksum and is handed off immediately.
5. As I mentioned above about tuning, several features designed to improve the bandwidth of TCP (halfheartedly tacked on lately) often cause major problems with gaming as they are optimizing bandwidth over responsiveness. Ex. the Nagle algorithm, which delays transmissions until an efficient amount of data is available to send. TCP_NODELAY!!!! EEk!!~~
Of course TCP has it's place, for instance, telnet, ssh, most web usage, chats, etc, where you want to see the data in order, and only in order, and not miss anything (snide remarks about the lack of actual content on the internet aside, anyways), regardless of how much extra time it takes.
One has to be careful making assumptions about the underlying quality of the internet, Kerries has some very insider information on certain massively huge tier 1 providers that suggests that a lessez-faire attitude exists amongst the traffic shaping engineers exists (they are even more 'meh' about IPv6, btw, and won't implement it anytime soon, meaning that 50% of the net's traffic will still be tunneling over IPv4 .. forever), and that other tier 1 providers have similar, degenerate attitudes. Also, wireless is NOT a perfect technology, and is often adding a fair bit of packetloss and retransmissions to every connection going over it.
So remember, boys and girls, old != invalid.
PS. SCTP can be tunneled over UDP~ tildemog~
I don't think I've worked on a network app in the last 15 years that didn't immediately turn off the Nagle Algorithm.