There are two elements to setting up the session. First, we need to set the program session key as a cookie. The client obtains this from the registration mechanism, whose purpose is to launch the game program and send the connection information back to the client. The client sends this to us in the form of a URL parameter, TADS_session. This key is essentially for authentication, to make sure that the client that we're talking to is actually the client that launched the program: only that client would be able to get the key, because we invent it and send it to the registrar, and the registrar only sends it back to the client session it's already established on its end. This prevents port scanners from finding our open port and trying to crawl our "site" or otherwise access our services.
The second setup element is to create a client session key. Whereas the program session key is for our entire service, the client session key is specific to this one connection. If the user opens two browser windows on this server, each browser needs its own separate client session so that we can tell the traffic apart. The client session key is simply another random key we generate, and again we pass it back to the client in a cookie.
The reason we set cookies for both of these session keys is that it lets the client pass the information back to us on subsequent requests without having to encode another parameter in every URL. We set session cookies in both cases; the program session is for authentication purposes and so we don't want it to be stored or shared, and the client session key is explicitly to identify this one browser session, so it obviously shouldn't be shared across browser instances or sessions.
Note that instances should always provide a string (as opposed to a regular expression) for the virtual path (the 'vpath' property). We have to send the path to the browser UI as part of the connection information, so we need a string we can send rather than a pattern to match.
WebResourceInit : object