"TCP looks sexy in that I don't have to spend time implementing guaranteed transfer,"
If you're using the Torque Network LIbrary (TNL?) then you don't need to implement guaranteed transfer, as it's already supported.
You could use TNL's UDP support for any type of connection, as it provides reliable UDP.
With TNL you could possibly use one socket for talking to many different other machines? I'm not sure from memory if this is supported.
I'm not sure what your problem is?
TCP / UDP advice
Author
Quote:Original post by stodge
"TCP looks sexy in that I don't have to spend time implementing guaranteed transfer,"
If you're using the Torque Network LIbrary (TNL?) then you don't need to implement guaranteed transfer, as it's already supported.
You could use TNL's UDP support for any type of connection, as it provides reliable UDP.
With TNL you could possibly use one socket for talking to many different other machines? I'm not sure from memory if this is supported.
I'm not sure what your problem is?
No offence intended, but had you read the rest of the thread, you would understood what my problem was. I glanced at TCP/IP because I did not understand the connectionProtocol class in TNL (which handles ACK, notify, etc) and how to use it, and I figured it would be faster to just use TCP than to try something I clearly was not capable of.
---------------------------------------------------------
Looks like I will be modifying NetEvents to not use the ordered class list instead. That way I can use it. :)
I was originally using my own networking library to do reliable transfer over UDP. It was getting to be more painful than fun, though, so I tried switching to another one. OpenTNL was just too complicated for me, and I couldn't find nearly enough documentation. I tried switching to RakNet, which I've felt is, at its core, a fantastic and simple API. It's not as powerful as TNL, but it handles all of the basic features, and it's really easy to grasp the various ways to send and receive data. Plus the creator's really responsive and helpful on his forum. Of course, it also costs $100 to $5000 dollars if you actually want to distribute your game, so, y'know, that might be a factor, too.
Quote:You went with only UDP for your projects, correct?
No, we actually mix. However, we do extensive management of the TCP channel, so that streaming large on-demand asset updates don't interfere with the real-time UDP data (especially important for lower-bandwidth connections).
The primary problem with mixing TCP and UDP (or any two connection-layer protocols, really) is the potential for one crowding out the other in bandwidth-limited situations. In the case of TCP plus a hastily-implemented reliable UDP, TCP will continuously throttle back its own speed until it's stalled. I think that more well-conceived systems such as enet may be better-behaved in this regard, but I'm not sure.
Author
Quote:Original post by hplus0603Quote:You went with only UDP for your projects, correct?
No, we actually mix. However, we do extensive management of the TCP channel, so that streaming large on-demand asset updates don't interfere with the real-time UDP data (especially important for lower-bandwidth connections).
That makes sense. So the actual game (not counting file transfers) use full UDP.
Thanks guys :) This has been very insightful.
UDP + TCP FTW, in most game stuff you run into things that are large and have to be sent, like data tables for viewing a shop in the game or something. UDP is used for everything else, though this might have been already said. However if you never send large amounts of data just use UDP. It's kinda funny how much you can get away with even with packet loss.
Another problem with TCP/UDP is, when on a modem, where a large-size TCP segment will cause excessive jitter for the UDP traffic. For example, if you send 200 byte UDP packets 15 times a second, and a 500 byte TCP packet or two get queued at the head end of the ISP modem, you will see significant (over half a second) jitter in the UDP stream. We solved this by rate-limiting TCP and sending only small packets at a time.
Quote:Original post by MatrixCubedQuote:Original post by SymLinkedHello,
We develop a game where we use UDP for our communication (TNL) and it's wonderfull. I am now toying with the idea of creating another server that the client connects to as well, like a auth server of some kind.
So I ran into the TCP vs UDP dilemma, and quite honestly (after 3 days of research) I still can't decide which one to use.
The auth server obviously will not send packets to clients in quick succession, just occasional CRC/login checks.
TCP looks sexy in that I don't have to spend time implementing guaranteed transfer, which I need. UDP looks sexy in that I can chose whether I want the packet to be guaranteed or not, and that I might save a few bits.
I saw comments in a few places where it was mentioned that TCP/IP is limited in that it opens a socket to each connection and that it would be a huge resource problem for the server when many are open at the same time.
What's so heavy about opening a socket?
I have also heard that mixing TCP and UDP is a bad idea.
You might consider an alternative which offers the benefits of both.
enet is a udp lib.
I do not know why u think mixing tcp/udp is a bad idea?
many mix both.
you might need to send certain packets in the game in order which are time independant and use TCP and the game update using UDP.
I have some free time and did some research on TCP.
well if you really optimize, u can run a gd real time game using TCP only.
u might need to turn off some flags like Nagle's algorithm and it will work.
but in general it is not bad to mix tcp/udp if u divide ur packets and when ur network engine is good enough.
Quote:Original post by SymLinked
So I ran into the TCP vs UDP dilemma, and quite honestly (after 3 days of research) I still can't decide which one to use.
I don't know if this has been suggested before, but I think you should check out this thread. It has pretty much everything you need. Next time, if you haven't already, please check the FAQ of this forum. [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
