You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<li><ahref="ChatScript-ClientServer-Manual.html#memory-issues-with-multiple-servers-on-a-machine">Memory issues with multiple servers on a machine</a></li>
31
31
<li><ahref="ChatScript-ClientServer-Manual.html#commands-affecting-the-server">Commands affecting the server</a></li>
@@ -82,6 +81,9 @@ <h1 id="server-crashes-cron">Server Crashes & cron</h1>
82
81
<p>Be advised that ChatScript assumes the current directory is the one the executable is in and accesses its data relative to that. For cron this means you want an entry like:</p>
83
82
<pre><code>0,5,10,15,20,25,30,35,40,45,50,55 * * * * cd /home/bruce/ChatScript;
<p>CS user or server logs are never written to anything other than local filesystem. A server log could in theory be written remote to a database since it is done as a single log line, but user logs can involve tracing, which must go to local fileserver since the log is written incrementally within a line and there would be inordinate network traffic.</p>
86
+
<p>Still, for server logs it is a constantly increasing record count and performance would suffer significantly so logs go to the local filesystem and you have to get logs from the local machine(s). This is what they do at Amazon and they have tools to yank logs from all deployed servers.</p>
85
87
<h1id="cpu-vs-io-bound">CPU vs IO bound</h1>
86
88
<p>The ChatScript server consists of a main thread to handle computing a response, a thread to accept incoming connections, and threads for each connection spawned. The connection threads handle reading the message from the user, getting the attention of the main thread to get a response, and then passing that response back to the user. Any logging is normally done from the connection threads, so the main server is free to spend all its effort handling volleys.</p>
87
89
<p>Under a full load of users, the main thread will nominally be always busy and the system CPU bound as a consequence. However, the main thread must also read and write user data for each volley. That may slow things down and make the system IO bound if there are lots and lots of user files around and the system is using cloud-based files instead of local ones. This will lower thruput significantly. It can be compensated for by locally caching active user data. There is a parameter to tell the server to track some number of users in memory. It will write out those memory copies periodically, but obviously if the server crashes, some users may be 50 volleys out of date.</p>
<p>An authorization of <code>all</code> allows everyone. See also <code>authorize=</code> command line parameter and nodebug parameter.</p>
114
-
<h1id="command-line-parameters">Command Line Parameters</h1>
115
-
<p>Either Mac/LINUX or Windows versions accept the following command line args:</p>
116
-
<h2id="server-or-not">Server or Not</h2>
117
-
<pre><code>port=xxx</code></pre>
118
-
<p>This tells the system to be a server and to use the given numeric port. You must do this to tell Windows to run as a server. The standard port is 1024 but you can use any port.</p>
119
-
<pre><code>local</code></pre>
120
-
<p>The opposite of the port command, this says run the program as a stand-alone system, not as a server.</p>
121
-
<pre><code>interface=127.0.0.1</code></pre>
122
-
<p>By default the value is <code>0.0.0.0</code> and the system directly uses a port that may be open to the internet. You can set the interface to a different value and it will set the local port of the TCP connection to what you designate.</p>
123
-
<h1id="user-facts">User Facts</h1>
124
-
<p>Scripts can direct the system to store individualized data for a user in the user's topic file in USERS. It can store user variables (<code>$xxx</code>) or facts. Since variables hold only a single piece of information a script already controls how many of those there are. But facts can be arbitrarily created by a script and there is no natural limit. As these all take up room in the user's file, affecting how long it takes to process a volley (due to the time it takes to load and write back a topic file), you may want to limit how many facts each user can have written. This is unrelated to universal facts the system has at its permanent disposal as part of the base system.</p>
125
-
<pre><code>fact=xxxx</code></pre>
126
-
<p>This limits the user to only the xxxx most recent facts created by his interactions. The default is <code>800000</code> which is HUGE. It's also meaningless if you don't have scripts that write facts.</p>
127
-
<h2id="user-caching">User Caching</h2>
128
-
<p>Each user is tracked via their topic file in USERS. The system must load it and write it back for each volley and in some cases will become I/O bound as a result (particularly if the filesystem is not local).</p>
129
-
<p>You can direct the system to keep a cache in memory of recent users, to reduce the I/O volume. It will still write out data periodically, but not every volley. Of course if you do this and the server crashes, writebacks may not have happened and some system rememberance of user interaction will be lost.</p>
130
-
<p>Of course if the system crashes, user's may not think it unusually that the chatbot forgot some of what happened. By default, the system automatically writes to disk every volley, If you use a different value, a user file will never be more out of date than that.</p>
131
-
<pre><code>cache=20
132
-
cache=20x1</code></pre>
133
-
<p>This specifies how many users can be cached in memory and how big the cache block in kb should be for a user. The default block size is <code>50</code> (50,000 bytes). User files typically are under 20,000 bytes.</p>
134
-
<p>If a file is too big for the block, it will just have to write directly to and from the filesystem. The default cache count is 1, telling how many users to cache at once, but you can explicitly set how many users get cached with the number after the "x". If the second number is 0, then no caching is done and users have no data saved. They remember nothing from volley to volley.</p>
135
-
<p>Do not use caching with fork. The forks will be hiding user data from each other.</p>
136
-
<pre><code>save=n</code></pre>
137
-
<p>This specifies how many volleys should elapse before a cached user is saved to disk. Default is 1. A value of 0 not only causes a user's data to be written out every volley, but also causes the user record to be dropped from the cache, so it is read back in every time it is needed (handy when running multi-core copies of chatscript off the same port).</p>
138
-
<p>Note, if you change the default to a number higher than 1, you should always use <code>:quit</code> to end a server. Merely killing the process may result in loss of the most recent user activity.</p>
139
-
<h1id="access-to-server-machine-itself">Access to server machine itself</h1>
140
-
<pre><code>sandbox</code></pre>
141
-
<p>If the engine is not allowed to alter the server machine other than through the standard ChatScript directories, you can start it with the parameter <code>sandbox</code> which disables Export and System calls.</p>
142
-
<pre><code>nodebug</code></pre>
143
-
<p>Users may not issue debug commands (regardless of authorizations). Scripts can still do so.</p>
144
-
<pre><code>authorize="" bunch of authorizations ""</code></pre>
145
-
<p>The contents of the string are just like the contents of the authorizations file for the server. Each entry separated from the other by a space. This list is checked first. If it fails to authorize AND there is a file, then the file will be checked also. Otherwise authorization is denied.</p>
146
-
<h1id="logging-or-not">Logging or Not</h1>
147
-
<p>In stand-alone mode the system logs what a user says with a bot in the USERS folder. It can also do this in server mode. It can also log what the server itself does. But logging slows down the system. Particularly if you have an intervening server running and it is logging things, you may have no use whatsoever for ChatScript's logging.</p>
148
-
<pre><code>Userlog</code></pre>
149
-
<p>Store a user-bot log in USERS directory. Stand-alone default if unspecified.</p>
150
-
<pre><code>Nouserlog</code></pre>
151
-
<p>Don't store a user-bot log. Server default if unspecified.</p>
152
-
<pre><code>Serverlog</code></pre>
153
-
<p>Write a server log. Server default if unspecified. The server log will be put into the LOGS directory under serverlogxxx.txt where xxx is the port.</p>
154
-
<pre><code>Noserverprelog</code></pre>
155
-
<p>Normally CS writes of a copy of input before server begins work on it to server log. Helps see what crashed the server (since if it crashes you get no log entry). This turns it off to improve performance.</p>
156
-
<pre><code>Serverctrlz</code></pre>
157
-
<p>Have server terminate its output with 0x00 0xfe 0xff as a verification the client received the entire message, since without sending to server, client cannot be positive the connection wasn't broken somewhere and await more input forever.</p>
158
-
<pre><code>Noserverlog</code></pre>
159
-
<p>Don't write a server log.</p>
160
-
<pre><code>Fork=n</code></pre>
161
-
<p>If using LINUX EVSERVER, you can request extra copies of ChatScript (to run on each core for example). n specifies how many additional copies of ChatScript to launch.</p>
162
-
<pre><code>Serverretry</code></pre>
163
-
<p>Allows <code>:retry</code> to work from a server - don't use this except for testing a single-person on a server as it slows down the server.</p>
164
-
<h1id="no-such-bot-specific---nosuchbotrestarttrue">No such bot-specific - nosuchbotrestart=true</h1>
165
-
<p>If the system does not recognize the bot name requested, it can automatically restart a server (on the presumption that something got damaged). If you don't expect no such bot to happen, you can enable this restart using <code>nosuchbotrestart=true</code>. Default is false.</p>
166
-
<h2id="testing-a-server">Testing a server</h2>
167
-
<p>There are various configurations for having an instance be a client to test a server.</p>
168
-
<pre><code>client=xxxx:yyyy</code></pre>
169
-
<p>This says be a client to test a remote server at IP xxxx and port yyyy. You will be able to "login" to this client and then send and receive messages with a server.</p>
170
-
<pre><code>client=localhost:yyyy</code></pre>
171
-
<p>This says be a client to test a local server on port yyyy. Similar to above.</p>
172
-
<pre><code>Load=1</code></pre>
173
-
<p>This creates a localhost client that constantly sends messages to a server. Works its way through <code>REGRESS/bigregress.txt</code> as its input (over 100K messages). Can assign different numbers to create different loading clients (e.g., load=10 creates 10 clients).</p>
174
-
<pre><code>Dual</code></pre>
175
-
<p>Yet another client. But this one feeds the output of the server back as input for the next round. There are also command line parameters for controlling memory usage which are not specific to being a server.</p>
176
116
<h1id="cs-as-an-embedded-client">CS as an embedded Client</h1>
177
117
<p>Building a web-based interface to ChatScript is different from building an app involving ChatScript. In the web-based version, the ChatScript engine will always be a server on a reasonably powerful machine and have available the full resources of the web. In building an app-based NLP application with ChatScript, there are two general architectures, embeed-based and server-based. Embedded based is described in the External communcations manual.</p>
<li><p>Use encrypt= and decrypt= command line parameters.</p></li>
211
151
<li><p>Use default system or roll your own encryption in privatecode.</p></li>
212
152
</ol>
213
-
<p>Encryption applies to user topic files and long term memory files (^export and ^import). The built-in encryption method calls an external api server using json to perform encryption and decryption, passing the server urls provided by encrypt= and decrypt= command line parameters. The routines will add in the user's login id if you use %s in the command line parameters. Eg.,</p>
153
+
<p>Encryption applies to user topic files and long term memory files (^export and ^import). The built-in encryption method calls an external api server using json to perform encryption and decryption, passing the server urls provided by <code>encrypt=</code> and <code>decrypt=</code> and <code>ltmencrypt</code> and <code>userencrypt</code> command line parameters. The routines will add in the user's login id if you use %s in the command line parameters. Eg.,</p>
<p>To roll your own, you have to define routines in private code that encrypt and decrypt (see examples in os.cpp) and on private initialization override the default variables controlling userFileSystem.encrypt and userFileSystem.decrypt.</p>
0 commit comments