[ENet-discuss] NAT and Enet

[Charlie Sibbach]

I wrote a long rebuttal to this before I finally realized that you're
absolutely correct. I realized last night that I only need a single
static IP, for the login server. The zone servers can simply report
their IP to central and maintain a table of everybody (which was
already planned, but it just has to be a bit more dynamic now). Now
the trick will be deciding on a suitable authorization token system.

One of our driving design philosophies has been to make the client
side as dumb as possible; there is nothing that it "decides" on, or is
trusted with. All the server wants from it are directions- what
buttons are pushed. The server will tell it the results. The client is
dumb, but there's a lot of prediction it does, it's just that whatever
the server tells it is gospel. This is one of the reasons I chose
enet, most of our trafic can be fast but unreliable UDP, but I can
send some reliable data (keyframes) on the same line.

This is getting off topic, but can I propose a solution here for
consensus? The client connects to the login server, which validates
the client's info. The login server then sends the client's IP to the
zone server (ZS), and the zone server's IP to the client. The client
connects to the zone server, which only accepts the connection if the
IPs match. The ZS trusts info coming from the login server.
The problem would be IP spoofing as the login server, which would make
the system vulnerable to abuse. The various servers could pass a key
amongst themselves- the bandwidth between them is considerably greater
than between the servers and the client. We're aiming for the modem
market, so great steps are being taken to reduce data sent to the
client to an absolute minimum- if the client has a key it needs to
send that's an extra 4 bytes minimum per packet, and somebody could
crack the key generation system.  Damn world of today; to many
security woes!

Does this sound like a workable solution?

On 6/7/05, Brian Hook <hook_l at bookofhook.com> wrote:
> On Tue, 7 Jun 2005 16:35:16 -0700, Charlie Sibbach wrote:
> > passing the incoming client's IP address to the zone server, which
> > will make an outward-bound connection to the client.
> 
> You probably do not want to do this, since you don't want to force a
> client to open a port in order to connect _out_ to a game.
> 
> I would instead have the login server send back a reconnect message of
> some kind to the client, telling it to connect to a different port and
> using some kind of auth token  to validate that internally.
> 
> Brian
> 
> 
> 
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
> 


-- 
~Charlie