[CF-Devel] server problems

[Mark Wedel]

 Moved back to mailing list as this may have some broader interest.

Michael Toennies wrote:
>
     
     
     >
     
      H, one problem is, that the server will run without getting a version cmd
     
     >
     
      from client.
     
     >
     
      Is this a problem or not? We can ignore it, implicit setting  "base" version
     
     >
     
      or we
     
     >
     
      can assume it as "broken" connect.
     
     
 At this point, probably ignore it.  For these interim releases, I don't really
want to have to worry about the version information and trying to figure it
out.  The setup command is probably the way to go for any future enhancements,
and at some point, the versioncmd could probably go away.  The only issue right
now might be if some people have really old clients.

>
     
     
     >
     
      For the version itself it has no effect, but the server determinate for
     
     >
     
      example the face/face1
     
     >
     
      cmd with it.
     
     
 Yeah - the version stuff was useful for transitional information.  As part of
the server cleanup, at some point, only the most recent version of some commands
will be supported.  This reduces codes, which typically means fewer bugs.  And
if the client knows it only needs to support the latest command, that is less
work on that side also.


>
     
      This works fine, but perhaps we should have here a stronger, server side
     
     >
     
      directed login procedure?
     
     
 Really the handling of much the login and character creation should be moved to
the client.  For example:

Client connects to server, does negotiating (making sure it can play on this
server).

Client prompts for user name and password.  It then sends this to server in one
protocol command.

 If authentication is successful, go to play game.  If not, confirmation of
password is requested (player may have entered password incorrectly of course). 
For this, the server should actually just use some state code, so that the
client can key in on this easily.  Alternately, you could have something like:

C->S: login <name> <password>
C->S: newplayer <name> <password>

 In the second case, the server has already double checked the password, and
sends the newplayer after the player has confirmed.  The advantage this has is
that it removes some of the state tracking from the server.

 Also, the the stat stuff should be redone.  Instead of having the player cycle
through swap and the yes/no, it would be something like:

S->C: newplayer_stats 18 15 14 13 12 11 10
C->S: newplayer_stats 10 18 15 32 12 11 14 (player has re-ordered them, but this
is all done on the client), or
C->S: newplayer_stats roll_again

 IMO other than simplifying the server by having the client deal with this, it
also means that the client is free to be more intelligent about menus or
whatever else that it shows up.  The only disadvantage here is that the player
won't necessarily be able to see how the change of strength and int affects some
abilities. 

>
     
      Giving the server here more "control" will help avoid abusing programms
     
     >
     
      (which perhaps try to fload
     
     >
     
      the server with senseless packets) or broken logins. He can then kill this
     
     >
     
      connects fast. When we
     
     >
     
      get more player, this makes alot sense.
     
     
 Some things will always be hard to deal with.  Certainly some timeout should
probably be in order (must log in within 5 minutes or the like) - doing that
would not be hard.  Trying to prevent floods is more difficult - it strikes me
that most services that listen to ports can conceivably be flooded (http,
sendmail, etc).  Perhaps adding some memory of hosts in the last X amount of
time that appeared abusive automatically get put into the deny file or the
like.  I'd also have to double check, but the ban file should have simple
matching for ip addresses, and if a banned ip address shows up, server closes
connection before even talking to it.