Why not support TCP?
by Ahn, Sung Hwan · in Torque Game Engine · 05/27/2004 (12:48 am) · 10 replies
Hi all.
I'm really happy at OpenTNL. But I know the TNL not support TCP now.
How can I support TCP/IP for developing game-server.
Thanks.
- Superahn
I'm really happy at OpenTNL. But I know the TNL not support TCP now.
How can I support TCP/IP for developing game-server.
Thanks.
- Superahn
About the author
Recent Threads
#2
For masively multiplayers, IO completion ports will be used to game server instead of Tnl library.
So now I consider carefully adding udp module in my server-platform or adding tcp module in tnl for clients.
Isn't my idea right?
-Superahn
05/27/2004 (6:44 pm)
It's reason that game server communicate with clients only using tcp.For masively multiplayers, IO completion ports will be used to game server instead of Tnl library.
So now I consider carefully adding udp module in my server-platform or adding tcp module in tnl for clients.
Isn't my idea right?
-Superahn
#3
05/28/2004 (6:15 am)
Ahh. Well, I can't say for sure which is the "best" answer. I think that, with the overhead you will already be incuring for a MM game, it *may* be best to not use TCP since you'll have to have a socket open for every client, you'll have to change that socket each time they switch servers (IE with areas of the world) which is more work on your half. You'll still have to do TNL stuff when you change servers, but at least you only have to do it once. The GDC paper on Tribes networking is a good read, regarding the different types of packets, assured delivery etc. Like I said I don't have an answer I think is 'right' for your case, but I think that, for ease of implementation AND maintnence, I would go all TNL.
#4
05/28/2004 (7:54 am)
TCP works contrary to the fundamental nature of TNL. I suggest you read the whitepaper Pat mentioned, as well as the TNL documentation, so you understand the situation better.
#5
12/27/2004 (7:36 am)
Where can I find the GCC paper on Tribes networking? Tried but could not find it. Thanks!
#6
www.garagegames.com/articles/networking1/
12/27/2004 (8:20 am)
This is the only article I know of for Tribes networking. Hopefully it is what you are looking for.www.garagegames.com/articles/networking1/
#7
- I am wondering if you might be able to clarify this? The majority of MMP games on the market actually use TCP for communication although in some cases like in Camelot you will have TCP communication with unreliable UDP packets for mobile movement.
A few examples of TCP MMP games are World of Warcraft, Ultima Online, Dark Age of Camelot (with the exception of UDP movement packets), Lineage 2.. and the list goes on to I believe almost all of them with the exception of Asherons Call and City of Heros.
04/26/2005 (11:27 pm)
" it *may* be best to not use TCP"- I am wondering if you might be able to clarify this? The majority of MMP games on the market actually use TCP for communication although in some cases like in Camelot you will have TCP communication with unreliable UDP packets for mobile movement.
A few examples of TCP MMP games are World of Warcraft, Ultima Online, Dark Age of Camelot (with the exception of UDP movement packets), Lineage 2.. and the list goes on to I believe almost all of them with the exception of Asherons Call and City of Heros.
#8
I'm not sure where you are getting the idea that many MMP's use TCP as their primary communications protocol--it's actually the opposite. Most MMP's use TCP/IP as a secondary channel, if at all, and use UDP as their primary network traffic.
TCP and UDP each have their advantages, and selection of which to use for which packet type is up to the designer's requirements, but in general UDP tends to handle most networked simulation requirements much better than TCP does. UDP for example allows the player to recover from multiple lost packets much more appropriately than TCP does--in TCP, the "action" on the client's side is pretty much time locked to the lost packets, since guaranteed delivery basically means that even you won't be doing much until the lost packets are re-transmitted and received, while in UDP, the server and the client can both say to themselves "ok, he lost some packets, let's recover more cleanly by just sending him the current state of the simulation he needs to know about".
I'm talking very high level here of course, and again of course you can implement all of this with TCP, but the fundamental nature of the two protocols are different, and in general, UDP makes a lot of sense for many simulation requirements.
04/27/2005 (3:41 am)
@Joe:I'm not sure where you are getting the idea that many MMP's use TCP as their primary communications protocol--it's actually the opposite. Most MMP's use TCP/IP as a secondary channel, if at all, and use UDP as their primary network traffic.
TCP and UDP each have their advantages, and selection of which to use for which packet type is up to the designer's requirements, but in general UDP tends to handle most networked simulation requirements much better than TCP does. UDP for example allows the player to recover from multiple lost packets much more appropriately than TCP does--in TCP, the "action" on the client's side is pretty much time locked to the lost packets, since guaranteed delivery basically means that even you won't be doing much until the lost packets are re-transmitted and received, while in UDP, the server and the client can both say to themselves "ok, he lost some packets, let's recover more cleanly by just sending him the current state of the simulation he needs to know about".
I'm talking very high level here of course, and again of course you can implement all of this with TCP, but the fundamental nature of the two protocols are different, and in general, UDP makes a lot of sense for many simulation requirements.
#9
So say for example if you are in a FPS and you run from Point A to Point B. You hit a spot of lag or lost packets, TCP is going to need to ensure all the packets get through for every spot along that path from A to B and will continue to retry to send/receive the lost packets and your connection bogs down as it does that. UDP on the other hand doesn't care what you lost, just where you are at that moment. So say you lose all the packets between Point A and Point B, UDP will just pop you up at Point B. Yeah it won't look pretty as your icon seems to blink across the map, but it keeps delay issues to a minimum.
Basically if there's any reason that you absolutely must be positive that all client server communication is received you want TCP. If you don't mind missing a few packets here and there you want UDP.
04/27/2005 (7:51 am)
Exactly what Stephen said is why you don't want TCP. TCP wants to ensure that all packets get there, UDP doesn't care. So say for example if you are in a FPS and you run from Point A to Point B. You hit a spot of lag or lost packets, TCP is going to need to ensure all the packets get through for every spot along that path from A to B and will continue to retry to send/receive the lost packets and your connection bogs down as it does that. UDP on the other hand doesn't care what you lost, just where you are at that moment. So say you lose all the packets between Point A and Point B, UDP will just pop you up at Point B. Yeah it won't look pretty as your icon seems to blink across the map, but it keeps delay issues to a minimum.
Basically if there's any reason that you absolutely must be positive that all client server communication is received you want TCP. If you don't mind missing a few packets here and there you want UDP.
#10
What most MMP's do is to implement some form of handling for lost/damaged packets at the application layer that are appropriate for their game. TGE/TNL does as well.
04/27/2005 (8:27 am)
And UDP's RFC also allows you to implement application level processing for lost/damaged packets, while TCP/IP does not give you this flexibility.What most MMP's do is to implement some form of handling for lost/damaged packets at the application layer that are appropriate for their game. TGE/TNL does as well.
Torque 3D Owner Pat Wilson