What happens on the server

The DSJ server provides a visual user interface to read and write data and configuration files which are stored on disk. All the configuration files are text files that you can edit with any text editor; however, the files are read only during startup, or when changes are made through the user interface. The files are rewritten whenever you choose OK in the corresponding dialog box.

This section describes the automated processes of the DSJ server, what it does during startup, and how it handles client connections.

DSJ server startup

When the DSJ server starts, it performs the following tasks, not necessarily in this order:

• The server scans the directory specified by the JREDirectories property, checking each subdirectory for a JRE that it can deploy to a client. If it finds a jreinfo.dsj file, it assumes that the directory has been processed. If not, it checks to see if that subdirectory contains both \Bin and \Lib subdirectories. If so, it creates a jre.zip file from the content of those directories and attempts to extract the JRE version information and write a jreinfo.dsj file describing the contents.
• The user names and passwords in the users.txt file and the access group files in the UserManagerDatabaseDirectory directory are read into memory.
• The server group files in the ServerManagerDatabaseDirectory directory are loaded.
• The index for the package database in the DatabaseDirectory directory is loaded into memory.
• Each .app file in the AppFileDirectory directory is read. If the Package Dependencies tag is missing, the package dependencies are calculated, and resulting packages are placed in the package database. Each .app file describes one version of an application that the server is supposed to be able to serve.
• For each .app file read, any extension files for that application are loaded.

After completing all its startup tasks, the DSJ server opens the port designated by the Port property and waits for DSJ client connection requests.

Handling DSJ client requests

When the server receives a request for a new connection, it checks if it has exceeded its maximum allowed connections (see LimitConnections and MaximumConnections). If so, it sends a message back to the client, denying the connection; otherwise, the connection is allowed.

There are two types of connections: short-term and long-term. A client will first attempt a short-term connection, and then a long-term one, not necessarily with the same server. The server handles each connection type differently.

Short-term connection

When a DSJ client completes a short-term connection, it transmits an identification packet that contains:

• The user name and password, if any
• The application name to run, if specified

The server digests this information, and then:

• The user name and password are authenticated against the in-memory list of user names and passwords. If they donÆt match, or if no user name is specified, the user is considered to be an anonymous user.
• If no application is specified, a list of applications that are accessible to the user is sent to the client. The client displays this list in its Available Applications dialog box. If the user chooses an application from the list, the DSJ client restarts and attempts another short-term connection, this time with the name of the application chosen.
• If an application is specified, the applicationÆs profile (see Authorized Accessors) is checked to verify that the user is allowed to access the application. If not, the server refuses the client request, causing an error to appear on the client.

When a client gets verified access to an application, a list of servers that are supposed to serve the application (see Available Servers) are sent to the client. The client then attempts to contact the first server on the list for a long-term connection. If the first server on the list is the same server the client is already connected to, the attempt succeeds immediately and automatically.

Long-term connection

When a DSJ client completes a long-term connection, it transmits an identification packet that contains:

• The version number of the DSJ client
• The version of the JRE that the client is running
• A list of the JREs that are available on the client
• The user name and password, if any
• The application name to run

The server digests this information and then:

• The user name and password are authenticated against the in-memory list of user names and passwords. If they donÆt match, or if no user name is specified, the user is considered to be an anonymous user.
• The applicationÆs profile (see Authorized Accessors) is checked to verify that the user is allowed to access the application. If not, the server refuses the client request, causing the client to try the next server on its list.
• If the specified application requires a specific JRE (see RequiredJRE) that the client does not have, and that JRE is installed in the server (see Installing JREs), the server sends the JRE to the client, and tells the client to restart with that JRE.
• If the specified application prefers a JRE (see PreferredJRE and AlternateJRE) and the client has that JRE, but is not currently running under that JRE, the server tells the client to restart with the preferred JRE.
• If the specified application requires a specific JRE that neither the client nor the server have available, the server refuses the client request, causing the client to try the next server on the list.
• If the DSJ client and server versions donÆt match, the server sends the matching version of the client software to the client, and tells the client to restart.

If the connection fails for any reason, the client will try the next server on its list. If it cannot connect with any of the listed servers, an error message is displayed by the client, and the client session ends.

Once it is verified that the DSJ client is running a version that matches the server, and it is running the right JRE for the application if necessary, the process of serving the application commences. First, a list of servers that are supposed to serve the application are sent to the client, in case the server goes down. Second, the package dependencies list for the application is used to create a lookup table of the packages to be scanned for resources (instead of scanning the entire package database). Third, if there are any external files required by the application (see Extra Files), they are sent to the client. Then the process of serving the Java classes begins.

If the client has chosen to preload their cache, then the server will send all the packages required by the application (see Package Dependencies) to the client before the client attempts to run the main class (see Mainclass) of the application. Otherwise, the server will send only the main class, which the client will run. From then on, whenever the client needs a class or other resource, it checks its cache first. If itÆs there, which it would be if the cache is preloaded, the cached copy is used. Otherwise, the client requests the resource from the server.