[quote]Light cycle updated the client dependant on their ping. For most people that ended up being 25 updates a second. The message’s are in a fairly flagrant manner, so no clever encoding. Update messages were sorta 2 doubles + int + int(MessageID) + int(CycleID). The strategy for guaranteed delivery was also sending ACK messages on top of this.
[/quote]
25 updates per second??? For Tron?? I have a flightsim that comes along with 1-2 updates per second! What do you send there? TCP transmission is guaranteed, so you only need to send when direction changes. Tron is very hard to do on the net I think for its highly synchronous gameplay. But flooding the line won’t help to reducde latency.
??
The ACK you send only for UDP, right? What happens if the ACK doesn’t get through?
Currently Tron sends the current position of each cycle.
If you only send direction changes how do you synchronize multiple clients to ensure changes the right time? Do you time stamp the changes or something?
If an ACK doesn’t get through then the resend occurs, which the client at the end will recieve and resend the ACK.
If you use TCP, how do your stuff cope with the delay of reciept. In tests I found this could be quite a problem even on a local network.
I think Tron is extremely difficult in terms of a network game bc. motion is highly limited (always strictly straight in one direction, maybe even discreet on a grid) and is very fastpaced. If the ‘remote’ vehicle is wrong once, there’s no way to interpolate towards the correct position. [more to come, must play Q3A NOW!]
Agree, Tron was annoying case, but its the same for some other types of games, MMORPG for one (see http://pondering.newdawnsoftware.com, got to get my plug in ).
However, the only reason I can really understand for using TCP is the simplicity of the related API. You could argue there was a bandwidth saving, and I’m not going to say its not without running some tests
I at least found with a little work on a wrapping API for UDP I can use UDP as a stream protocol simply without undue effort.
[I’ll post the current state of API on the newdawn site, I’m afraid it may not be the most well documented of source]
I’ve seen this come up several times on various games-developer (pro and hobbyist) mailing lists. I’ve also talked about it with network-protocol researchers and people working in massive scale environments.
The person who warned “many don’t really know what they are talking about” was giving very good advice. The X-wing-versus-tie-fighter article is really embarassing; the author shows how stupid and lazy they were not to bother learning about TCP and UDP before they started using them. Many of their mistakes are equivalent to never using the java.util.Vector class because you didn’t realise it existed, and hand-hacking from scratch dynamic arrays every single time you need one!
Main differences:
TCP: Guaranteed delivery, in-order-arrival, connection-based, compressed automatically on slow connections (99% of 56k modems do significant TCP compression - but you don’t notice if you download a ZIP file; you do when you download TXT files).
UDP: One-way-only (cannot respond down the same channel), connectionless (slight reduction in overhead), does IPv4 broadcast
Gotchas (PLEASE don’t ignore these, they are the cause of the majority of TCP/UDP woes in games development!):
“Guaranteed delivery” is absolute hell to implement properly. I’ve seen dozens of “UDP with guaranteed delivery” schemes which didn’t work properly (in fact, note: JDK 1.1.x RMI was at one point completely broken because it included a naive implementation of this - RMI couldn’t be used in large production environments because it generated so many colliding packets that it brought down the LAN. Yuk. Unforgivably stupid by a company with such a strong heritage in networked computers).
Connection negotiation and maintenance is also not trivial.
The TCP standard implementations have a complex state-model (FSM). From memory (but it’s been a looooong time since I looked) there are 22 unique states that a TCP system can be in. Most of those are to do with guaranteed delivery and connection handling (the two bits people most frequently try to add to UDP). Sun’s implementation broke (we think) because they “forgot” to include the “random-delay backoff before re-transmit”.
Compare this with the (again from memory) four states of UDP, and you can see there is a LOT of work if you want to achieve the benefits of both.
TCP is normally as fast or faster than UDP. Normally, UDP is very inefficient and wastes bandwidth (no, seriously), mainly because of small packet-sizes. For VERY small packets, UDP is more efficient, because it has a much smaller constant-overhead-per-packet. From memory, the numbers are something like 15 bytes overhead per-packet for UDP, compared to about 30 for TCP. But, TCP packets can be MUCH larger, so that 30 bytes CAN get sent much less often.
Even games sending lots of messages per second may find TCP is fundamentally faster (but then they get bitten by the next problem, sooner or later). If you experiment on your LAN, you can often get TCP running faster; but don’t bother - the next problem will screw you if you deploy your game like this.
The vast majority of games developers only have one problem with TCP (but often mistakenly believe they need more!). They need to remove the “in-order arrival”. Whenever you hear about “TCP is sloooow” or “TCP has high latencies”, you are listening to someone who is 99% likely to have bitten by this problem but not understood it.
The problem is that if you send 30 packets, and the fifth one gets dropped, but packets 6-10 arrive OK, your network stack will NOT allow your application to see those last 5 packets UNTIL it has received a re-transmitted packet 5.
Lastly, there ARE alternatives to TCP and UDP. Not surprisingly, since almost every game finds that neither is really good enough (the games that just go TCP only suffer weird stuttering, the ones that are UDP only often get players freezing, or their guns not firing because of lost packets). The last time I looked, ENet seems to be the best widely/freely available implementation around, but people have suggested several others to me, including:
RAKnet (sp?)
RDP (covered by an official internet RFC)
There are a LOT of commercial implementations of “the best bits of UDP and TCP, implemented efficiently”. Most are as cheap as they should be (tens of dollars) given that so many companies have written their own.
There are SO many implementations lying around that unless you already have one, you REALLY shouldn’t implement your own - there’s no excuse (unless you enjoy pain? ;)).
[quote]Main differences:
TCP: Guaranteed delivery, in-order-arrival, connection-based, compressed automatically on slow connections (99% of 56k modems do significant TCP compression - but you don’t notice if you download a ZIP file; you do when you download TXT files).
UDP: One-way-only (cannot respond down the same channel), connectionless (slight reduction in overhead), does IPv4 broadcast
[/quote]
When you say “one-way-only” you make it seem like a negative. There’s just no concept of a channel to respond down. Just a nit-pick…
yes and no. if you need a generalized solution that you can use in all kinds of situations, it’s going to be difficult to beat TCP. on the other hand, the specialized conditions a particular game (or class/genre of games, perhaps) can be designed for, IMO.
[quote]2. Connection negotiation and maintenance is also not trivial.
The TCP standard implementations have a complex state-model (FSM). From memory (but it’s been a looooong time since I looked) there are 22 unique states that a TCP system can be in. Most of those are to do with guaranteed delivery and connection handling (the two bits people most frequently try to add to UDP). Sun’s implementation broke (we think) because they “forgot” to include the “random-delay backoff before re-transmit”.
Compare this with the (again from memory) four states of UDP, and you can see there is a LOT of work if you want to achieve the benefits of both.
[/quote]
Just because TCP has 22 states does not mean that another go at guarantees needs it!
UDP and TCP both use the same type of packets. When TCP is slower (which is farily often), it’s usually because of its various net congestion algorithms – which aren’t really a good thing for gaming. And UDP is no more or less efficient than TCP.
agreed…
These protocols, unless they are running at the OS level, are not necessarily going to be running any better than something you roll yourself. And chances are, they probably aren’t optimized for gaming.
[quote]There are a LOT of commercial implementations of “the best bits of UDP and TCP, implemented efficiently”. Most are as cheap as they should be (tens of dollars) given that so many companies have written their own.
There are SO many implementations lying around that unless you already have one, you REALLY shouldn’t implement your own - there’s no excuse (unless you enjoy pain? ;)).
[/quote]
If you know of anything that is particularly well done for gaming (and is implemented in Java!) I’d love to hear about it.
Sorry - I was trying to make it clear for people new to this one of the practical differences between “connection” and “connectionless” protocols. You’re absolutely right it’s not a negative - I didn’t mean to imply that.
I didn’t say it explicitly, and logically you’re correct, but in fact - those 22 states are really only there because they are ABSOLUTELY necessary to get a decent, working implementation (perhaps a few can be omitted - I’ve tried but couldn’t get it down to fewer than about 18 ). TCP is annoyingly complex to implement - it was obviously designed with the hope ofbeing as simple as possible, given that it has to be implemented in hardware all over the place, running at 10’s of Gigahertz. There’s very little unnecessary overhead. I would be very surprised to see people come up with a design that is significantly less complex and still does the job - anyone who is uncertain should have a look at the RFC’s, and the block diagrams (don’t have links to the block diagrams, only my own printouts, but they can be found in most good TCP/IP books), and see for themselves; once you fully understand it, you’ll see that most states are necessary :(.
UDP and TCP do NOT use the “same type of packets”. The packets they do use are both embedded in the same lower-level-protocol packets (IP). UDP’s major bandwidth efficiency savings come from having a packet with smaller header. If you have to send many packets per millisecond, then it can make a big difference (12 bytes saved per packet).
Yeah, the “standard” net congestion algorithms are indeed crap; but there are much better ones available. Tiny downloads for most OS’s - e.g. TCP Vegas (extensively linked to on Google). But sadly these are of little use to games developers, unless you roll your own UDP + bits-of-TCP, and copy the Vegas implementation into your congestion-control part (instead of using the standard TCP congestion control).
Rubbish; I wouldn’t mind - but I explicitly explained this above. I did make a stupid mistake in claiming that UDP payloads were limited at a smaller figure than TCP - putting me in the same category as all the others who spout ill-informed stupid mistakes when talking about this stuff :). Whoops:
UDP and TCP are both only limited by the IP max packet size, which is (216 - 1) bytes. However, on most links between hosts/routers, there is an MTU (chosen by the physical devices) which is often much lower. Ethernet is typically 1500 bytes. TCP can automatically discover the MTU and be more efficient. UDP doesn’t bother, and tends to waste bandwidth - either because you send small packets (very wasteful) or because the ones you do send are too big, and cause fragmentation (requires extra delay to negotiate, and extra packets).
If you are on a 1500 MTU link (i.e. typical ethernet), and you send ANY UDP packet of size less than 730 bytes (i.e almost 1kb per packet), then you are “wasting” bandwidth compared to TCP (which would automatically be using about 1460-byte payloads). But if the MTU changes, or the link is a modem (typical MTU’s as low as 300), then if your UDP packets are larger than about 550 bytes, you again are wasting bandwidth compared to TCP (because each fragment incurs an overhead of an additional 20 bytes).
You’ve also spurred me on to dig out the figures :).
TCP states: 22 (CLOSED, LISTEN, SYN RCVD, SYN SENT, ESTABLISHED, FIN WAIT 1, FIN WAIT2, CLOSE, TIME WAIT, CLOSE WAIT, LAST ACK) - 11 each on local and remote, and they change semi-independently.
UDP states: 2? (sent and received? there’s no ACK, so…)
TCP header: 20 bytes.
UDP header: 8 bytes.
However, they do WORK. Most UDP+bits implementations do not work - they kind of work, or work in 95% of situations, and then go titsup the first time a cable-modem user talks to an ADSL user, or they crash once every 10,000 packets, or etc. Or (as in SUN’s RMI) they start chain-reactions leading to packet-storms, and can bring down a LAN segment! The problems are nearly all subtle, all special cases. It’s really hard being sure you’ve taken account of every situation.
I’d just like games developers to think twice, then think again, and finally think twice more, before rolling their own…
That said, I agree with you in spirit: most games companies have so far just rolled their own, and not released them. I’d really like to see a common standard (RDP has already stolen the name “Reliable Datagram Protocol”, AFAIAA). However, there are quite a few commercial offerings that include java versions (or claim to “very soon now”).
I’ll admit I’m not an expert on networking but I’ve observed the following things to be more or less true.
As I see it minds many times smarter than mine have spent many more hours figuring out how to make TCP faster/efficent/better than I can do in years. I don’t have false hopes that I can somehow do better than the people who’ve tried before me.
I don’t see why people don’t just use one TCP connection for reliable packets and one UDP “connection” for packets that don’t need to be reliable. With the exception of running out of file handles it seems like the best of both worlds. IMO anything else is reinventing the wheel.
As I recently learned at work not fully understanding the interface you are programming for can lead to horrible results. In my case it was a web application running out of file handes because I thought I’d be smarter than the lib I was using and cache connection objects.
Familar with the problem where cable modems can’t download worth a damn when you’re saturating the upstream? Backing off the upstream even 1% really improves downstream performance. Developers seem to expect 100% throughput and refuse to accept that 99% throughtput may actually perform many times better.
I think the point here is that we’re talking about gaming. You can be as bandwidth concious as you like but in the end if the user presses a key (which needs to send a packet) the difference of a few milli-seconds can make the difference between playable and not playable.
From talking to a few more independant sources (read: work collegues) the real disadvantage of implementing a TCP like protocol over UDP is the likely bandwidth usage. TCP for the right use in other words is great, I’d just argue real-time gaming comms isn’t it. If I read the above right, I’m just agreeing
As to implementations of guaranteed delivery by other developers not being any good, I’m slightly bias here. However, I really do get tired of hearing this same old story, “someone else wrote one so its bound to better than anything I can do”. Generally the people who write these things are software engineers just like us? In the case of TCP, its had years and years of testing, but it was designed as a general purpose stream protocol. Thats not nessercarily (spelling?) the best thing for gaming circumstances.
As for the header size - one thing which makes it more complicated is that TCP/IP is often optimized for modem links. If enduser modem is weakest part of connection (and it often is), TCP/IP can be actually better per-packet (ignoring packet loss at the moment) - I think that optimized header is around 6 bytes then.
I do not think that 8 versus 20 bytes figure is fair. You need to take IP header into comparison - it takes 20 bytes itself. So it is at least 28 versus 40. You also get low level header, but it changes from network to network - but it will be again in 5-20 byte size.
Trick is, that 6-byte figure for TCP/IP over modem is total figure - so we are talking about 6 bytes for TCP/IP versus 28 bytes for UDP…
As for the debate itself - I think it is easiest to look at successful games. Unreal, Quake, Tribes - all these engines need close to real-time updates and all use UDP.
At the moment I’m betatesting certain space game, which uses TCP/IP for connection. But this is no-arcade, third view, 1 position update per second, lag for 5 seconds and nobody cares kind of game.
Can you give me examples of really fast paced, sucessful game, which has used TCP/IP for network communication ?
Isn’t a vonJacobson optimized TCP header on a dialup line going down to 3 bytes? Anyway, this doesn’t matter…
I’ve always been a TCP advocate here and I feel very comfortable with blahblahblahh’s statements.
Besides the technical bandwidth/latency issues that are based on the resp. protocol itself (header size, vonJacobsen, handshake,…) I’d like to emphasize on the algorithmical issues. And these are for performance, latency tolerance and beauty of design!
If you hammer out 25 msg/sec anyway, for sure this will be better done with UDP. I’d call that a brute-force approach. The information transmitted is highly redundant and it has to be, bc. you cannot make assumptions on what the other side received.
OTOH, the 1-2 msg/sec I talked about are possible ONLY under the assumption that delivery is guaranteed. The messages are not redundant due to an algorithmic approach (dead reckoning up to the second derivative in time).
Although the messages are quite rich of information and therefor quite big, the saving in bandwidth against the brute-force approach is enormous.
By using a suitable gameplay (this is important when deciding to make a network game!! Avoid Tron.) and a smart deal with a distributed timebase, the approach also is latency tolerant.
Eat shit!! Millions of flies…
And it depends. Unreal, Quake … all FPS, very fast, very inexact … and they all suck playing on the internet if the line is only a bit less than ‘excellent++’. They are LAN games. Brute-force.
CS is highly latency dependant and asymmetric - very annoying.
WarBirds, one of the online action games pioneers, goes for TCP AFAIK. 200 players on a server - no problem. And no need for a 30ms ping.
Success of a game does not say very much on the quality of the underlying technology. And that’s what we are talking about here?
I myself like to use millions of flies argument - but I use it mostly to note that it is not important what common people do. But are you suggesting that Carmack/GarageGames/Unreal team etc are just misguided flies ?
I will not agree with you that excellent line is needed. I often play Americas Army (it is based on Unreal). Unfortunately most of servers are in US, so I have around 300-400 ms ping and 10-20% packet loss. And I’m perfectly able to compete with other people in most sitations (except jump-from-behind-corner-you-are-dead-in-200ms case).
I’m not able to comment on WarBirds case - I have not played it - but I believe you that they were able to manage it decently with TCP/IP. More ‘inertia’ avatar has, more acceptable TCP/IP is.
TCP/IP is a lot more simple. Less places to get things wrong. You can focus on logic of game, instead of trying to reimplement reliable messages on top of UDP. But I still claim that there is certain subset of games which are playable over internet with UDP and would not be playable with TCP.
As for the Tron game - I think it will be laggy regardless of protocol. You need exact path for each player (not only latest position to which you can interpolate), and tiny fraction of second latencies would literally kill players when running head to head.
When considering the tron game I did think about doing stuff where the bike keeps going in one direction until the server tells it otherwise.
However, the game was really a test platform for trying out networking code (and Java3D at the time). I was really more concerned about the MMORPG I’ve been playing with. In the case of someone running around a map I’m not really sure how else to implement the comms. I actually be quite interested in any ideas?
At the moment the only way I can think of is the “brute” force approach to get any sort of decent response. Just send a message if the particular player/AI has moved every so many millis.
I did consider:
Sending a message when the client starts moving, stop moving and changes direction. But the system would still have to support people running in circles (as people on MMORPG so often do).
My main concern is the responce between one player seeing another players actions.
[quote]But are you suggesting that Carmack/GarageGames/Unreal team etc are just misguided flies?
[/quote]
For sure not. But I don’t trust them much when talking about networking and some other things. For I’ve been in the business for a while, I’m very suspicious about what game coders claim … :-[
I hope I didn’t say anything against that.
Just saying that Quake uses UDP so UDP is better for games - thats a big mistake.
It depends how do you plan to control avatars. If we are talking about mouse-click on target, then just transmit current position + destination each click. If you want to have some kind of full control like Tomb Raider, situation is a bit more complicated - but with classic MMORPG you are in very good situation - there is almost none arcade skill involved. This means that one person seeing other person one meter from it’s real position will not cause you any problems.
For non-arcade MMORPG, I would certainly suggest you to use TCP/IP. Most data has to go through reliable route (all events, trade, chat messages) - most of it even with correct order. You can consider adding second UDP connection for some other data - but I really doubt it will get you much.
Now, as far as actual data to send is concerned… I think this is one of last places where you count every byte, like in programming old Atari games. With guaranteed TCP/IP you have a bigger field for being smart - you can for example transmit delta of position encoded in some way making small numbers shorter.
I know that you would like to get as real time updates as possible. But as long as life of player is not dependent on few degrees of aiming line or fraction of second timing when trowing cooked grenade, sticking to TCP/IP will save you many worries.
Some name dropping here (please forgive, I feel I must make sure those who made it happen get proper credit) –
The previous posting stating that ‘vonJacobson’ who is really “Van Jacobson” did enable PPP link to use TCP header compression. I worked at LBNL shortly after I worked in the game biz, not in the network technologies group but I did get to know them reasonably well (http://www-nrg.ee.lbl.gov/). They were incredibly influential in the network world, the folks who made ‘traceroute’, ‘tcpdump’, and ‘libpcap’, and hundreds of low level optimizations to IP stacks and tools against TCP in the 90’s. Let me begin by saying that Van Jacobson is an incredibly brilliant man and did a lot of amazing and unimaginable things, he lead that group (I cannot give him the credit he deserves), however the TCP header compression was intended for very slow point-to-point links mostly which are disappearing every day and those that are not are out-optimizing his compression (e.g everyones compressing streams these days).
Back into the UDP v. TCP argument – In the late 80’s (I’ll call this the pre-quake era) everything was IPX(Novell) , but there was some effort in trying to figure out what worked being converted to TCP/IP. I was fortunate enough to work with a very brave, ingenious, and adventurous lot that were trying to make games playable on the Internet – everything was TCP then. Back in those days when one person lost the connection even in a game of backgammon, the whole game crashed (lockstep).
Later, a few innovative and ingenious souls started to realize that the problem was not nature of the network but how they were looking at the network. I personally think of Bill Lipa who was the Architect at TEN, but Quake came out a few weeks after TEN did Duke Nukem in UDP, so I’m not sure if it was Bill Lipa or John Carmack who originally thought of it first (I know I’m biased since I worked at TEN in those days, but Bill Lipa was a network proramming guru while John Carmack was a god, but mostly in graphics and non-networked game stuff).
I have to simultaneuously agree and disagree with ’ blahblahblahh’ . I’ve not read the X-wing-versus-tie-fighter article, but I have to state quite bluntly, use TCP until you understand whether to use UDP in place of TCP. There is quite simply no reason to blindly assume you will get better performance out of UDP than TCP, and using UDP will make things much more complicated.
“Guaranteed Delivery”
Agreed, it is generally NOT worth doing on your own - if you don’t understand this please accept this as fact! Many, many really smart people have spent half of their lives on this and only gotten tiny advancements! If its critical your packet gets there then use TCP, and focus on your game design.
“Connection negotiation and maintenance is not trivial.”
Agreed. Again people have spent half of their lives on this and gotten tiny advancements. Save yourself the grief and accept this as fact! Unless you want to dedicate your life to a network protocol stack, again a reason to use TCP.
"TCP is normally as fast or faster than UDP. "
Heres where I disagree, this depends largely on whether you are measuring as ‘fast’, latency or bandwidth.
“Normally, UDP is very inefficient and wastes bandwidth”,
True UDP wastes bandwidth, but its in trade for latency. If the raw packet delivery is more important than the sequence or state, and the game itself can deal with these factors on a frame-by-frame basis then what a great place we’ve gotten to. The fact is in some games its important, in others, its not.
"The vast majority of games developers only have one problem with TCP (but often mistakenly believe they need more!). They need to remove the “in-order arrival”. “Whenever you hear about “TCP is sloooow” or “TCP has high latencies”, you are listening to someone who is 99% likely to have bitten by this problem but not understood it. The problem is that if you send 30 packets, and the fifth one gets dropped, but packets 6-10 arrive OK, your network stack will NOT allow your application to see those last 5 packets UNTIL it has received a re-transmitted packet 5.”
Agreed, a single retransmitted packet can seem tragic for a developer trying to make their game playable across the internet. Which often makes developers inappropriately reach for UDP, thinking it will fix their problem and usually it will not. But there is something beautiful to the idea of being able to drop packet ‘5’ and proceed that seems appealing.
"Lastly, there ARE alternatives to TCP and UDP. Not surprisingly, since almost every game finds that neither is really good enough (the games that just go TCP only suffer weird stuttering, the ones that are UDP only often get players freezing, or their guns not firing because of lost packets). The last time I looked, ENet seems to be the best widely/freely available implementation around, but people have suggested several others to me, including: RAKnet (sp?), RDP (covered by an official internet RFC)
"
Ok here, fully disagree. Random replacements for to on top of of IP seem to invoke the same arguments you were posing earlier - working against your initial premise. I would say quite simply use TCP for reliable delivery, use UDP where latency is at a premium.
[quote]I would say quite simply use TCP for reliable delivery, use UDP where latency is at a premium.
[/quote]
Nail on the head here, as far as it goes, what about when you need reliable delivery in a situation where latency is at a premium??
[quote]1. “Guaranteed Delivery”
Agreed, it is NOT worth doing on your own - if you don’t understand this please accept this as fact! Many, many really smart people have spent half of their lives on this and only gotten tiny advancements! If its critical your packet gets there then use TCP, and focus on your game design.
[/quote]
I got to disagree here, I agree that for a generic case it might be non trivial, but if you are writting something specific on top of UDP you can make is as complex or as trivial as you like, at the most trivial you send the message with a sequence id, if you don’t get an ack back, resend it.
[quote]2. “Connection negotiation and maintenance is not trivial.”
Agreed. Again people have spent half of their lives on this and gotten tiny advancements. Save yourself the grief and accept this as fact! Unless you want to dedicate your life to a network protocol stack, again a reason to use TCP.
[/quote]
again, if your writting something specific you probably don’t need all of the connection states, maybe 4, ‘i’m trying to construct the ‘connection me message’’, 'ive sent a ‘connect me message’, ‘i’m connected’ (received the server responce), and some kind of error state, to say it all went horribly wrong
Completely agree about UDP being a bandwidth waste and TCP having latency problems.
[quote]The problem is that if you send 30 packets, and the fifth one gets dropped, but packets 6-10 arrive OK, your network stack will NOT allow your application to see those last 5 packets UNTIL it has received a re-transmitted packet 5."
[/quote]
the more often hit issue is more likely to be a buffer size one, a game update message is for example 100 bytes, my tcp stack size is 8k, so the message won’t get sent right away, likewise on the receiving end.
There is also the point that TCP is presented as a stream of data (what it’s designed for), where as UDP is datagrams, so if what i need is reliable datagrams then i should be using UDP plus a bit of roll your own for the reliability side.
These comments are my observations, and if there are any reasons why these don’t hold up other than ‘this is the way it’s always been done’ or ‘because I told you’, then i would be interested to hear them.
Generally I live by the philosophy of ‘not reinventing the wheel’, if you really understand TCP, have done all your proper tuning to how you are using TCP, and realy REALLY understand what your doing then by all means make a UDP implementation. Its no walk in the park and you WILL spend a great amount of time trying to debug and make it work properly and you could still wind up with something that is effective as well tuned TCP.
This is quite simply not true. There are congestion control mechanisms in most TCP stacks such as the Nagle algorithm , it IS the default behavior to use this because it reduces overall bandwidth utilization. Those algorithms are easily turned off.
Let me say straight forward and bluntly your statements are a clear indication that you do not understand TCP enough and you would likely spend a inordinate amount of time reinventing the wheel and would likely still not have any better performance.
[quote]Its no walk in the park and you WILL spend a great amount of time trying to debug and make it work properly and you could still wind up with something that is effective as well tuned TCP.
[/quote]
We wrote a number of test cases of the period of a couple of days using different message sizes and TCP settings, and couldn’t get decent performance. Our first stab at implementing some UDP addons (Connections and delivery options) took a little over a day, we have just discovered a couple of bugs, but even now, we have something in UDP that far out performs the TCP options we tried. Using a 100mbit switched network we sometimes had messages that took 800ms+ to travel, we now rarely get messages that take more than 16ms.
we havn’t sped the network up by 5000%, just the worst case, and the ‘normal’ case is a faster responce time.
[quote]Let me say straight forward and bluntly your statements are a clear indication that you do not understand TCP enough
[/quote]
The fact that we wrote a UDP wrapper that works in less time that it took us to investigate some TCP options suggests the UDP option in our case isn’t that complex to write.
I’m not trying to say that UDP is the best way, just put forward our observations.
Did you say its faster for you to spend “a little over a day” making your own than finding out what options you can use to tune TCP? Hey by that same logic you should write your own database, configuring and using a canned database like MySQL can be diffcult. I don’t know about you but I can find dozens of articles that talk about optimizing TCP performance by spending 5 minutes googling.
Also expect to spend a bunch more time when you use that thing in a real situation (like inside your app across the internet cloud).
).