[CF List] CF 0.95.6 Client discards commands under "load" - feature,
not bug
Mark Wedel
mwedel at scruznet.com
Thu Jun 29 23:09:05 CDT 2000
Good document.
Note that connection speed is not all that relevant. The bandwidth it takes to
send the commands to the server is minimal (maybe 30-40 bytes/command?
presuming a minimal usuable speed is probably 3 K/second, tht is a lot of
commands). And unless the command results in lots of output (map redraws or the
like), the incoming bandwidth should not be much of a factor.
Likewise, server speed only really comes in to play if the cpu on the server
systems gets maxed out. Possible on slow systems, but on fast systems, this is
fairly unlikely.
Client speed is relevant, but similarly, really only if the cpu gets maxed
out. One thing of major importance is the key repeat speed of the client.
As another note, if you bind multiple commands to one key (like the 10 searches
below), note that pressing that key would count as 10 commands as far as the
client & server are concerned - in other words, the client expands the key and
sends the actions to the server. So this can fill up that buffering quite a
bit.
Most servers use the 120 ms tick time (roughly 8/second). A player with speed
1.0 gets one action per tick. A player with 0.5 speed get 1 action every other
tick.
If you have your window size set to say 40, and your character speed is 0.5,
that is 80 ticks (or roughly 10 seconds) it will take for the server to process
all those buffered commands.
One thing that could be nice is to have commands that get sent no matter what
the windowing looks like. So for example, if the window is full (client will
send no more commands) yet the player invokes the word of recall spell, it would
still send that. Ideal solution would be for this to be set on a player by
player basis.
Ie, have some config file (or gui popup) with the list of commands and let the
player set which ones are 'always send' commands, and which ones can be
discarded. In theory, you could even get intermediate commands (if the queu is
less than half full, send it, otherwise don't).
Frank McKenney wrote:
>
>
Users with high-speed connections to relatively fast Crossfire servers
>
will probably not need the following information. However, those with
>
slower connections and/or slower servers may find it of interest.
>
>
--
>
>
Crossfire clients and servers are hosted on a variety of systems. The
>
client accepts commands from the user, pass them to the server, and
>
present the results of the server's response back to the user. Under
>
certain circumstances it is possible for the client to send commands to
>
the server faster than the server can respond to them; if this continues
>
long enough, commands will be buffered in the server and in the client
>
(not to mention the keystrokes in the client's host system keyboard
>
buffer) up to the limits of these buffers.
>
>
The rate at which "the pipe" fills depends on several factors,
>
including:
>
>
- How fast the user is typing,
>
- How "leveraged" any 'bound' keystrokes happen to be,
>
- The speed of the link between the client and the server,
>
- The basic speed of the Crossfire Server host machine, and
>
- How much of a load Server and host machine are experiencing.
>
>
The "leveraging" is an (oog!) key factor, since the Crossfire 'bind
>
command makes it possible to define a single key to execute multiple
>
commands. With a high leveraging factor (say, one key = 10 searches),
>
pressing this key rapidly or holding it down to generate repeat
>
keypresses continuously can easily generate commands from the client
>
faster than some servers can respond to them.
>
>
Used carelessly, this could be fatal. Imagine that you are "searching"
>
a stack of chests for traps. You press the 'S' key (which you've
>
defined to invoke 10 searches per keypress) and hold it down for several
>
seconds to make sure you don't miss any well-hidden traps. Suddenly a
>
Red Dragon appears... and you can't interrupt your searching. Foom!
>
You just became a crisped critter!
>
>
In CF 0.95.6, the client keeps track of the number of commands sent to
>
the server and the number of responses received. If the number of
>
outstanding commands exceeds a limit value (default of 10), the client
>
will start discarding repeats of movement and 'firing' commands
>
(including such things as skill use and spellcasting). The specifics
>
can be found in the send_command() function in player.c.
>
>
When commands are discarded, the Linux client writes
>
messages to stderr like the following:
>
>
Wont send command use_skill praying - window oversized 205 164
>
...
>
Wont send command search - window oversized 2 217
>
>
>From a user standpoint, the "command windowing" has advantages and
>
disadvantages. On the good side, it tries to keep the client's view of
>
the universe from getting too far ahead of the server's view (e.g. the
>
chest/Dragon example above). The down side is that if enough many
>
commands are queued quickly enough to overrun the window size, what one
>
enters is not necessarily what one gets back. My attempt to issue 50
>
'search' commands, for example, actually executed some number less than
>
that (as shown by the error message above)... with potentially painful
>
consequences.
>
>
Fortunately, the command window size is determined by the client. The
>
following describes how to turn this particular knob on the Linux client
>
(other clients may provide different mechanisms).
>
>
The 'help command describes two commands of interest:
>
>
'cwindow N sets the window size to N (1...127), and
>
'savedefaults creates a .crossfire/defaults file, which
>
will include the command_window setting.
>
>
In my case both the client and the server on the same machine, a 32 Mb
>
486DX4-100 with SuSE Linux 6.4. For the most part this works
>
acceptably, but until I cranked the 'cwindow setting up to 40 I was
>
losing a _lot_ of attempts to stack multiple 'use_skills praying'
>
commands. Even at 40, as you can see from the above error messages, I'm
>
not actually doing all the 'search'ing I _thought_ I was doing, so I'll
>
probably increase the setting to something in the 60-80 range and
>
monitor my stderr output.
>
>
Hope this helps.
>
>
--
>
>
My thanks to Mark Wedel, whose comments a few days back started my
>
research on this. However, I should point out that any typos,
>
misinterpretations, or misreadings of the Crossfire code are mine and
>
mine alone (;-).
>
>
Frank McKenney
>
>
Frank McKenney, McKenney Associates
>
Richmond, Virginia / (804) 320-4887
>
E-mail:
frank_mckenney at mindspring.com
>
_______________________________________________
>
crossfire-list mailing list
>
crossfire-list at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-list
More information about the crossfire
mailing list