[MUD-Dev] UDP Revisted

[Brian Hook]

At 02:33 PM 10/10/01 +0100, Daniel Harman wrote:

> The issue centres around using a known port for all comms, or
> using a range.  From a server perspective, it seems easy enough to
> have multiple clients all on the same well known UDP port since a
> single port can handle an arbitrary number of connections (I
> believe). I'm concerned that this then leaves a server open to
> easy packet flooding.

I would imagine that problem isn't going to be port specific if
someone is performing a DoS attack -- they're going to flood the
server and its upstream routers with garbage packets, which will
hose you irrespective of the given port.

I suppose there might be some merit trying to obfuscate your active
connection port, but even then I would imagine a talented attacker
would simply negotiate the appropriate protocol to retrieve a valid
port then just spam it instead.

As a reference, I'm pretty sure Quake3 uses only a single port and I
haven't heard of any complaints related to this (granted, with only
32 players typically, but at much, much higher bandwidth per player
than a MUD, graphical or not).

> The alternatives, which I believe Everquest may use, are to either
> negotiate a port to communicate on through the log in server, or
> to have a set of known ports with which one can connect to the
> server, and to randomly pick one. Obviously the former is more
> complicated as the negotation probably takes place using a
> standard tcp/ip connection with some form of encryption, so you
> have to pass state between that and the udp part of the system.

Why would the negotiation require TCP?  All the relevant state can
be stored on the server and client, and UDP would be used to handle
the negotiation.

I would personally shy away from mixing and matching TCP and UDP.
Adding a reliable transport layer on top of UDP isn't that difficult
(anyone seriously working on this stuff should, at the very least,
have a copy of Unix Network Programming by Stevens), and TCP
performance is fairly slow and unpredictable.  From talking to
others, one of the primary problems is that your TCP command stream
can often be radically out of sync with your TCP one.  So if you try
to sync your UDP stream with the occasional TCP packet, you can get
really wacky results and hiccups.

> Are there any reasons that I might want to not use a single port
> for UDP with multiple clients other than the flooding aspect? It
> just seems wasteful to instantiate a socket per client for a
> connectionless protocol, although obviously from a defensive point
> of view, its easier to stop servicing a port if someone starts to
> flood it as it will only affect the flooder.

The main advantage is that you can then associate port number with
client, which is a nice easy correlation, e.g.:

  clientIndex = incomingport - PORT_BASE;

With a single port you'll have to hash the client's incoming address
(via recvfrom()) into a table of clients.  This may or may not be a
factor, but it does add some extra indirection:

  clientIndex = hash( incomingAddress, NUM_PORTS );

Brian

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev