ChatScript Client Server Chat Script Manual

ChatScript%20ClientServer%20Manual

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 13

Scroll down to view the document on your mobile browser.
ChatScript Client/Server Manual© Bruce Wilcox, gowilcox@gmail.com brilligunderstanding.comRevision 7/31/2016 cs6.7aTable of ContentsRunning the serverUnique User NamesChatScript protocolCommunicating with the ServerTesting the serverRevising a live serverRevising a topicPreparing for compiling on a serverTesting for server presenceServer crashes and cronCPU vs IO boundMemory issues with multiple servers on a machineCommands affecting the serverCommand AuthorizationCommand line parametersRESTful serverWhile the system defaults to running as a stand-alone chatbot under Windows, when rununder LINUX it defaults to being a server.Nominally (meaning depending on hardware and what your bot does) ChatScript canprocess a volley on a single core in 10 milliseconds on a slow machine, thus handling 100volleys every second from different users using one core. A human-human volley isoften around 15 seconds, so handling 1000 simultaneous users with a single core slowserver is not unreasonable.The fastest server OS for ChatScript is Linux. The Mac tends to misfire in the OS itselfwith heavy client loads. Windows is a much slower server in general. And Linux versionof CS has support for forking chatscript (no such support under Windows), so you canrun a fork of the engine on every core, saturating cpu processing to the max while stillserving a single port. Speedup is nearly linear per core added.Running the ServerWhen you run the Mac/LINUX program, it defaults to server mode, port 1024. To runthe server under Windows you must give it a command line parameter specifying a port.There are various command line parameters to affect behavior, described at the end.1
Unique User NamesChatScript maintains an independent history with each user-bot combination in a singlefile in the USER's directory. It is nominally up to you to define some unique name foreach user. There is no login validation service provided by ChatScript; that is yourresponsibility. Some simple things which ChatScript supports directly are:1. If the login name is “.” , the system will assign a user name of the IP address itreceives. This doesn't work from localhost nor will it work if you have a server ofyour own relaying between the client and the ChatScript server (since the IPaddress will always be of your relay server).2. If the login name is “guest”, the system will assign a user name of guestconcatenated with the IP address. You could also use the user's email address as a login id. ChatScript will automatically convert periods and @ in a user's name to _ , so a login like “gowilcox@gmail.com” will become gowilcox_gmail_com. Likewise logging in as guestwill result in something like “guest_123_124_155_12”.Of course, if the user eventually comes back some other day on a different IP address,they lose their history. Can’t be helped. And you end up with dead files.Communicating with the ServerThe client webpage/program connects on a socket to the IP and port of the server. If youare coming from a webpage, the webpage must establish the socket. The system does notuse HTTP. HTTP is an agreement on what port to use (a standard http port) and whatmessage protocols look like to the HTTP server. Similarly ChatScript uses an agreementon what port to use (but you get to specify the port) and what the message protocols looklike.And, each communication is a one-shot deal. The socket is made, the client sends amessage to the server, the server sends data back, AND CLOSES THE CONNECTION.Given that potentially thousands of users may be using the server at the same time, it isundesirable for it to try to maintain that many open sockets. If for some reason you needto maintain a permanent connection to a client, you can write an intermediary serverprogram that has a permanent socket to the client, and relays messages back and forthbetween the client and the ChatScript server.This is also what you would do if you wanted ChatScript to “push” unsolicited messagesto the client. Your intermediary server can use timeouts to decide to send a specificmessage to the ChatScript server, and then relay the result back to the client as anunsolicited output. Similarly, your intermediate server might receive variousasynchronous events and signals, and can pass requests to ChatScript at that time andpass the result back to a permanently connected client.2

Navigation menu