|
Message
LogSetOptions [–events on|off] [–keyevents on|off] [–clientclient on|off] [–comms on|off] [-signature on|off]
Originator
Client
Response
Info: Recording options: events on|off keyevents on|off clientclient on|off comms on|off signature on|off
SyntaxError: insufficient parameters to LogSetOptions
SyntaxError: invalid parameters to LogSetOptions
Response (immediate socket)
Success
Failure
Details
You may choose what class of events are written to the log:
Explicit messages from the client (sent with LogWrite) are always recorded.
–events: Event messages are recorded.
–keyevents: KeyEvent messages are recorded.
–clientclient: Client-to-client (ClientMessage:) communications are recorded.
–comms: All client–server communications are written (including events). Be warned: this can create large logs.
–signature: The log is digitally signed when it is closed. Be warned: this can pause the system briefly if the log is very long (see below).
At least one option must be specified. The new logging options are written to the log in full. For example:
2001-11-05,21:40.48,40927,Log,Recording options: events on keyevents off clientclient on comms on signature off
By default, signatures are on and all other options are off. The settings from LogSetOptions persist if you close the log and open another, or if you issue the command before opening a log.
PERFORMANCE NOTES (technical)
| 1. | If a client logs data at a very high rate, it may impact upon the system's performance. The act of writing to a disk log is conducted by the same thread that processes the same client's network communications. Therefore, if this thread spends a great deal of time writing to disk, it will impact the performance of the client whose log it is before it impacts the performance of the rest of the server (or of other clients) - though this will happen insofar as the whole computer starts to run slowly. |
| 2. | When a client closes itself, the client's thread digitally signs its log before the client is removed from the server. This may take a few moments if the log is large. After that, it informs the server that the client should be removed. Removal of the client from the system is performed by the server's main (user interface) thread. However, if the user deletes a client manually from the server's console, it will be the server's user interface thread that has to sign the log; consequently, the user interface may pause (and an hourglass be shown) while the server signs the log. This may also pause ongoing processing of all displays (since display processing is also handled by the server's user interface thread). Motto: don't delete clients by hand without thinking first. |
| 3. | When a client signs a log, the intensity of processing is such that brief (e.g. 60 ms) pauses may occur in polling. This is an unfortunate compromise; it is not possible, within one process (WhiskerServer.exe), to separate the thread priorities for log-signing and polling to a great enough extent. The choices are either (a) the signing thread priority is higher than optimal - polling continues perfectly and the computer freezes during signing, to the extent that the mouse doesn't work; (b) the polling priority is briefly lower than optimal - the computer remains perfectly usable and polling suffers slightly during signing. I've (RNC) chosen (b), as people always seem to get upset when their computers freeze for unknown periods of time. If you cannot afford even this pause, turn the signature off. |
Revision history
Implemented in WhiskerServer version 2.6.8.
|