[CF-Devel] Bug in cvs checkout on 09-Jan-2001?

Mark Wedel mwedel at scruz.net
Wed Jan 10 01:36:22 CST 2001


Michael Toennies wrote:

>
     
      The error comes because there is no "bye" or "logout" cmd. The server can't
     
     >
     
      determinate the difference between a broken connect or a client side closed
     
     >
     
      connect.
     
     
 Note that the server reports connections of all types, so even with a bye
command, you will still see a lot of connects/disconnects reported.  Now whether
this really needs to be logged is a different story - potentially not, as even
'bad' disconnects are not a problem on the server side of things but is instead
on the client.


>
     
      Also, iam not sure that the way i connect direct to the server is a good way
     
     >
     
      to
     
     >
     
      get the latency. The idea is of course to get the time the server really
     
     >
     
      need to
     
     >
     
      serve a single user. But when we have many users, the server can get dozens
     
     >
     
      of these
     
     >
     
      "ping connects" per seconds. I have no idea about th effects on server speed
     
     >
     
      or
     
     >
     
      connections.
     
     
 It certainly won't help.  I'm unsure of the actual speed concerns - I think
most of the work is done by the OS, but I'm not sure how costly things like the
accept is.  Certainly, for each active connection, the server has to monitor it
for input, and if it gets input, do that action, but that should be fairly
trivial unless you get a lot of clients out there, which could happen.  That is
probably the bigger concern, as hundred/thousands of clients
connecting/disconnecting probably will have performance problems.  I'm not sure
how soon that will be an issue.


>
     
      A normal ping will also work, but only show you the connect to the used
     
     >
     
      server,
     
     >
     
      not the real cf speed. And this can change when much user are online or the
     
     >
     
      server thread runs with low priority.
     
     
 Of course, your current method only shows statistics as when the player is
determining where to log in, correct?  So that data is only valid for that time
being.

 I would guess that the general case is that a server can handle a certain
number of players/connections adequately, but once it gets beyond some number,
the performance really starts to nosedive (especially if the performance issue
is bandwidth and not say cpu time).

 The problem that even with pings is once again, if there are thousands of
clients out there sending ping requests, while it doesn't harm the actual
crossfire server, thousands of pings would start to take up some significant
amount of bandwidth.

 So I can't really come up with a good solution without knowing the potential
user base.  I would guess if the user base gets significantly large, even the
load on the metaserver could start becoming significant.

    
    


More information about the crossfire mailing list