ClientSessionclass
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)
ClientSession
` object`
Subclass Tree
(none)
Global Objects
(none)
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
Properties
clientKey
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.
downloads
this client’s list of downloadable temporary files
ifdbTuid
the client’s IFDB user ID (a “TUID”), if logged in to IFDB
isAlive
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.
isPrimary
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.
lastEventTime
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.
pendingEvts
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.
pendingReqs
the list of pending event requests from this client
screenName
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.
storageSID
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.
uiPrefs
the UI preferences object for this session
Methods
addDownload (desc)
add a download to this client
allDownloads ( )
get a list of all of my downloadable files
broadcastDownload (desc)
broadcast a downloadable file to all clients
broadcastEvent (msg)
class method: broadcast an event message to all connected clients
cancelDownload (desc)
Cancel a downloadable file. Removes the file from the download list and notifies the client that the file is no longer available.
checkDisconnect ( )
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)
no description available
disconnectAll ( )
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)
Class method: Find a client session, given the session key or an HTTPRequest object.
flushEvents ( )
flush outstanding events for this client
getPrimary ( )
Get the primary session. This is the session for the original initiating user (the “host” in a multi-user game).
processQueues ( )
process the request and response queues
requestEvent (req)
receive an event request from the client
sendEvent (msg)
send an event to this client
sendKeepAlive ( )
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 ( )
set the default screen name for a client
shutdownWait (timeout)
wait for the queues to empty in preparation for shutting down
updateEventTime ( )
update the last event time for this client
TADS 3 Library Manual
Generated on 5/16/2013 from TADS version 3.1.3