diff options
| author | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
|---|---|---|
| committer | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
| commit | 0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch) | |
| tree | 2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2000-November/000041.html | |
| download | nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip | |
Initial commit
Diffstat (limited to '')
| -rw-r--r-- | pipermail/nel/2000-November/000041.html | 94 |
1 files changed, 94 insertions, 0 deletions
diff --git a/pipermail/nel/2000-November/000041.html b/pipermail/nel/2000-November/000041.html new file mode 100644 index 00000000..f77c77a7 --- /dev/null +++ b/pipermail/nel/2000-November/000041.html @@ -0,0 +1,94 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Nel] Ok, some food for your toughts</TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:sferro%40wojo.com"> + <LINK REL="Previous" HREF="000040.html"> + <LINK REL="Next" HREF="000043.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Nel] Ok, some food for your toughts</H1> + <B>Sal</B> + <A HREF="mailto:sferro%40wojo.com" + TITLE="[Nel] Ok, some food for your toughts">sferro@wojo.com</A><BR> + <I>Thu, 16 Nov 2000 12:32:09 -0500</I> + <P><UL> + <LI> Previous message: <A HREF="000040.html">[Nel] Ok, some food for your toughts</A></li> + <LI> Next message: <A HREF="000043.html">[Nel] Ok, some food for your toughts</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#41">[ date ]</a> + <a href="thread.html#41">[ thread ]</a> + <a href="subject.html#41">[ subject ]</a> + <a href="author.html#41">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>><i> You can take the long, hard route: +</I>><i> use UDP (and code redundancy for the elements you need to guarantee +</I>><i> transmission of, putting some badly made subset of TCP in it). +</I> + I find it easier to put some simple checking into UDP than to manage two +sets of sockets for each client, one TCP and one UDP. Also the important +data that needs reliable transmission is usually rare.... like you said, +when someone casts a spell... and maybe chat text. Most data in a networked +game is usually skippable. I think this is why most games use simple UDP, +because of simplicity of implementation, and because there is so little data +that needs to be sent reliable, a less-than-efficient reliable stream is +o.k. The strength in TCP/IP comes mostly when sending large amounts of +data, since it makes compromises with packet acknowledgement over a period +of time to gain its efficiency. But for short bursts of data typical for a +MMOG it wouldn't perform significantly better. + +><i> Or you can take the smart route: use two protocol paths, one which carries +</I>><i> the correctable elements over UDP (since you don't care if you lose a % of +</I>><i> them), and one which carries the critical ones over TCP (which provides +</I>you +><i> the service guarantee you need). +</I> + This is one possible route... not a bad one either. There would not be +any sort of performance loss in comparison to a pure-UDP implementation, +since the operating system's TCP/IP implementation is probably more +efficient than the custom UDP one. + + I guess its a matter of preference, of the developers are willing to +code something that manages two sets of sockets int the clients and servers, +then go for it :-) + +><i> One of the minor advantages of the dual-protocol path is that it allows +</I>you to +><i> bypass firewalls that refuse to forward UDP: you fold back the UDP +</I>protocol +><i> path into TCP. You start losing performance, but at least, you do have a +</I>><i> way of passing thru (don't forget to make your UDP packet protocols +</I>><i> compatible with TCP streaming). +</I> + This is true. Then again, a most of today's networked games use UDP so, +the genre of people who would play a MMOG would probably have dealt with the +firewall issues before, and would expect to fix their config to accomodate a +new game. Of course thats a slight generalization... + +Just adding some more food to the bowl ;-) +-Sal + + +</pre> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI> Previous message: <A HREF="000040.html">[Nel] Ok, some food for your toughts</A></li> + <LI> Next message: <A HREF="000043.html">[Nel] Ok, some food for your toughts</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#41">[ date ]</a> + <a href="thread.html#41">[ thread ]</a> + <a href="subject.html#41">[ subject ]</a> + <a href="author.html#41">[ author ]</a> + </LI> + </UL> +</body></html> |