Hand-offs
Author
I''m trying to figure out how a server will hand a client off to another server.
Here is the scenario. Client boots up and requests a connection (sends username and password to a connection server via UDP packet). Connection server reads the packet, consults a database to determine if username and password are correct and if so it sends an OK reply back to the client. Along with the OK, the client recieves a list of available servers. Client selects server 3. Does this selection go back through the connection server (CS) and then the CS lets the actual world server know that it''s OK to exchange info with the client? Or does the client simply now have access to the world server because it has passed already through the CS for password checking?
If the CS handles initial communication with the world server it would be like this. There is already a connection between the two (well maybe not an actual connection for UDP). The CS would tell the world server "Client X at IP XXX.XXX.XXX.XXX on port YYYY is ok to communicate with and then let the server send relevant information directly to the client?
This would stop someone from just getting access to a game world via IP address and port number because the initial hookup would only come from the CS and the client would have no way to access the world server without the CS first telling the World server to begin communication with the client (add valid clients to some sort of list). If client looses connection to world server then the whole process will have to be restarted from a previous place (before the connection server probably).
Obviously this is in regards to MMO server/client setups. Anyone know if this is on the right track for this sort of thing? Mostly I''m working with flowcharts (no actual code) until I get a system that seems to work on paper. I''ll be happy to upload my charts somewhere when I get something decent done. So far they are a great help for desiging.
Thanks for any input or criticism,
Webby
The client needs to initiate a connection out to the server IP first, by sending a packet. If your servers are on separate IPs. Otherwise the client firewalls will cause your game to not work.
Author
Hmmm. So there needs to be another step involved.
Client would recieve the IP and port number of the world server from the CS ONLY after the CS has notified the world server that a client will be sending packets to it. This would set the incoming connection from X flag on the world server. After that the client would send the "I''m the new guy" packet to the world server (possible with a validation code attached originating from the CS)? Then communication between world and client would as be normal. Sound like it would work? I''m assuming the same kind of process would be required when say a client does something in the game that would require switching to another physical world server (something similar to zoning)? Then just let the world server handle setting up the connection between the client and the new world server? Or would the old world server refer the client back to the connection server? Probably the first method for efficiency as the old world server would simply have to do 2 extra things.
1)Inform the new world server of an incoming connection from a specified IP and port(the client).
2) Send the new IP and port# to the client.
Then let the client and new world server tango as usual.
This doesn''t seem too difficult. Thanks, keep the hints coming this was really helpful
Webby
Client would recieve the IP and port number of the world server from the CS ONLY after the CS has notified the world server that a client will be sending packets to it. This would set the incoming connection from X flag on the world server. After that the client would send the "I''m the new guy" packet to the world server (possible with a validation code attached originating from the CS)? Then communication between world and client would as be normal. Sound like it would work? I''m assuming the same kind of process would be required when say a client does something in the game that would require switching to another physical world server (something similar to zoning)? Then just let the world server handle setting up the connection between the client and the new world server? Or would the old world server refer the client back to the connection server? Probably the first method for efficiency as the old world server would simply have to do 2 extra things.
1)Inform the new world server of an incoming connection from a specified IP and port(the client).
2) Send the new IP and port# to the client.
Then let the client and new world server tango as usual.
This doesn''t seem too difficult. Thanks, keep the hints coming this was really helpful
Webby
Here''s how my multi-user server system works. I use TCP, but it can easily be adapted to use a FSM and UDP.
1. Client opens connection to the "primary" server (connection server in your case)
2. Server performs authentication; will either forcibly terminate the connection if authentication failed, or send a "welcome to the system" packet.
3. The client, now in the system, is responsible for requesting an actual server to talk to. This is done with another packet. (My protocols and handshakes are very complex, but in general quite secure) Taking this route just "feels neater" IMHO, but it has no real advantages that I can think of.
4. The server sends the list of possible servers (in my case, this list includes the primary server, because its actually more of a clustering system than anything else). The client then picks one and notifies the gateway server of its choice.
5. The gateway then sends a packet to the chosen server informing it that a client wants to connect. It is easy to have the separate server make sure that ONLY packets coming from the gateway server are accepted; this will make your system much more secure. The chosen server then sets an internal state flag that says "client * is now allowed to connect." It then sends an acknowledgement to the gateway server, which relays this to the client.
6. The client now sends a connection request to the chosen server, and begins processing as normal.
This approach is a lot more secure than simple validation codes, because a validation code can be forged or broken. However, if you have all of your servers running securely (either on a LAN or via IP tunneling if at all possible) then the system is much harder to get into. First of all, the hacker has no way to sniff packets in between the gateway server and the rest. Make this protocol secure -- I use 1024-bit (128-byte) validation codes, but only in between the servers. The validation codes are never sent to the client, meaning they can''t be hacked. Secondly, the only way a hacker could possibly fool the (hopefully secure) server into setting its "client may connect" flag is if the hacker correctly spoofs the validation handshake. If your handshake is nice and obfuscated, and uses a long key (preferably randomly choosing one of many keys), the chances of a hacker successfully spoofing a packet is basically zero. Plus, since the spoofed request will be returned to the gateway server, you can monitor incoming traffic to the gateway server and easily indentify packets that aren''t coming from legitimate connections -- a free hacker trap.
Good luck with your setup -- it''s a long and bumpy road, but extremely rewarding in the end.
1. Client opens connection to the "primary" server (connection server in your case)
2. Server performs authentication; will either forcibly terminate the connection if authentication failed, or send a "welcome to the system" packet.
3. The client, now in the system, is responsible for requesting an actual server to talk to. This is done with another packet. (My protocols and handshakes are very complex, but in general quite secure) Taking this route just "feels neater" IMHO, but it has no real advantages that I can think of.
4. The server sends the list of possible servers (in my case, this list includes the primary server, because its actually more of a clustering system than anything else). The client then picks one and notifies the gateway server of its choice.
5. The gateway then sends a packet to the chosen server informing it that a client wants to connect. It is easy to have the separate server make sure that ONLY packets coming from the gateway server are accepted; this will make your system much more secure. The chosen server then sets an internal state flag that says "client * is now allowed to connect." It then sends an acknowledgement to the gateway server, which relays this to the client.
6. The client now sends a connection request to the chosen server, and begins processing as normal.
This approach is a lot more secure than simple validation codes, because a validation code can be forged or broken. However, if you have all of your servers running securely (either on a LAN or via IP tunneling if at all possible) then the system is much harder to get into. First of all, the hacker has no way to sniff packets in between the gateway server and the rest. Make this protocol secure -- I use 1024-bit (128-byte) validation codes, but only in between the servers. The validation codes are never sent to the client, meaning they can''t be hacked. Secondly, the only way a hacker could possibly fool the (hopefully secure) server into setting its "client may connect" flag is if the hacker correctly spoofs the validation handshake. If your handshake is nice and obfuscated, and uses a long key (preferably randomly choosing one of many keys), the chances of a hacker successfully spoofing a packet is basically zero. Plus, since the spoofed request will be returned to the gateway server, you can monitor incoming traffic to the gateway server and easily indentify packets that aren''t coming from legitimate connections -- a free hacker trap.
Good luck with your setup -- it''s a long and bumpy road, but extremely rewarding in the end.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
