[MUD-Dev] UDP vs TCP for MUD/MMORPG project.
ceo
ceo at grexengine.com
Thu May 15 10:00:43 CEST 2003
Crosbie Fitch wrote:
> From: Jason Slaughter
>> Is this true??? Is UDP really that big of a problem? It seems
>> like scare-mongering to me, or that people are just so used to
>> TCP that they don't know any different... but my technical
>> knowledge of the subject isn't great (I am doing this as a
>> learning project), so I could be totally wrong. I would greatly
>> appreciate people's advice!
> Abstract the characteristics of as many communications protocols
> as you have time for (don't forget variations and
> hybrids). Implement a few of them (the easy ones). Upon that
> glorious day in the future when you need to optimise, install
> performance monitoring to correlate measurement of each protocol's
> real characteristics. At run-time continuously ensure that the
> protocol most closely meeting your application's required
> characteristics is the one currently selected. Probe alternate
> protocols in the background (catering for
> interdependencies/interference). Don't thrash though. And
> remember, one of the protocols is incommunicado - don't forget to
> detect it, or when other protocols appear very similar to it.
No, that is a bad idea. If I may be excused for a simplistic analogy
:), you are suggesting that the poor guy build his first house
without learning the difference between brick, wood, stone, and mud
as house-building materials.
It's good advice you give ... if it were to someone who already
understands the differences, and can make a reasonably informed
choice; I think you are essentially saying "there's no substitute
for experience", and "don't get obsessive about one small piece of
the puzzle" ?
Ryan Arthur wrote:
> Research links:
> http://wand.cs.waikato.ac.nz/wand/publications/jamie_420/final/node1.html
> http://www.daemon.org/tcp.html
> In the end for a MMOG-like game as EQ I'd rather go with UDP,
> however for a text-based MUD TCP is it. If you optimistically plan
> to have over a few thousand people I would suggest UDP.
Anyway, Jason, for more details, I'd suggest you also check out the
following thread:
http://www.javagaming.org/cgi-bin/JGOForums/YaBB.cgi?board=Networking;action=display;num=1046872611;start=15
...that links to page 2, which is when I waded in with a summary and
comparison of UDP and TCP specifically for game development (I was
posting as blahblahblahh). Warning: It's slightly dumbed-down for
the audience on that site, that includes a lot of newbies. I also
made a some silly mistakes - most of them I corrected (or other
people pointed out during the thread :)), but there may be some
still in there.
Pages 3 and 4 also have some good meaty discussion in them and are
worth reading; page 1 had lots of opinions by people who didn't
really know what they were talking about, so probably not worth
looking at.
Note to JC: It might be a good idea to copy/paste the forum thread
in here, since the javagaming website is only a "temporary"
site. However, my attempts to cut and paste produced a monstrously
long email, with no explicit quoting (because of the way the forum
works), which was almost impossible to read :(.
Adam M
<EdNote: I happen to be waiting for a phone call (we're in the
contract signing and final negotiation brinksmanship stage), so I
have a minute. Brief notes on such copying: Text mode browsers are
your friend for getting "clean" text copies of sites. Favourites
here are w3 mode under XEmacs, w3m, and lynx (in that order).
Another useful trick is using print-preview (or print-friendly mode
if the site offers that) which typically auto-strips all the banners
and framing cruft. None are perfect for posting to lists. You have
to do the cleanups manually. I have some practice at this simply
because I've done it a bit. You can practice too. Its not hard,
merely tedious. I also recommend a good editor with decent undo
(for iterative cleanup-testing) regexp and macro support. Thread
follows with some minor formatting cleanups. I've manually fixed up
the quotes (fairly simple regexp macro work), but may have
mis-quoted some of the multi-paragraph quotes. If I did, please
email me and I'll fix the archives.>
--<cut>--
Title: UDP Vs TCP/IP
Post by simpleton on Mar 5th, 2003, 8:56am Hi,
I'm trying to network two applets (embedded into applications, i
know you can't network applets), and i was wondering which would be
the better option - UCP or TCP/IP?
I know UDP just keeps firing out packets, and doesn't need any
recognition of packet reception, the game is a boxing game - so it
has to be as close to real time as possible.
any suggestions or tips would be greatly appreciated!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 5th, 2003, 9:44am
Very different opinions on that and no only true answer. This
problem also has some dimensions to consider.
If you can miss messages, UDP is fine. If you want to make sure that
the remote player also hits when your local player hits, TCP is the
easiest solution to have.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by leknor on Mar 5th, 2003, 9:50am
The advantage of UDP over TCP in the context of a game is you want
to be moving the gameplay forward at all times. With TCP if there is
a problem in the delevery of a packet the TCP stack will hold things
up and retry the missing packet which will cause your game to
pause. With UDP packets are sent and there are no guarentees on the
order they are received or even if they are received.
When writing a UDP protocol you need to take into account that you
really don't know what came before or what will come after. So a
packet to the effect of "move one unit to the left" is a bad idea
because if the player moves to the left 5 times but only 3 packets
make it then the other client will think the player is in a
different spot than the local client. A more robust UDP protocol
would be something like "at time 123 player 1 was at x=10 y=15 and
was moving left at 1 unit per tick". This way you know when a packet
was sent in case they arrive out of order, you know where the player
is/was at the time so there is no confusion about location, and you
have enough info to predict the future location if future packets
get lost or maybe the current location if the packet was slow
getting there.
I'll admit I'm not a protocol design expert so I hope I didn't miss
anything.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by simpleton on Mar 5th, 2003, 10:56am
thanks a million, i appreciate the information, and i was kinda
coming to the conclusion that TCP would be the better option!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 5th, 2003, 11:19am
Very wise. I use TCP only.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by abies on Mar 9th, 2003, 8:32pm
Please abstract your network code as much as possible - I'm not just
talking about actual byte access, but even some game-related
logic. While TCP is a lot easier to use, net is full of extremly
laggy projects which was tested on local net and then released into
the wild without really checking if they work over the ocean.
So start with TCP (you will probably not be able to manage UDP at
start) and then ask Japanese and Peruvian to test it on server
running in Europe during peak hours. Then please read
http://www.gamasutra.com/features/19990903/lincroft_01.htm "The
Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter"
I especially like the sentence "TCP is evil. Don't use TCP for
a game. You would rather spend the rest of your life watching
Titanic over and over in a theater full of 13 year old girls." :)
TCP is certainly acceptable solution for small scale game
project. If we are talking about 2-person boxing game, no
ladders/competitions, no big money involved - TCP will cut your
development time tremedously.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 10th, 2003, 3:56am
on 03/09/03 at 20:32:21, abies wrote:
> While TCP is a lot easier to use, net is full of extremly laggy
> projects which was tested on local net and then released into
> the wild without really checking if they work over the ocean.
But this holds very well for UDP things too!
> Then please read
> http://www.gamasutra.com/features/19990903/lincroft_01.htm "The
> Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE
> Fighter"
Read it - but don't blindly believe it! I've seen network coders in
games business at work .... sometimes they had very strong opinions
that not necessarily were backed up by a corresponding know-how! I
don't say the XvT guys are of that kind, but be critical!!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by markuskidd on Mar 10th, 2003, 4:20am
what i'm working on right now (and this is hardly original) is a
reliable layer on top of UDP. that way, when there messages i don't
need to guarantee will arrive, i can have the advantages of UDP -- i
can fire and forget. when i need to make sure things get there, it
won't bog down the speedier traffic and i can count on it eventually
getting where it needs to be. other developers have taken this path
in the past and i don't think it's going to be terribly difficult to
get up and running. to get the most out of the reliable messaging,
some tweaking and performance tuning are definitely going to be in
order, but there are plenty of examples out there (including TCP)
that we can probably borrow from in order to maximize efficiency.
if this all comes together and is useful, the code will be open
source so everyone will be free to use it, chuckle at it, etc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 10th, 2003, 4:59am
Looking forward to see it! Esp. if it were transparently embedded
into the NIO package ;)
I definately need guaranteed transmission. IMHO thats the only way
to be able NOT to send redundant data and thereby saving *very much*
bandwidth. I could be able to give up the streaming characteristics
and sometimes even to drop so far undelivered messages in case of
new ones available.
I would be interested to know where TCP is wasting resources. Have
they made a mistake those days? How can transmission be guaranteed
without the things TCP does? What are the tradeoffs?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by sugarshark on Mar 10th, 2003, 11:51am
Looking forward to see it! Esp. if it were transparently embedded
into the NIO package
I've written such a beast in C++ some time ago for a comercial
game. I have a half finished reimplementation using java nio lying
around. I'm currently trying to find the time to finish it.
I definately need guaranteed transmission. IMHO thats the only way
to be able NOT to send redundant data and thereby saving *very much*
bandwidth. I could be able to give up the streaming characteristics
and sometimes even to drop so far undelivered messages in case of
new ones available.
What you need isn't guaranteed delivery but what i call "notified
delivery". You need to know when a packet didn't reach its
destination so you can resend it, or send new data if available. The
Tribes2 networking guys came up with this idea first, I think. See:
http://www.gdconf.com/archives/2000/frohnmayer.doc
You can implement this with a sliding window algorithm. I have done
it, for said game, on top of UDP and it worked beautifully, but was
later dropped (against my advice) in favor of DirectPlay.
Ole
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by markuskidd on Mar 10th, 2003, 1:41pm
on 03/10/03 at 04:59:00, Herkules wrote:
> Looking forward to see it! Esp. if it were transparently
> embedded into the NIO package ;)
It will probably be a seperate API which actually simplifies the
process of using non-blocking datagrams down to only what (I think)
we need. So it'll be a bit different but pretty straightforward.
> I could be able to give up the streaming characteristics and
> sometimes even to drop so far undelivered messages in case of
> new ones available.
Streaming never really seemed that benificial for the stuff I've
done with networking. Messages themselves as well as the underlying
protocols all lend themselves to being thought of as
packets/messages/whatever in gaming situations (unless you're
talking about transferring over a map file or a client upgrade, and
in that case opening up a TCP socket for the transfer isn't a bad
idea).
> I would be interested to know where TCP is wasting
> resources. Have they made a mistake those days? How can
> transmission be guaranteed without the things TCP does? What are
> the tradeoffs?
It's my understanding that when there are problems with
transmission, TCP backs off a bit in order to help net congestion
die down. The theory is that if the networks really are saturated
with traffic, all connected users are going to experience some
dropped packets, and so therefore if they're all running TCP and the
protocol elects to back off for a second or two, the congestion will
promptly start to clear. On the other hand, selfish game developers
don't really care about net congestion, and if we need a message to
get there we'd rather just send it 20 times and have it get there in
40ms rather than wait for congestion to die down and get it there in
80ms.
This all sounds good heheh... just hope I can make good on some of
it.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by gregorypierce on Mar 10th, 2003, 9:52pm
I had to write some commercial code that connected Dreamcast
consoles to a Java server running on the back end and while it never
(to my knowledge) tried to communicate across the ocean, it went
coast to coast across the United States with no issues whatsoever
(Dreamcast side was C based before people start inquiring).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 11th, 2003, 3:35am
? What's the essence? Did you use TCPor what?
We tried TCP connections also inside of Germany, but from one crappy
ISDN dialup as a server and some other DSL connect. Nothing bad to
see. A ISDN connected server should easily be able to host a game of
4-6 bandwidth-wise. By exploiting the knowlegde that a message
definately arrives, we come along with 1-2 messages/second.
Our message format is currently highly unoptimized and bloated so
there still is much potential for improvement w/o changing the
protocol.
Currently I just wouldn't dare to touch protocol - there have been
enough sync/deadlock/threading issues with the well-behaved TCP.....
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 11th, 2003, 3:55am
What I observed earlier when using TCP via DirectPlay was, that
overcommiting the line can lead to TREMENDOUS latencies. 10 sec, 15
sec.
So if the app is designed to pump out a message 10 times/sec, this
may lead to real serious issues! This is a real 'no go'.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by coilcore on Mar 21st, 2003, 12:46am
Ah the old UDP verses TCP debate. I don't currently work in the
game biz, but did circa the early/mid 90's. It was the dawn of
making online games and where I worked making games Internet enabled
was our thing. We did a lot of research on using TCP verse UDP for
games. The hardware infrastructure is much better now but the same
problems exist.
The simplest way to sum it all up is UDP will beat TCP for raw
throughput performance but TCP will usually beat UDP for
reliability. In the old days the rules were fairly simple. You
used TCP if game state was important (lockstep) and you used UDP if
latency was a premium and the game was wiggly enough to have things
maybe be inconsistant at times. The rules are significantly more
complicated now, but the basic premise is still there.
The best stuff I've seen is some very interesting layers on top of
UDP that essentially replicated some TCP functionality but
effectivlely did 'read ahead' and 'gap filling' that normal TCP is
not designed for - in those cases UDP was nearly as reliable as TCP
but much better performing. I'm sure things are much more developed
now.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by kevglass on Mar 26th, 2003, 4:07pm
Wow! Something I can actually comment on!
Apologises in advance for the long post,
I recently wrote a light cycle game in Java3D which is network
playable. I originally based the whole thing on TCP. On my local
machine there was no problem, across the LAN it was a little slow,
across the internet is was really bad.
With a little investigation I found that the real problem with using
TCP for anything performance related is the send/recieve buffers on
the IP stacks. TCP won't send an IP datagram until the send buffer
is full. So you'll get little blasts of data going across the
net. Athough you can reconfigure this on the local machine, the
further you go across the net the more stacks you go up and
down. This seems to be referred to as latency.
I moved over to UDP and suddenly I could get decent pings between my
client and server.
I've actuall written an API over the top of UDP that supports
"Message" objects. These can be sent across UDP in a TCP like
manner. The API uses the strategy pattern to support being able to
plugin different type of UDP handle, e.g. GuaranteedDelivery,
IgnoreLoss, ResequenceOnly
If anyones interested in the API drop me a mail.
Interesting thing was that even when I simulated TCP across UDP,
i.e. GuaranteedDelivery using ACK messages, I got a far better
performance. I guess what it comes down to is that using UDP you
have a real control over when an IP packet is sent.
Apologies again for the long message,
Kev
EDIT: Incidently, the API is based on NIO
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by markuskidd on Mar 26th, 2003, 5:43pm
could we borrow your input over at http://www.josrts.org/ in the
"Design" forum? this very issue is up for debate and it sounds like
your experience would be very pertinent ;D
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by leknor on Mar 26th, 2003, 6:08pm
on 03/26/03 at 16:07:38, kevglass wrote:
> With a little investigation I found that the real problem with
> using TCP for anything performance related is the send/recieve
> buffers on the IP stacks.
Socket.setNoDelay(true) to disable the Nagle's algorithm didn't
help?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 27th, 2003, 4:40am
on 03/26/03 at 16:07:38, kevglass wrote:
> I recently wrote a light cycle game in Java3D which is network
> playable. I originally based the whole thing on TCP. On my local
> machine there was no problem, across the LAN it was a little
> slow, across the internet is was really bad.
How many messages per second did you typically send? How big are
they?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by kevglass on Mar 27th, 2003, 7:04am
> Socket.setNoDelay(true) to disable the Nagle's algorithm didn't
> help?
This did give me some performance increase, but I got the feeling
this was only on the local stack.
> How many messages per second did you typically send? How big are
> they?
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.
Kev
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 27th, 2003, 7:22am
on 03/27/03 at 07:04:39, kevglass wrote:
> 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.
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.
<south><south><south><south><east><east><east><east><east><east><east>
<east><east><east><east><east><east><east><east><east><east><east><east>
<east><east><north><north><north><north><north><north><north><north>
<north>??
The ACK you send only for UDP, right? What happens if the ACK
doesn't get through?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by kevglass on Mar 27th, 2003, 10:42am
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 27th, 2003, 11:24am
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!]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by kevglass on Mar 27th, 2003, 1:23pm
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]
EDIT: The UDP API is over at http://www.newdawnsoftware.com in the
resources section.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Mar 27th, 2003, 7:24pm
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!):
1. "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).
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.
3. 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.
4. 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.
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? ;)).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by markuskidd on Mar 27th, 2003, 9:03pm
> 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
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...
> 1. "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).
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.
> 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.
Just because TCP has 22 states does not mean that another go at
guarantees needs it!
> 3. TCP s 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.
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.
> 4. 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..
> 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)
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.
> 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? ;)).
If you know of anything that is particularly well done for gaming
(and is implemented in Java!) I'd love to hear about it.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Mar 27th, 2003, 10:29pm
on 03/27/03 at 21:03:34, markuskidd wrote:
> 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...
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.
on 03/27/03 at 21:03:34, markuskidd wrote:
> 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.
> Just because TCP has 22 states does not mean that another go at
> guarantees needs it!
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 :(.
on 03/27/03 at 21:03:34, markuskidd wrote:
> 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.
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).
on 03/27/03 at 21:03:34, markuskidd wrote:
> And UDP is no more or less efficient than TCP.
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.
on 03/27/03 at 21:03:34, markuskidd wrote:
> 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.
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").
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by leknor on Mar 28th, 2003, 12:33am
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by kevglass on Mar 28th, 2003, 3:27am
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by abies on Mar 28th, 2003, 3:33am
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 ?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 28th, 2003, 4:13am
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.
on 03/28/03 at 03:33:04, abies wrote:
> 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.
> Can you give me examples of really fast paced, sucessful game,
> which has used TCP/IP for network communication ?
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?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by abies on Mar 28th, 2003, 7:12am
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by kevglass on Mar 28th, 2003, 7:30am
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Mar 28th, 2003, 7:49am
on 03/28/03 at 07:12:22, abies wrote:
> But are you suggesting that Carmack/GarageGames/Unreal team etc
> are just misguided flies?
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 ..... :-[
> 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.
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by abies on Mar 28th, 2003, 10:58am
on 03/28/03 at 07:30:55, kevglass wrote:
> 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).
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by coilcore on Mar 29th, 2003, 2:41am
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.
1. "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.
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.
3. "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.
4. "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.
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) "
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by endolf on Mar 29th, 2003, 9:53am
> I would say quite simply use TCP for reliable delivery, use UDP
> where latency is at a premium.
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??
> 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.
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.
> 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.
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.
> 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."
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.
Endolf
(dons flame retardant suit)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by coilcore on Mar 29th, 2003, 2:15pm
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.
on 03/29/03 at 09:53:46, endolf wrote:
> 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.
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by endolf on Mar 29th, 2003, 2:53pm
> 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.
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.
> Let me say straight forward and bluntly your statements are a
> clear indication that you do not understand TCP enough
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by coilcore on Mar 29th, 2003, 4:46pm
on 03/29/03 at 14:53:20, endolf wrote:
> 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.
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).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by endolf on Mar 29th, 2003, 5:04pm
I'm genuinely interested to learn some of these TCP optimisations if
they are as great as you say, but what we tried didn't work for us,
can you give us some technical explanations rather than 'use google'
?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by coilcore on Mar 30th, 2003, 2:00am
Probably the most import is turning off the Nagles algorithm, which
is designed to gain bandwidth at the expense of latency
Socket.setTcpNoDelay(true); // TCP_NODELAY
There are other things to work on, but the time difference you were
seeing doesn't make sense considering that you should get almost no
packet loss since your on that switch. Of course your packets will
still be a bit bigger with TCP (more header info), but with no
packet loss you should get nearly the same latency from TCP and UDP.
If you are not within a millisecond or two something is very wrong.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by endolf on Mar 30th, 2003, 4:23am
> Probably the most import is turning off the Nagles algorithm,
> which is designed to gain bandwidth at the expense of latency
> Socket.setTcpNoDelay(true); // TCP_NODELAY
yup, thats what we thought too, but we still saw huge latency :(
> Of course your packets will still be a bit bigger with TCP (more
> header info)
no biggy, it's not *that* much more info, and we have bandwidth to
spare atm :)
> but with no packet loss you should get nearly the same latency
> from TCP and UDP. If you are not within a millisecond or two
> something is very wrong.
again, this is what we thought, we tried changing buffer sizes too,
they all helped some, but nothing got us anything that we thought
'hey, we've cracked it', the send / receive buffer and the
TcpNoDelay seem to be the only settings we have to play with under
java, we also tried a completely remote network to check if that
helped, and it didn't seem to either, kevin went away and tried
using NIO channels too, that again helped some, but not enough. So
we looked at UDP, and seemed to beat the latency, we drew some
conclusions from this that may not be 100% accurate, but seem to
explain our situation.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Humble Pie
Post by endolf on Mar 30th, 2003, 12:10pm
:-[
In the interest of thoroughness I was going to dig out my old test
code and do some more playing, but i couldn't find it, so i rewrote
it, and damn if I didn't get good ping times (avrg 2 millis, worst
case about 4 millis, this was with TcpNoDelay set, I'm sure we tried
that before, but ho hum, our UDP code uses message objects so kevin
knocked together a TCP version of the endpoints and we are still on
sensible latency. I guess we did something wrong in out tests, but
what ever it was, we both did it independantly, and without the code
I can't check. So, large slice of humble pie, and a bald spot from
all the head scratching.
Most confused now
Endolf
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by coilcore on Mar 30th, 2003, 1:36pm
Of course the real problem with TCP comes in from packet loss (and
the subsequent retransmits and sequencing), which is when you start
having to get into really interesting experiments with what works
best for your particullar game. :)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Apr 2nd, 2003, 7:43am
on 03/28/03 at 07:12:22, abies wrote:
> 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 ?
There is no doubt that initially most of them had no real idea what
they were doing. Quake 1 and 2 both had rubbish network code (and q2
even came late enough, IIRC, to benefit from seeing the PlanetQuake
improvements - however, my knowledge of Q2 is very sparse; I didn't
play it much and haven't studied it (OTOH I've spent thousands of
hours on Q1 and 3)).
But that was THEN...see below for a note on Q3.
on 03/28/03 at 07:12:22, abies wrote:
> 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).
OK, but that's NOTHING! Quake 3 can cope with 40%-50% packet loss,
no probs (well enough, at least, to be able to still play the game
effectively, modulo the difficulties/differences that may ALSO be
caused by the high ping time that usually goes hand-in-hand with a
high packet loss).
on 03/28/03 at 07:12:22, abies wrote:
> 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.
Indeed; it is a sufficiently difficult problem with Tron to merit
some serious academic study - comparing players' effectiveness
against the same bots on different simulated artificially-delayed
systems. E.g. run TRON on a 10 Mb LAN, and run ten sets of tests,
from "no additional latency" up to "+100ms latency" or
something. This could be compared to the results of similar tests
that IIRC have already been performed for generic "twitch" games a
la Quake/Doom.
Certainly, tron on TCP is pretty much pointless without the
guarantee of LAN-only games. One dropped packet can screw the
synchronization (between players differing views of the game-state)
for the next 100-3000 milliseconds.
But c.f. my next post below...:)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Apr 2nd, 2003, 7:58am
Quick side note for endolf - who by the sound of things was trying
sensible things to solve a weird problem:
This may be a red herring, but in future also investigate your
hardware. I've generally stuck to one or two top-tier branded NIC's
since first discovering how much seriously terrifyingly screwed
hardware was around many years ago. Probably not worth naming them
because I've not re-analysed whose best recently, and now know the
quirks so well I don't need to change. However, I can assure you
that even the most expensive NIC's from the most famous
manufacturers have some SERIOUS problems - e.g. I've seen 3COM
100Mbit cards that can "accidentally" get stuck at approx 1Mbit
(yes, really!); 3COM also in particular had a problem for a long
while of people selling things that looked like a 3COM, smelled like
a 3COM (!), but wasn't really - it was a carefully branded clone.
It's crazy the first time it happens to you, but sometimes you find
that a factor-of-a-hundred (or more) performance problem on your LAN
can be attributed to one piece of dodgy hardware - from a reputable
manufacturer.
on 03/30/03 at 04:23:09, endolf wrote:
> yup, thats what we thought too, but we still saw huge latency :(
no biggy, it's not *that* much more info, and we have bandwidth to
spare atm :)
again, this is what we thought, we tried changing buffer sizes too,
they all helped some, but nothing got us anything that we thought
'hey, we've cracked it', the send / receive buffer and the
TcpNoDelay seem to be the only settings we have to play with under
java, we also tried a completely remote network to check if that
helped, and it didn't seem to either, kevin went away and tried
using NIO channels too, that again helped some, but not enough. So
we looked at UDP, and seemed to beat the latency, we drew some
conclusions from this that may not be 100% accurate, but seem to
explain our situation.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Apr 2nd, 2003, 8:53am
As my initial inordinately long post has now kicked up quite a few
interesting comments and ideas, I'm weighing back in with a
generalised response :).
FYI, I come from a strong academic background (Cambridge University,
where being/becoming familiar with all the prior art is heavily
encouraged) and now work on the Grexengine (an MMOG technology -
grexengine.com), although only tangentially on the networking side
(I choose protocols, not implement them). But I've never been a pro
network engineer, and most of my knowledge is a combination of
talking to real net engineers, detailed academic study of the
systems and protocols, and my own experiences over 9 years. So you
can take what I say with a pinch of salt...
What I'd like people to take home as the core points:
1. TCP vs UDP: It's not a simple argument; be careful about making
any decisions that will cost you significant effort to implement.
2. UDP + (some parts of TCP): Is VERY difficult to get right; it's
one of the areas of programming that is still "hard", as opposed
to just being time-consuming to get right.
3. Of the three options covered in those two points, each is
suitable for a significant percentage of games; I say "suitable"
not "perfect" - a perfect option is the one that is
technologically best for the game, a suitable one is the one that
is affordable, not too risky, and provides acceptably good
performance.
4. A depressingly large number of people who offer advice on these
topics are naive or ignorant at best (i.e. they have gaps in their
knowledge), or just plain wrong at worst. Be careful what advice
you take! (and as endolf discovered, it's often not as simple as
just experimenting with the alternatives people suggested and
benchmarking them - there are nasty non-obvious subtleties in
accidentally mis-implementing many of the protocols).
To illustrate each of these a bit further (some I covered
initially):
1:
Well, I guess the length of this discussion already makes that
clear enough. Nod to all those who've contributed examples and
counter-examples and shown how non-trivial a question this really
is :). I'd quote more, but this board makes it difficult to quote
lots of posts in one, sigh.
2:
on 03/29/03 at 02:41:42, coilcore wrote:
> 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.
Coilcore gave a good explanation of how hard it is to replicate even
just some of the excellent work of Jacobson's (sp?) - and many
others. Not by any means impossible, and most of it is documented as
research papers - but it wasn't done by "ordinary" developers: much
was done by hard core specialists.
3:
on 03/29/03 at 02:41:42, coilcore wrote:
> (in response to my quote: "Lastly, there ARE alternatives to TCP
> and UDP. Not surprisingly")
> 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.
Most of coilcore's expansions on what I said originally are extra
details that I might myself have come up with - we concur strongly.
However, there seems to be one point coilcore doesn't appreciate:
there are games where neither UDP nor TCP - nor both together -
"work". Some absolutely require simultaneous low latency with
guaranteed delivery - and e.g. even using the TCP as a control
channel to police the UDP (which is a relatively easy "first draft"
way of implementing this) is itself not "fast" enough (in the cases
I've seen, it's too high latency, because a dropped TCP packet can
delay the realisation that a UDP packet got dropped, delaying the
resend).
(but note: this is NOT the case for the majority of games - for most
games, I agree with coilcore, and my initial arguments for not doing
so come to the fore)
For some of those I've looked at, separating one stream into
TCP-bits and UDP-bits (i.e. sending the data that needed reliabilty
down TCP, the rest on UDP, etc) was highly undesirable - but in the
overall scheme of things saved enough implementation time and hassle
that it made sense financially. Others just HAD to have the best of
both worlds. As someone else mentioned, TCP was designed as a
generic excellent-average-case protocol; some games sadly pay the
price for that (if they use TCP at all).
So, people shouldn't dismiss "roll your own" (RYO) out of hand - but
OTOH, there's SO MANY people who assume they should RYO in the first
place that perhaps I should say as you do, just to combat the huge
weight of current opinion, and even the scales! :)
As I said before, think several times (lots) before RYO'ing - but
don't completely dismiss it if it looks like it might be
necessary. You can probably solve what you thought needed RYO by
e.g. using a clever higher-level algo like in Quake3 - but maybe you
can't.
4:
on 03/29/03 at 02:41:42, coilcore wrote:
> proramming guru while John Carmack was a god, but mostly in
> graphics and non-networked game stuff).
Indeed, a very good point: it's very important in the games industry
to be wary of the fact that most of us are brilliant coders, but
only highly experienced in our own specialist areas - and can be
quite naive in others.
I've read Carmack's long explanation of Q3's networking technology,
which Brian Hook requested off him and posted to the MUD-DEV mailing
list. A search for "Hook, Carmack, Quake3, MUD-DEV" on google should
find the post in the MUD-DEV archives. Nicely explained, and a
reasonably good approach - although some people consider it a bit
more ground-breaking than perhaps is fair.
In summary, by the time id got to Q3, they'd come up with a good
algorithm for network-play. As you explained, possibly the biggest
problem has not been the technology, but the higher-level
algorithms/protocols/etc and the decisions on HOW to use the
available tech; Q3's networking is a good solution for a Q-like
game.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Apr 2nd, 2003, 9:34am
on 04/02/03 at 08:53:47, blahblahblahh wrote:
> I've read Carmack's long explanation of Q3's networking
> technology, which Brian Hook requested off him and posted to the
> MUD-DEV mailing list. A search for "Hook, Carmack, Quake3,
> MUD-DEV" on google should find the post in the MUD-DEV
> archives. Nicely explained, and a reasonably good approach -
> although some people consider it a bit more ground-breaking than
> perhaps is fair.
Looked it up an read it. I think the solution is a typical
Carmack-solution and reminds of the early published Doom
sourcecodes. This is very typical for game coding in contrast to
application coding. The solution is absolutely focused on the
current topic, no abstraction, no layering, simple as
possible. Maybe that is one of Carmacks biggest talents. KISS - keep
it stupid simple.
When I start doing this kind of construction as a not-so-talented
game coder, I think of optional clients that only need parts of the
information, think of scalability, how to hide networking at all,
setting up distributed databases of several kinds, care for minimal
bandwidth usage, ..... I just cannot manage to focus on transmitting
the gamestate of a specific FPS. Cannot even develop an imagination
what a 'gamestate' could be.....
Just totally different from a Carmack-approach. I'm afraid my system
to just identify things is more complex than the whole Q3 network
logic....
But in the end, Q3 networking is highly brute force, isn't it?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by leknor on Apr 2nd, 2003, 10:32am
One thing I don't remember being mentioned in this thread is there
is a desired middle state between UDP and TCP that as far as I know
doesn't exists.
UDP is a bunch of atomic datagrams.
TCP is a reliable stream of bytes.
I think many developers *want* a reliable and atomic protocol but
don't need the stream concept. Something more than UDP but less than
TCP. A protocol where packet #5 doesn't prevent packet #6 from
arriving but #5 will be retransimited asap.
Personally I feel that this desire stems for the developer's desire
for a quick/easy solution instead of doing the right thingTM and
writing their game protocol such that current updates are not
dependant on past state.
... but that's just my unprofessional opinion.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Apr 2nd, 2003, 10:58am
I feel that reliable and stream are tightly connected terms.
For TCP, if #5 cannot be transmitted for a time, the stream goes to
an error state.
But what would be if #5 fails to transmit over and over while #6,
#7, #8 are transmitted w/o problem? #1000, #1001, .... but #5 still
missing. Is this an error? Close connection? Very difficult!
A replacable transmission would be great, where in case of failure
and retransmission the data can be replaced by a more current one.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Apr 2nd, 2003, 5:21pm
on 04/02/03 at 10:32:03, leknor wrote:
> One thing I don't remember being mentioned in this thread is
> there is a desired middle state between UDP and TCP that as far
> as I know doesn't exists.
Um, OK, you may need to read between the lines, but several people
have been saying that. My first and last posts were fairly explicit
in mentioning it. In the first one, I said:
"4. 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"."
...which is TCP with something taken out (that doesn't exist in
UDP), making it slightly more like UDP - i.e. a middle ground
between the two.
on 04/02/03 at 10:32:03, leknor wrote:
> UDP is a bunch of atomic datagrams.
> TCP is a reliable stream of bytes.
>From the textbooks:
TCP is...reliable, in-order, flow-control, congestion-control,
connection-oriented, socket-addressed, automatic MTU/MSS discovery
(i.e. dynamically selects the best size packets to avoid
fragmentation)
UDP is...stateless (advantageous in some situations including
e.g. can reduce memory usage), socket-addressed, smaller header
size
IP is... (TCP and UDP typically both run on IP but don't have
to)...checksums, fragmentation, QOS (sometimes), TTL management.
Some consider that TCP offers too much for it to be ever worth not
using it.
Note that TCP/IP is also:
- ppor at QOS
- very poor at congestion control
- very poor at encryption
Other protocols do these better, but some things (like
e.g. congestion control) only work well when everyone (on the
network) is using them. We could stop most DDOS attacks easily, if
only the world were willing to dump IP and switch to ATM. Another
example: IPv6 is good at encryption.
TCP is not perfect, and it doesn't do the kitchen sink - but perhaps
it does everything else :).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Apr 2nd, 2003, 5:25pm
on 04/02/03 at 09:34:27, Herkules wrote:
> Looked it up an read it. I think the solution is a typical
> Carmack-solution and reminds of the early published Doom
> sourcecodes. This is very typical for game coding in contrast to
> application coding. The solution is absolutely focused on the
> current topic, no abstraction, no layering, simple as
> possible. Maybe that is one of Carmacks biggest talents. KISS -
> keep it stupid simple.
> When I start doing this kind of construction as a
> not-so-talented game coder, I think of optional clients that
> only need parts of the information, think of scalability, how to
> hide networking at all, setting up distributed databases of
> several kinds, care for minimal bandwidth usage, ..... I just
> cannot manage to focus on transmitting the gamestate of a
> specific FPS. Cannot even develop an imagination what a
> 'gamestate' could be.....
> Just totally different from a Carmack-approach. I'm afraid my
> system to just identify things is more complex than the whole Q3
> network logic....
on 04/02/03 at 10:32:03, leknor wrote:
> Personally I feel that this desire stems for the developer's
> desire for a quick/easy solution instead of doing the right
> thingTM and writing their game protocol such that current
> updates are not dependant on past state.
A very interesting idea. I've spoken to some within the games
industry who are really pissed off with "the idiots who try to do
everything with objects all the time" (they are themselves usually
expert OO developers). We at least agree that too many educational
establishments teach how to OO without teaching why, and there's a
huge number of people around who have the age-old problem "when all
you have is a hammer, everything in the world starts looking like a
nail".
I can give an interesting example from another industry, same
problem: someone I know was managing the development of radar
systems. There was a team working on the software to draw the
display. The old version was C, with little reusability - everything
was so tightly integrated that it was hard/impossible to separate
and encapsulate functionality. The new version that the new team
proudly delivered had a class for each of:
- the planes
- the previous positions of each plane (so you could draw trails
of arbitrary length)
- the predicted positions of each plane
- the graphic for the plane (methods to change colours, change
size, rotate, etc)
Unfortunately, on the first beta test, they discovered that it took
30 seconds to draw EACH FRAME of the radar - i.e a frame rate of
0.03 fps. This is because each real-world plane had approximately 30
objects associated with it, and there were a LOT of planes (and the
redraw was heavily OO'd, with separate layers drawn separately, so
that it took IIRC 5 or 6 passes to draw the whole frame).
Ultimately, you should never use a tool unless you know what it's
meant for; OO was invented to solve a small set of recurring
problems - it's great for solving them, but it has soooooo many
disadvantages that it can be as lethal as it can be a lifesaver.
I'm not implying that you in particular shouldn't use OO, but it's a
sword that cuts both ways. In particular (to come back on topic),
when you're writing network code, you CANNOT speed up the internet,
and you probably cannot speed up the hardware (you only control the
server hardware, not the client stuff). So, all that's left for you
to squeeze optimizations out of is the software. Performance is
typically a heck of a lot more important than whether you can easily
add new features later on (one of the primary advantages of
OO). Reusability for network code often is no more complex than "is
it a single API that I can remember how to use?". It's quite hard to
write a network-API that isn't reusable (you have to write pretty
hard-core complex algorithms and protocols to make it that way).
Several other parts of game development are similar. I suggest using
thingy's equation (hopefully someone else can remember the name!)
that's the yardstick for VLSI (cpu) developers:
To compare two possible ways of doing a new function (or choosing
one of two functions to implement in silicon when you only have
room for one), you rank each using the formula:
score = %age speed improvement / %age of the time that the speed
improvement can be used.
So simple, yet for instance I wouldn't bother with abstraction if I
were writing a new 3D engine except at a very high level - e.g. I'd
want to be able to swap in and out different renderers, and be able
to reproduce "sketched quake" (where the renderer is replaced with
one that draws everything like pencil sketches; it's pretty cool) or
"fisheye quake" where everything is rendered through a
super-wide-angle ("fisheye") lens.
Many (most?) low-level decisions in game development are 100% all or
nothing: if I write a game whose engine uses BSP's, there's no point
in being able to swap that out and use a non-BSP solution - the use
of BSP's contaminates so much other code in so many places, that you
never need a fine grain of replaceability.
These examples are perhaps a little contrived; BSP is a particularly
nasty (contaminating) technology that it would be nice to never use
at all - but it is very effective and was miles ahead of anything
else (for performance) invented for a long while.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by jbanes on Apr 2nd, 2003, 6:18pm
While you're right about OO being heavily misused, I don't think
that it's anything inherent in OO designs. Take Java 1.1 vs. many of
the later APIs for example. With the exception of the AWT, the 1.1
APIs generally consisted of 1 class per function with as little
"tying" as possible. This open design allowed each class to perform
independently and performance was handled internal to the class. Now
take a Java 2 API such as JavaMail. JavaMail has an object to
describe every little item in the system, from body text to email
addresses to attachments.
In the case of JavaMail it ended up making sense due to the
flexibility it gave. But what about Graphics2D? Did we really need
objects to describe transforms instead of constants? Especially in
performance critical code. The error that I think designers make is
that they look for perfect OO instead of pragmatic OO. In
thoeretical "perfect" OO, every part of the system should be
described by objects down to the slightest detail of using an object
instead of a primitive. This works fine, *in theory*. In reality,
you could continue churning out objects ad-infinitum because you'll
never be able to stop deciding what should be described by your
system, and what should be taken as an axiom. Thus you end up with
object after object being created just to run the simplest of
programs.
At the same time, where to draw the line to get the best balance can
be a difficult question to answer. Just be aware of what your code
is doing and you should be able to deliver both maintainable OO code
and high performance code in the same package.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by blahblahblahh on Apr 3rd, 2003, 6:45am
on 04/02/03 at 18:18:58, jbanes wrote:
> While you're right about OO being heavily misused, I don't think
> that it's anything inherent in OO designs.
Yes, there are situations where OO is abused without it being OO's
fault. There are also many many ways in which OO is just plain
rubbish and ruinous for a project - you're onto the right track by
saying that "sometimes it can be taken too far", but it goes much
further than that.
OO was invented largely to provide: encapsulation, data-hiding,
versioning-independence, explicit-interfaces, ADT's,
etc. Encapsulation is probably the most important of those,
depending upon whom you talk to ("an object is defined as Data + the
methods that act upon that data").
E.g.: "Global" methods and data are fundamentally non-OO. There
was a time when it was preached that "You should NEVER use global
anything - there's always a better way". There were good reasons
for this - e.g. some compiler-optimizations are impossible if the
source contains any globals. But as PC's get more powerful,
compilers can take more time to compile - which enables new
transforms which are more "brute force" than the original ones.
So nowadays at least one major reason not to use globals is
evaporating; but I've worked on at least one game where every method
had to have access to every set of data - the problem domain was
really hard to solve if you used any encapsulation. Which is a bitch
to solve if you're working in a programming language which really
only supports imperative code and OO - and doesn't also do, e.g.,
aspects or similar out-of-the-box (IIRC, Aspect-oriented programming
was invented largely to circumvent problems like this)
There are mathematical theories around, along the lines of "no
programming paradigm will ever be the best paradigm in the majority
of situations" - but no-one has yet proved them AFAIAA :). They are
based on work to do with search-spaces, and the concept that the
ordered set of searches of an algorithm is equivalent to a
description of the algorithm. You can probably find more info
anywhere that discusses the Church-Turing thesis (that all
non-trivial programming languages are 100% equivalent).
(side note: until someone "disproves" C-T, everything can be
written in the lambda calculus, which is a programming language
with only two operations, and no other symbols - no numbers, no
constants, no characters etc - but it can still represent any
program you can think of).
...this also happens to underlie most compiler-development
theory. But now I'm guilty of taking this thread completely OT...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by Herkules on Apr 3rd, 2003, 6:53am
on 04/03/03 at 06:45:55, blahblahblahh wrote:
> until someone "disproves" C-T, everything can be written in the
> lambda calculus, which is a programming language with only two
> operations, and no other symbols - no numbers, no constants, no
> characters etc - but it can still represent any program you can
> think of
Aha - so what is better now: TCP or UDP ?
;D ;D ;D ;D
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by kevglass on Apr 3rd, 2003, 7:11am
> Aha - so what is better now: TCP or UDP ?
Well, after re-reading the thread and having learnt my lesson, I'd
have to recommend carrier pigeon as the most flexible
transport. That, possibly in conjuction with the use of two coffee
cups and a piece of string.
:D
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by endolf on Apr 3rd, 2003, 7:23am
RFC 1149
i think ;D
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Title: Re: UDP Vs TCP/IP
Post by darcone on Apr 10th, 2003, 7:14am
I had a very interestig lecture on TCP and UDP today... You can
look at the OH and summary here: (very good documentation imo)
http://www.imit.kth.se/courses/2G1501/common/2g1316-17/lect/end1.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list