diff options
Diffstat (limited to 'pipermail/nel/2001-July/000496.html')
| -rw-r--r-- | pipermail/nel/2001-July/000496.html | 91 |
1 files changed, 91 insertions, 0 deletions
diff --git a/pipermail/nel/2001-July/000496.html b/pipermail/nel/2001-July/000496.html new file mode 100644 index 00000000..a686dffb --- /dev/null +++ b/pipermail/nel/2001-July/000496.html @@ -0,0 +1,91 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Nel] TCP vs. UDP</TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:miller%40nevrax.com"> + <LINK REL="Previous" HREF="000494.html"> + <LINK REL="Next" HREF="000497.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Nel] TCP vs. UDP</H1> + <B>Daniel Miller</B> + <A HREF="mailto:miller%40nevrax.com" + TITLE="[Nel] TCP vs. UDP">miller@nevrax.com</A><BR> + <I>Sun, 8 Jul 2001 18:44:09 +0200</I> + <P><UL> + <LI> Previous message: <A HREF="000494.html">[Nel] TCP vs. UDP</A></li> + <LI> Next message: <A HREF="000497.html">[Nel] TCP vs. UDP</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#496">[ date ]</a> + <a href="thread.html#496">[ thread ]</a> + <a href="subject.html#496">[ subject ]</a> + <a href="author.html#496">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>I've been reading this thread with great interest. There's clearly a good +case for using UDP for low priority or short life-span data. In this case +the app software on top of NeL must clearly be designed with the fact that +some data isn't going to get through in mind. + +The problem is particularly interesting because: +1. The limiting factor on the amount of data we transmit looks like being +the cost of output bandwidth for the servers. +- as far as I can ascertain, at today's costs we're looking at something +like 8-16 kilobits per client per second maximum output from the servers +(including lost packets) +2. The complexity of the scenes that we are trying to convey to the clients +is rising fast. +- view distances are increasing, as are screen resolutions which means that +you can see more dynamic world content at any given time (characters, +creatures, objects...) +- It is clear that for MMORPGs we wil soon need to be able to display crouds +or armies of 100s or even 1000s of characters and creatures at once. +- Character animation is becoming more complicated to reflect a mix of +actions performed simultaneously (such as speaking with emotional facial +expression and manipulating an object in one's hands while sitting down) - +which means more information to describe each character's state. +- and so on... + +These two points combined mean that, whichever way one looks at it, a lot of +scene information will have to be filtered out or sent at low frequency. If +one isn't careful low frequency sends can obviously be very sensitive to +packet loss - which leads me to the point of this posting: In order to work +the problem we need to have a good understanding of true internet behaviour +and to have a good set of test data for simulating it. + +The trouble right now is that I have no hard data to use to model packet +loss or delivery latency over time. If anybody knows of any studies that +have been done or has any of their own data I'd be very interested. In +particular I'm interested in moderately bad connections that exhibit both +good behaviour and bad behaviour over time. + +Regards to all, +Daniel + + + +</pre> + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI> Previous message: <A HREF="000494.html">[Nel] TCP vs. UDP</A></li> + <LI> Next message: <A HREF="000497.html">[Nel] TCP vs. UDP</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#496">[ date ]</a> + <a href="thread.html#496">[ thread ]</a> + <a href="subject.html#496">[ subject ]</a> + <a href="author.html#496">[ author ]</a> + </LI> + </UL> +</body></html> |