Author Topic: UDP only connection  (Read 636 times)

phoenix

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 3
  • Posts: 49
    • View Profile
UDP only connection
« on: April 08, 2017, 11:09:17 PM »
So I am messing around with azure and I am having trouble opening up a tcp port and getting TNet working when I noticed that TNManager.Connect ends up only calling a ConnectToTcpEndPoint

Is it possible to use TNManager to connect to a udp endpoint?

Is it as simple as mSocket = new Socket(tcpEndPoint.AddressFamily, SocketType.Stream, ProtocolType.Udp);

Are there unintended consequences of using the Udp protocol as an endpoint for TNManager?

Is it possible to use TNet as UDP only without any TCP connectivity?

cmifwdll

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 149
  • Posts: 285
  • TNet Alchemist
    • View Profile
Re: UDP only connection
« Reply #1 on: April 09, 2017, 02:37:31 AM »
I'd say TCP is almost necessary for TNet's model.
Let's say you die. You call an RFC "RegisterDeath" notifying the other players that you died. With UDP, packets aren't guaranteed, so it's very possible this RFC simply never reaches the server. So every other player sees you as alive. You can imagine the bugs this might introduce when your dead-but-not-dead player starts the respawn process.
You would need to add a "receipt" to every network action. You would have to keep sending your "RegisterDeath" RFC in an infinite loop until every client responds with an "AcknowledgeRegisterDeath" RFC. Do this for every single network action (including the entire Connect process!) and you see how valuable TCP is :)

The reason other games are able to get away with using UDP is because they're server authoritative. The server controls the game, so if a packet is lost in transit it doesn't matter much. The server will keep sending out world updates and the client will just see a little stutter from the lost packet.

TNet does support UDP with the tno.SendQuickly function, but I imagine it's mostly intended for frequently sent or unimportant RFCs like movement. The connection process, as you've seen with ConnectToTcpEndpoint, is built around TCP (in fact, tno.SendQuickly isn't even available until after you connect and register yourself for UDP).