Steve wrote:
While designing my new MUD server I ran into a design problem that I'm
hoping someone here has had experience with.
Specifically, I currently keep track of clients in a hashmap, with the
hash being comprised of their IP address and port.
This works very well until multiple clients who are NAT'd try to connect.
Now my initial response to this was to have each client bind a
listener to a random port, then send a discovery request to the server
that contains the port that they bound their listener to.
That kind of works, except that some NAT Gateways and routers
(specifically my own ActionTec Gateway POS from Qwest), block
unsolicited incoming UDP packets on all ports regardless of if the
same IP address is responding, as was used in the initial request, if
the response packet is coming in on a port different than the one the
original discovery packet was sent from.
That's correct. The router has to choose the port number, not your
server. Your server must reply to the address and port provided in the
IP header of a packet from the client. You mentioned your application
uses some kind of discovery request. That discovery request adds an
entry to an internal table in the router. The internal table maps
packets sent from the server to the router on a specific port back to
the host that sent the discovery request. The discovery request creates
a virtual connection and you must use that connection for the duration
of the session.
Your application doesn't need to do anything special to work around NAT
except recognize that the client does not know its own IP address or
port. The server must infer the address and port of the client from the
IP header of the first packet.
I've looked at protocols like STUN, but there is so much overhead in
the final binary, that I'ld really rather not try and implement all of
that.
The purpose of STUN is to make a peer-to-peer connection between two
hosts that are both behind masquerading firewalls. STUN is tricky, but
depending on the firewalls, a connection can usually be made with the
help of an intermediary. If either of the peers has a public IP
address, STUN is an unnecessary complication.
Shane
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
