Reliable UDP?

#1 Actually, it does, if the packets are marked as guaranteed/guaranteed ordered. I'm not an expert on the net code, but I am somewhat familiar with it. In fact, there are several levels of reliability based on the nature of the data within the packets sent.

What specifically indicated to you that it wasn't a "reliable" implementation?

#2 Lines like these:

./engine/core/dnet.h:/// This implements a sliding window connected message stream over an unreliable transport (UDP). It
./engine/platform/platform.h: // Unreliable net functions (UDP)
./engine/platform/platform.h: // App can only open one unreliable port... who needs more? ;)
./engine/platform/platform.h: // Reliable net functions (TCP)

This is me searching for the word "reliable" in header files.

#3 To be fair, engine/sim/netConnection.h does talk about guaranteed events and such. I wonder where do I tell Torque that I only want UDP, though? I specifically don't want any TCP connections.

#4 TGE actually never uses a TCP connection unless you explicitly tell it to.

I think it's a matter of somantics here as well: by definition, UDP as a transport protocol is unreliable, but implementation decisions can allow for reliability requirements once implemented (the protocol leaves reliability to the developer). TGE's network layer does implement reliability by tracking packet transmissions and applying various "missed packet" rules based on the nature of the sent packet.

For example, if the missed packet was a move event update from the server to the clients, it won't retransmit the packet directly, but will send the current updated position at the time of notification about the missed packet. This is so that you don't send a move update packet out of sequence--if they only missed one packet out of a stream, you don't want to send a previously sent packet with the "old" position--the code just sends a current update instead.

Disclaimer: As I mentioned before, I'm not an expert in the net implementation, so while I may be glossing over things or stating something inaccurately, I know the general point is correct.

Does that help?

#5 It does seem that the default netEvent type is guaranteed+ordered. I'llassume that Torque does not use TCP and will go from there.

I really just need to throw strings back and forth but want to use UDP and guaranteed ordered events. If someone could point me to examples I would appreciate it.

#6 --messageClient
--cmdToServer('XXX')/serverCmdXXX() and cmdToClient('YYY')/clientCmdYYY()
--/common/server/message.cs (an entire tagged message system for chat implementation).

That should get you started!

#7 TGE uses UDP (user datagram protocol - Internet standard network layer, transport layer and session layer protocols which provide simple but unreliable datagram services.) Since UDP is send it and forget it, it makes the most sense when dealing with a networked FPS. Any game or application which would depend on data being sent as fast as it possible would utilize UDP.

TCP (transmission control protocol), on the other hand, will verify that data arrived properly before assembling the packet and handing it up to the next layer. Because of this inherent responsibility of the networking protocol, you get what is referred to as a blocking issue. The layer blocks (holds all other processes) until the data arrives. Now you can get around that problem by threading your network "chatter," but the game will soon get out of sync on a noisy network.

TGE is able to utilize UDP like TCP, but it controls if the data is verified and/or resent. Thus, it always gets a packet no matter what. If the data arrives, it is passed up to the next layer. It becomes TGE's responsibility to assemble packets and guarantee that they are in order or that they arrived. Using this method, the TGE is never blocked by the network layer while waiting for packets to arrive. That would slow down gameplay dramatically.

Hopefully that helps to clarify some things.

- Brett

#8 Stephen,

I must be dumb but what are messageClient and cmdToServer? I searched the CS files in the torque distro and the header files as well. Can't find a mention of cmdToServer.

Thanks, Joel

#9 Never mind, it's late and my attention is suffering. common/server/message.cs has it all. thanks!

#10 Brett and Stephen, I apologize for not making this clear in the beginning. I do understand the difference between udp and tcp and it was my understanding that the guaranteed + ordered bit was provided somewhere. I just could not find it. I understand now that reliable and ordered are properties of the netEvent itself as opposed to the connection. Thanks!

#11 You're looking for a function named: commandToServer not cmdToServer. So, you'd see a call like:

commandToServer("TeamMessageSent", %text);

And then the corresponding function on the server would be the name of the command with serverCmd prepended to it:

function serverCmdTeamMessageSent(%client, %text)
{
   if(strlen(%text) >= $Pref::Server::MaxChatLen)
      %text = getSubStr(%text, 0, $Pref::Server::MaxChatLen);
   chatMessageTeam(%client, %client.team, '\c3%1: %2', %client.name, %text);
}

- Brett

#12 While we are on this subject... Is network-layer encryption provided or do I have to do it myself? Yes, I want UDP _and_ encryption.

I used to do it with TCP the same way that SSL does it (don't ask me why not use SSL, it was just so ;)), by first sending the public key to the client, having the client encrypt its block key with the server's public key (asymetric encryption) and then switching to using the block key for the rest of the session.

I suppose I could do exactly the same with UDP but I want to make sure this is not done for me already.

Thanks in advance!

#13 @Brett: thanks for the typo correction, it's been a LONG day staring at code!

@Joel: now that one you'll have to do yourself!

#14 Joel, you may want to take a look at TNL if you are looking for encryption - TNL supports public key crypto and then encrypts the packet stream with a shared symmetric key. All the crypto is done using the libtomcrypt publicly available library. TNL also has some really cool RPC functionality for guaranteed or unguaranteed messages.