* Copyright (c) 1999, 2006 Michael J. Roberts
* This file is part of TADS 3
* This header defines the tads-net intrinsic function set.
* The tads-net function set provides network input/output. In particular,
* this implements an HTTP server that can be used to implement a
* browser-based user interface. The network layer could also be used for
* other purposes, such as implementing a multi-user game server.
* The first step in setting up a network server is to create a suitable
* server object, such as an HTTPServer. The server opens a network port
* on the local machine and waits for incoming connection requests from
* clients, such as from Web browsers on remote machines. When a client
* connects to the server's port, the server creates a separate thread to
* handle the new connection, then goes back to listening for additional
* connections. The connection thread handles network communications with
* the client; when the client sends a request to the server, the thread
* posts an event message to the network message queue.
* The next step for the program, then, is simply to go into a loop reading
* and handling incoming network messages. Once the server is set up, the
* program is basically driven by the network client. Call netEvent() to
* read the next message, then interpret the contents, process the message,
* and send a reply. Once that's done, go back to the start of the loop to
* handle the next request message. The program continues running until a
* suitable network event occurs to terminate it, such as the user typing
* QUIT into the UI.
* tads-net - the TADS Network function set
* Connect to the Web UI client. This connects the Web browser client
* to the game's HTTP server. 'server' is the HTTPServer object where
* the Web UI is found, and 'path' is the URL path of the game's main
* UI start page. This will tell the client to navigate to the given
* start path on the given server.
* Web-based games must call this after starting the HTTP server that
* provides the game's Web UI. This should be called as quickly as
* possible after starting up, because clients might time out and miss
* the connection data if it takes too long to get this back to them.
* Read an event from the network message queue. When a listener
* receives a connection request from a client, it creates a network
* server thread to handle the connection; then when the server thread
* receives data from the client, it packages the data into an event
* message and places it in the queue. This function retrieves the
* next message from the queue.
* If 'timeout' is omitted or nil, the function waits indefinitely; it
* doesn't return until a network event occurs. If a timeout is given,
* it gives the maximum time in milliseconds that the function should
* wait for an event; if the timeout expires before any events arrive,
* the function returns a timeout event.
* The return value is a NetEvent instance describing the event.
* Get the local network host name. This is the name (or a name) that
* other computers can use to connect to this computer across the
* Some computers have multiple host names, since a single machine can
* have more than one network adapter. If this is the case, this
* function returns the default host name if there is such a concept,
* otherwise it just picks one of the names arbitrarily.
* If there's no host name at all, this returns nil.
* The host name returned here isn't usually a "global" name for the
* computer, but is a name that the local operating system recognizes
* as itself for networking purposes. In particular, this usually
* won't be a full internet "x.y.com" domain name. This name thus
* isn't something you can advertise to arbitrary other machines across
* the Internet and expect them to be able to connect. Instead, this
* name is primarily useful for telling the operating system which
* network adapter to use when opening a listening port. For example,
* you can use this name in the HTTPServer constructor.
* Get the local host's IP address. This is the IP address (or an IP
* address) that other computers can use to connect to this computer
* via the network. IP addresses are the basic addressing scheme of
* the Internet.
* Some computers have multiple IP addresses, since a single machine
* can have more than one network adapter. If this is the case, this
* function returns the default IP address if there is one, otherwise
* it selects one of the machine's IP addresses arbitrarily.
* If the IP address can't be retrieved (for example, because the
* machine has no network adapter installed), this returns nil.
* Get the URL to the storage server. When running in Web mode, the
* interpreter is generally configured to store files on a separate
* "storage server" rather than on the game server. This function
* retrieves the interpreter's configuration data and returns the
* storage server URL.
* 'resource' is a string giving the resource (page) name on the server
* that you wish to access. This can contain query parameters
* (introduced by a "?" symbol), if desired. The return value is the
* full URL to the requested page on the server.
* Get the host address that the user used to launch the game. For
* standard client/server TADS Web play, this is the network address
* that you should specify as the listening address when setting up the
* HTTPServer object.
* When we're operating in client/server mode, the interpreter is
* launched by an external Web server, in response to an incoming
* request from a client. In order to establish our own connection
* with the client, we need to know the address that the client used to
* connect to the external Web server in the first place. The Web
* server passes this address to the interpreter as part of the launch
* information, and the interpreter makes the address available to the
* TADS program here.
* If there's no launch address, this returns nil. This means that the
* user launched the interpreter directly, from the local desktop or
* command shell. In this case, it means that the user wants to run
* the game locally, rather than from a remote client machine. Simply
* use "localhost" as the networking binding address in this case.
* Send a network request to a remote server. This initiates
* processing the request and immediately returns; the process of
* setting up the network connection to the remote server, sending the
* request data, and receiving the reply proceeds asynchronously while
* the program continues running. When the request completes (or fails
* due to an error), a NetEvent of type NetEvReply is queued.
* 'id' is a user-defined identifier for the request. This can be any
* value, but is typically an object that you create to keep track of
* the request and process the reply. TADS doesn't use this value
* itself, but simply hangs onto it while the request is being
* processed, and then stores it in the NetEvent object generated when
* the request completes. This lets you relate the reply event back to
* the request, so that you know which request it applies to.
* 'url' is a string giving the URL of the resource. This starts with
* a protocol name that specifies which protocol to use. The possible
* protocols are:
* - HTTP: the URL has the form 'http://server:port/resource'. It can
* also start with 'https://' for a secure HTTP connection. The port
* number is optional; if omitted, the default port is 80 for regular
* HTTP, or 443 for HTTPS.
* Currently, the only protocol supported is HTTP. An error occurs if
* another protocol is specified.
* Additional parameters depend on the protocol.
* HTTP Additional Parameters:
* 'verb' - a string giving the HTTP verb for the request (GET, POST,
* HEAD, PUT, etc).
* 'options' - optional; a bitwise combination of NetReqXXX option
* flags specifying special settings. Omit this argument or pass 0 to
* use the default settings.
* 'headers' - optional; a string giving any custom headers to include
* with the request. The system automatically generates any required
* headers for the type of request, but you can add your own custom
* headers with this parameter. The headers must be specified using
* the standard 'name: value' format. Use '\r\n' to separate multiple
* headers. If you don't need to specify any custom headers, pass nil
* or simply omit this argument.
* 'body' - optional; a string or ByteArray giving the content body of
* the request, if any. This is suitable for verbs such as PUT and
* POST. For verbs that don't send any content with the request, pass
* nil or simply omit the argument.
* 'bodyType' - optional; a string giving the MIME type of the content
* body. If this is omitted, a default MIME type is assumed according
* to the type of 'body': for a string, "text/plain; charset=utf-8";
* for a ByteArray, "appliation/octet-stream".
* This routine has no return value, since the request is processed
* asynchronously. The result can't be determined until the
* corresponding NetEvReqReply event occurs, at which point you can
* inspect that NetEvent object to find out if the request was
* successful, and if so retrieve the reply data.
sendNetRequest(id, url, ...);
/* ------------------------------------------------------------------------ */
* sendNetRequest option flags for HTTP requests.
* DO NOT follow "redirect" (301) results. By default (i.e., without this
* option flag), if the server sends back a 301 HTTP status code
* ("permanently moved"), we'll automatically follow the link to the new
* location and return the result from that new request. This is
* transparent to the caller; the caller just sees the final result from
* the final server we're redirected to. If this flag is specified, we
* DON'T follow a redirection, but instead simply stop and return the 301
* result. The caller can inspect the reply headers to get the redirection
#define NetReqNoRedirect 0x0001
/* ------------------------------------------------------------------------ */
* Network event types. This value is used in the evType property of
* NetEvent objects to indicate the type of the event.
* Request event. This type of event contains a request from the network
* client. For example, for an HTTP client, the event contains an HTTP
* request, such as a GET. The request is represented as an object; the
* class depends on the type of server and request.
#define NetEvRequest 1
* Timeout. netEvent() returns this type of event when the interval
* expires before any actual network events occur.
#define NetEvTimeout 2
* Debugger interrupt. netEvent() returns this type of event when the user
* commands the debugger to interrupt the program and take control. If the
* program is waiting for a network event, this causes the netEvent() call
* to return with this type of event.
* In a normal event-loop type of program, you can simply ignore this event
* and loop back for a new event immediately. The purpose of this event
* type is to force netEvent() to stop waiting and return to the byte-code
* caller, so that the debugger can pause execution at a valid byte-code
* program location. Once that's accomplished, there's nothing more to do
* with this event type; simply discard it and get the next event when the
* user resumes execution.
#define NetEvDebugBreak 3
* UI Closed. This type of event occurs when the user manually closes the
* Web UI, ONLY in a stand-alone local configuration. This is the special
* configuration where the browser UI is integrated into the interpreter
* application, simulating the traditional TADS interpreter environment
* with the Web UI, and everything's running on a single machine. When the
* user closes the Web UI in this environment, the game should usually just
* terminate, since the user has effectively dismissed the application.
* In the true client/server configuration, where the user is running an
* ordinary Web browser on a separate machine, we have no way of knowing
* that the user has closed the browser window. The best we can detect is
* a dropped network connection, but we can't assume this is due to the
* window closing, because it could happen for other reasons (such as a
* temporary network interruption). In the full client/server
* configuration, we have to be more subtle in determining that the user
* intends to quit the application, generally with inactivity timers.
#define NetEvUIClose 4
* Network reply. This type of event occurs when a network request
* initiated by sendNetRequest() completes, or fails with an error. The
* event object contains the status of the request and, if successful, the
* result information sent back from the server.
#define NetEvReply 5
* Reply data transfer finished. This type of event occurs when an
* asynchronous reply to a request is completed. An asynchronous HTTP
* request reply can be sent with HTTPRequest.sendReplyAsync(). The event
* object contains information on whether or not the reply was successfully
* sent to the client. For HTTP transactions, this is largely advisory,
* since there's no recovery action the server can take when an error
* occurs sending a reply; there's no provision in HTTP for a server to
* initiate contact with a client, so it's up to the client to handle it,
* such as by retrying the request.
#define NetEvReplyDone 6
TADS 3 Library Manual
Generated on 5/16/2013 from TADS version 3.1.3