Connection flow

Figure 1. Connection flow
Connection flow
Figure 1 shows a schematic overview of how a client connects to the host using z/OS® Explorer. It also briefly explains how PassTickets are used.
  1. The client logs on to the daemon (port 4035).
  2. RSE daemon authenticates the client, using the credentials presented by the client.
  3. RSE daemon selects an existing thread pool or starts a new one if all are full.
  4. RSE daemon passes the client user ID on to the thread pool.
  5. The thread pool creates a client specific RSE server thread, using the client user ID and a PassTicket for authentication.
  6. The client server thread binds to a port for future client communication.
  7. The client server thread returns the port number for the client to connect to.
  8. The client disconnects from RSE daemon and connects to the provided port number.
  9. The client server thread starts other user specific threads (miners), always using the client user ID and a PassTicket for authentication. These threads provide the user-specific services requested by the client.

The previous description shows the thread-oriented design of RSE. Instead of starting an address space per user, multiple users are serviced by a single thread pool address space. Within the thread pool, each miner (a user specific service) is active in its own thread with the user's security context assigned to it, ensuring a secure setup. This design accommodates large number of users with limited resource usage, but does imply that each client will use multiple threads.

From a network point of view, z/OS Explorer acts similar to FTP in passive mode. The client connects to a focal point (RSE daemon) and then drops the connection and reconnects to a port number provided by the focal point. The following logic controls the selection of the port that is used for the second connection:
  1. If the client specified a non-zero port number in the subsystem properties tab, then RSE server will use that port for the bind. If this port is not available, the connection fails.
  2. If _RSE_PORTRANGE is specified in rse.env, then RSE server will bind to a port from this range. If no port is available, the connection fails. RSE server does not need the port exclusively for the duration of the client connection. It is only in the time span between the (server) bind and the (client) connect that no other RSE server can bind to the port. This means that most connections will be using the first port in the range, with the rest of the range being a buffer in case of multiple simultaneous logons.
  3. If no limitations are set, RSE server will bind to port 0. The result is that TCP/IP chooses the port number.

The usage of PassTickets for all z/OS services that require authentication allows z/OS Explorer to invoke these services without storing the password or constantly prompting the user for it. Use of PassTickets for all z/OS services also allows for alternative authentication methods during logon, such as one-time passwords and X.509 certificates.