REST Protocol verses native Torque 3D
by Scott Peal · in Torque 3D Professional · 11/15/2009 (1:56 am) · 5 replies
Has anyone compare the transport protocol found in the 3D code base verses using the REST protocol? We would be interested in your discoveries.
About the author
Step 1) be the indie, step 2) make enough to buy a commercial license :)
#2
11/16/2009 (12:15 am)
I will sound like a snob saying this, but comparing REST to Torque's networking is like comparing a bicycle to a sports car. They are barely in the same category.
#3
And no, Ben, that is not snobbish at all :)
11/16/2009 (1:48 pm)
Or, to put it like this: There are at least two protocols between you and TCP/IP if you use a RESTful method of communication (not to mention a potential N magnitude increase of translation of data ;).And no, Ben, that is not snobbish at all :)
#4
Actually, this is not completely true. "Torque has elected to build on top of the UDP protocol." - http://tdn.garagegames.com/wiki/TorqueNetworking
Here is a link to the definition of protocol: "Computers. a set of rules governing the format of messages that are exchanged between computers." - http://dictionary.reference.com/browse/protocol
Using a restful interface, which by the way is very much defined with .NET 4.0 WCF and today's cloud computing is by definition a protocol. Granted it is a higher level protocol, but a protocol none the less.
So to repeat the question, has anyone tried to use a restful interface as a transport layer for Torque? We have successfully using XNA, but wanted to get other's thoughts. Why you ask? With many companies starting to block UDP traffic due to DoS and other attacks, combined with faster network bandwidths, faster processors, and cloud computing - may signal the need to start thinking about a TCP-based solution.
11/16/2009 (11:02 pm)
Thanks for all the feedback, however, none of you actually answered the question. I saw no need to provide a link as if you don't know what it is, then you would not be able to answer the question. Quote:Clients maintain an active connection to the servers
Actually, this is not completely true. "Torque has elected to build on top of the UDP protocol." - http://tdn.garagegames.com/wiki/TorqueNetworking
Here is a link to the definition of protocol: "Computers. a set of rules governing the format of messages that are exchanged between computers." - http://dictionary.reference.com/browse/protocol
Using a restful interface, which by the way is very much defined with .NET 4.0 WCF and today's cloud computing is by definition a protocol. Granted it is a higher level protocol, but a protocol none the less.
Quote:comparing a bicycle to a sports carEvery application has different requirements. Tic Tac Toe could use a bicycle.
So to repeat the question, has anyone tried to use a restful interface as a transport layer for Torque? We have successfully using XNA, but wanted to get other's thoughts. Why you ask? With many companies starting to block UDP traffic due to DoS and other attacks, combined with faster network bandwidths, faster processors, and cloud computing - may signal the need to start thinking about a TCP-based solution.
#5
As already pointed out, REST is an architecture, not a protocol.
11/17/2009 (1:59 am)
The main problem with a RESTful interface is the requirement for it to be stateless - this doesn't sit happily with multiplayer games where client state needs to be persisted on the server for interaction purposes. For some games REST is fine, but in general, no.As already pointed out, REST is an architecture, not a protocol.
Associate Manoel Neto
Default Studio Name
Well, that's not how Torque works at all. Clients maintain an active connection to the servers, and both are constantly sending each other data. Clients transmit moves, servers transmit ghost updates (and move ACKs) and both can transmit net events (and the respective ACKs). Each active client is represented on the server via a GameConnection object, which needs either an associated control object or camera object to be able to receive the ghost updates.