Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Quake/QW and Pipeline 75 and NAT
Some questions have been raised about the definition of UDP, and from
what RFC I'm getting this information (or what I'm smoking :). The
following STD is the standard for UDP. I _hope_ this answers all
questions on the Quake/UDP issue. :)
Full text at http://info.internet.isi.edu/in-notes/std/files/std6.txt
Regardless of what was proposed, RFC 768 made it as an Internet
Standard. I haven't researched this aspect much, but I didn't see David
Reed's name anywhere on the standard. Perhaps he helped write/was
quoted in one of the references, or is referring to a different, non STD
RFC.
STD 6 (RFC 768) Describes the UDP layer format, written by J. Postel:
> Format
> ------
>
>
> 0 7 8 15 16 23 24 31
> +--------+--------+--------+--------+
> | Source | Destination |
> | Port | Port |
> +--------+--------+--------+--------+
> | | |
> | Length | Checksum |
> +--------+--------+--------+--------+
> |
> | data octets ...
> +---------------- ...
>
> User Datagram Header Format
>
> Fields
> ------
>
> Source Port is an optional field, when meaningful, it indicates the port
> of the sending process, and may be assumed to be the port to which a
> reply should be addressed in the absence of any other information. If
> not used, a value of zero is inserted.
Well, here it is, written in stone as it were. id software sets this
port to some non-zero value, and therefore is required to receive
packets on the port specified in the UDP header, not in the data
octets. This is what NAT takes advantage of. NAT does not claim to
handle all forms of UDP, however. When the source port is zero, all
bets are off.
Notice how at the packet level, UDP and TCP can be very similar...
except in rare cases where someone uses a UDP protocol in a truly
connectionless manner. Quake does not qualify for this. There is
simply a bug in the way the Quake protocol was written.
> Destination Port has a meaning within the context of a particular
> internet destination address.
So, the Pipeline doesn't touch it.
> User Interface
> --------------
>
> A user interface should allow
>
> the creation of new receive ports,
i.e. a Quake server listening on UDP port 26000.
> receive operations on the receive ports that return the data octets
> and an indication of source port and source address,
i.e. a Quake server receiving the first packet from a client.
Unfortunately, the Quake server ignores the UDP header source port.
> and an operation that allows a datagram to be sent, specifying the
> data, source and destination ports and addresses to be sent.
The Quake client does this properly, as does the Quake server.
Unfortunately, the Quake server inserts the wrong destination port.
> Protocol Application
> --------------------
>
> The major uses of this protocol is the Internet Name Server [3], and the
^^^^^^^^^^^^^^^^^^^^ = DNS
client
queries
I believe zone transfers are TCP based.
> Trivial File Transfer [4].
Cool.
I don't know how tftp works, but DNS is a simple client-server protocol
which works great through NAT, and complies with STD 6. Quake is more
complex than DNS, of course... but only in game design. It's just
another client/server protocol.
I believe that id designed the Quake IP protocol this way as a carry
over from their IPX protocol. No other idea I've heard makes more
sense.
Again, I hope this answers everyone's questions.
Thanks,
--
Jason Eggleston
SysAdmin, Jet.Net Inc.
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>