1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
|
<!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:zane%40supernova.org">
<LINK REL="Previous" HREF="000484.html">
<LINK REL="Next" HREF="000491.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Nel] TCP vs. UDP</H1>
<B>Zane</B>
<A HREF="mailto:zane%40supernova.org"
TITLE="[Nel] TCP vs. UDP">zane@supernova.org</A><BR>
<I>Thu, 5 Jul 2001 10:08:09 -0700</I>
<P><UL>
<LI> Previous message: <A HREF="000484.html">[Nel] TCP vs. UDP</A></li>
<LI> Next message: <A HREF="000491.html">[Nel] TCP vs. UDP</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#486">[ date ]</a>
<a href="thread.html#486">[ thread ]</a>
<a href="subject.html#486">[ subject ]</a>
<a href="author.html#486">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>----- Original Message -----
From: "Vincent Archer" <<A HREF="mailto:archer@frmug.org">archer@frmug.org</A>>
Sent: Thursday, July 05, 2001 8:50 AM
><i> To be efficient, any UDP-based protocol needs to be highly aware of the
</I>><i> data semantics (not just syntax - i.e. format - but semantics - i.e.
</I>meaning)
><i> of what it carries. Which makes it very complex and usage-specific; you
</I>><i> cannot plug in a "random UDP protocol" in your app (in this case, the
</I>><i> client-server part of NeL architecture). If you design the protocol in
</I>><i> complete isolation of the application (the MMOG) inside, better go
</I>directly
><i> to TCP; it won't be worse than anything you'll design. And it's already
</I>><i> made and tested.
</I>
I don't believe that this is entirely true. Let's look at what we need out
of a protocol for NeL:
1) Know what data HAS to be delivered and what data doesn't really.
2) Know what data can be overwritten by new data if we recieve a large
chunk of data
at once or out of order. (If the data is spread out, not read in one call to
the network object, then we don't need to know if it can be overwritten, and
in order the game engine will overwrite it if it's the same class of data)
Problem one is very easy to solve, we simply use a priority argument when
sending data with our network object. In this case high priority data could
be sent via TCP and low priority data could be sent via UDP.
Problem two really isn't all that hard to solve either. Perhaps we have a
'class' argument whend sending data via our network object. When a packet
is sent it includes it's data class and a serial number, both client and
server keep track of both. When we recieve data we check the class and
serial number. If the serial number is out of sequence and the data is
considered old for that class then it's discarded, otherwise it's accepted.
If the data has no class (class is set to 0) then all data is accepted and
the serial number isn't checked.
The only problem I see is mainting the large list of data classes. Really I
don't think it's that much of a problem and wether or not you're using this
model if you do discarding of data you'll be doing class checking in some
form anyway.
I'm sure the rest of you will point out the many other flaws I don't see.
:<i>P
</I>
-E.J. Wilburn
<A HREF="mailto:zane@supernova.org">zane@supernova.org</A>
</pre>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI> Previous message: <A HREF="000484.html">[Nel] TCP vs. UDP</A></li>
<LI> Next message: <A HREF="000491.html">[Nel] TCP vs. UDP</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#486">[ date ]</a>
<a href="thread.html#486">[ thread ]</a>
<a href="subject.html#486">[ subject ]</a>
<a href="author.html#486">[ author ]</a>
</LI>
</UL>
</body></html>
|
