Client session. This represents a connection to one browser (or other client application). Each browser client is a separate session, so we create one instance of this class per connected browser. Note that browser instances don't necessarily represent different users - a single user could open multiple browser windows on the same server.

We identify each browser instance via a session cookie, which we establish when the client connects. The browser sends the cookie with each subsequent request, allowing us to tie the request to the browser session we previously set up.

class ClientSession :   object

Superclass Tree   (in declaration order)


Subclass Tree  


Global Objects  


Summary of Properties  

clientKey  downloads  ifdbTuid  isAlive  isPrimary  lastEventTime  pendingEvts  pendingReqs  screenName  storageSID  uiPrefs 

Summary of Methods  

addDownload  allDownloads  broadcastDownload  broadcastEvent  cancelDownload  checkDisconnect  construct  disconnectAll  find  flushEvents  getPrimary  processQueues  requestEvent  sendEvent  sendKeepAlive  setDefaultScreenName  shutdownWait  updateEventTime 



The client session key. This identifies the client across requests. We send this to the client as a cookie when they connect, so we get it back on each request.

this client's list of downloadable temporary files

the client's IFDB user ID (a "TUID"), if logged in to IFDB

Is this session alive? When we detect that the client has disconnected, we'll set this to nil. When waiting for a client in a modal event loop, this can be used to terminate the wait if the client disconnects.

Am I the primary player? This is true if the player connected using the primary session key. Collaborative players join through the separate collaborative session key.

Last request time, in system ticks (ms). We use this to determine how long it's been since we've heard from the client, for timeout purposes. This is updated any time we receive a command or event request from the client, and each time we successfully send an event reply.

The client's event queue. When a server-to-client event occurs, we post it to each current client's queue. When the client sends a get-event request, we satisfy it out of this queue.

the list of pending event requests from this client

The client's "screen name" - this is the user-visible name that we'll show other users to identify commands and chat messages entered by this client.

The storage server session key for the user connected to this session, if any. We can have multiple users logged in to the game in collaborative play mode, each with their own separate storage server session. This allows each user to have their own private preference settings, saved games, etc.

the UI preferences object for this session


addDownload (desc)webui.t[597]

add a download to this client

allDownloads ( )webui.t[622]
get a list of all of my downloadable files

broadcastDownload (desc)webui.t[590]
broadcast a downloadable file to all clients

broadcastEvent (msg)webui.t[478]
class method: broadcast an event message to all connected clients

cancelDownload (desc)webui.t[607]
Cancel a downloadable file. Removes the file from the download list and notifies the client that the file is no longer available.

checkDisconnect ( )webui.t[693]
Check to see if the client is still alive. If the client has no pending event requests, and we haven't heard from the client in more than the client session timeout interval, assume the client is no longer connected and kill the session object.

This should be called whenever a sending a reply to a request fails with a Socket Disconnect exception. We also run this periodically during routine housekeeping to check for clients that haven't even bothered to send a request.

construct (skey, ssid)webui.t[380]
no description available

disconnectAll ( )webui.t[714]
Class method: forcibly disconnect all clients. This simply deletes the list of active clients and deletes any pending events in their queues. This doesn't actually terminate their network connections, but simply clears out any pending work for each client that we've initiated on the server side.

find (key)webui.t[727]
Class method: Find a client session, given the session key or an HTTPRequest object.

flushEvents ( )webui.t[501]
flush outstanding events for this client

getPrimary ( )webui.t[755]
Get the primary session. This is the session for the original initiating user (the "host" in a multi-user game).

processQueues ( )webui.t[625]
process the request and response queues

requestEvent (req)webui.t[493]
receive an event request from the client

sendEvent (msg)webui.t[485]
send an event to this client

sendKeepAlive ( )webui.t[553]
Send a keep-alive reply to each pending request from this client that's been waiting for longer than the timeout interval.

Javascript clients in principle will wait indefinitely for an XmlHttpRequest to complete, but in practice browsers tend to set fairly long but finite time limits. If the time limit is exceeded for a request, the client will fail the request with an error. To prevent this, our main event loop (processNetRequests) periodically calls this routine if no other events have occurred recently. We'll clear out the pending event request queue for each client by sending a no-op reply to each event. This tells the client that the server is still alive and connected but has nothing new to report.

setDefaultScreenName ( )webui.t[409]
set the default screen name for a client

shutdownWait (timeout)webui.t[675]
wait for the queues to empty in preparation for shutting down

updateEventTime ( )webui.t[475]
update the last event time for this client

TADS 3 Library Manual
Generated on 5/16/2013 from TADS version 3.1.3