Abstract:
Methods, apparatus, systems and computer program product for instantiating user sessions in a terminal server environment in such a way as to accomplish fast switching between multiple user sessions while all user sessions are fully isolated from one another. The methods can embody a communication method wherein a user&#39;s credentials are used to identify the instances of system resources, for example, applications, that a user is using. This grouping can be referred to as a context, which may be associated with a particular user session. Independent communication mechanisms or pathways with window server for each context can be created and maintained. A bootstrap component can be created in such a manner that a logical barrier between user sessions is initiated and maintained; each instance of a given application thereby will be associated with a specific context. Additional control of information flow between bootstrap processes can be provided via a gateway, which may also manage communication between the components of the operating system and local user input/output agents.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of provisional patent application Ser. No. 61/099,549, filed Sep. 23, 2008, which is incorporated by reference. 
     
    
     FEDERALLY SPONSORED RESEARCH 
       [0002]    Not applicable. 
       SEQUENCE LISTING OR PROGRAM 
       [0003]    Not applicable. 
       FIELD OF THE INVENTION 
       [0004]    The present invention relates to the field of computer networks. In particular, the present invention relates to methods, apparatus and computer program product for fast switching between multiple user sessions. 
       BACKGROUND 
       [0005]    For enterprises large and small, consolidation of hardware and software is increasingly vital due to reasons of accessibility, reliability, data security, cost and the administration of applications and the network itself. Managing remote users, their computing experience and their access to networks is similarly crucial. Many different types of institutions have used terminal server applications to provide a computing environment and to address these issues, despite having varied institutional and computing objectives. For instance, educational institutions deploy computer networks to allow teachers, students and staff to connect remotely, thereby allowing increased productivity, easier access to information, rapid communication and, ultimately, enhanced learning opportunities. Government agencies are perhaps more concerned with data security, which is why terminal services always have been essential to their information technology infrastructures. Thin client and network deployments have been mandated in several agencies—this allows all operations to be performed centrally, and secures and monitors information that may have been sent or received. Commercial organizations, as well, benefit from deploying terminal servers so that data transmission can be managed and controlled; for example, by requiring users to access data through smart cards and biometrics, and allowing editing and review of the data only within a secure environment, or by certain identified users. And in the case of organizations of all types there is a growing need for network users to access information via mobile or handheld devices from remote locations. 
         [0006]    Centralized computing results in cost savings, ease of administration and enhanced security. Since almost all the processing of an application is done on a central server, companies are not forced to continuously upgrade or replace client or user hardware to keep pace with the systems requirements of modern applications. Maintenance of applications is isolated to the application server and not each individual node, also reducing administrative overhead. Servers are usually located in secure data centers, reducing the risk of physical theft. Centralized malware and audit processes also facilitate enhanced security. In addition, replacing workstations with thin clients can reduce energy consumption, environmental costs, support cost, and hardware costs. 
         [0007]    Despite these advantages, contemporary network protocols often suffer from drawbacks in that they are not optimized to provide a graphical interface in a multi-user environment. While many systems have a facility with multiple-user communications in a text-based communication sense, for example via TTY in Unix-like systems, graphical input and output in a multi-user networked environment remains cumbersome. For example, in the Mac OS X operating environment provided by Apple Inc. of Cupertino, Calif., the window server component is not optimized for graphical interaction with multiple users. For instance, the OS X window server communicates over a graphical socket, graphical Mach port or similar, depending on the version. Despite the availability of these protocols, a need exists for improved network communications allowing better security, better resource management and faster, more robust operation. 
       SUMMARY 
       [0008]    The disclosed embodiments relate to methods, apparatus, systems and computer program product for instantiating user sessions in a terminal server environment in such a way as to accomplish fast switching between multiple user sessions. In accordance with a preferred embodiment, the disclosed methods, apparatus, systems and computer program product provide functionality to multiple users whose demands on the operating system may differ in scope, extent or time. Thus, among the advantages disclosed herein, one or more aspects are to provide a faster and more secure computing environment. Other advantages relate to the ability to keep a user session running in the background of an operating system while streamlining users&#39; interfaces with the computing environment. These and other advantages of the many aspects of the disclosed embodiments will become apparent from a review of the following description and corresponding figures. 
         [0009]    Via certain embodiments disclosed herein, users can simply log into a server as if connected directly to the server&#39;s console, work with a full-featured desktop and run applications while all user sessions are fully isolated from one another. Embodiments disclosed herein facilitate sharing the resources of a common server, providing the advantages of simplified installation, configuration and maintenance of programs; management of user policies and profiles; central administration of user environments and security; simultaneous resource sharing and usage; faster processing and greater security. 
         [0010]    In certain embodiments disclosed herein, the methods, apparatus, systems and computer program product embody a communication method wherein a user&#39;s credentials are used to identify the instances of system resources, for example, applications, that a user is using. In certain embodiments, this grouping is referred to as a context, which may be associated with a particular user session. In certain embodiments, this allows independent communication mechanisms or pathways with window server for each context. As a non-limiting example, if separate instances of an application, such as Finder, have been launched in multiple user contexts or sessions, each instance of the application will communicate with window server using a distinct set of communication mechanisms or pathways, thereby isolating user sessions from one another, but maintaining each user&#39;s applications within a particular session. This may be accomplished, for example, by creating a bootstrap component in such a manner that a logical barrier between user sessions is initiated and maintained; each instance of a given application is thereby associated with a specific context. According to one embodiment, each specific context is associated with only a single session, although each session may optionally contain more than one context. According to certain embodiments, additional control of information flow between bootstrap processes is provided via a gateway. A gateway may also manage communication between the components of the operating system and local user input/output agents. Creating separately-identified and identifiable bootstrap processes, sessions and/or contexts provides mechanisms allowing allow rapid resource switching or optimization between users and across a network. 
     
    
     
       DRAWINGS 
         [0011]    The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention. 
           [0012]      FIG. 1  graphically depicts a typical operating system with a plurality of elements relating to a user session. 
           [0013]      FIGS. 2A-B  graphically depict exemplary operating systems configured to host multiple user sessions, optionally including a user gateway. 
           [0014]      FIG. 3  graphically depicts an exemplary operating system configured to host one or more remote user sessions. 
           [0015]      FIG. 4  is a flow chart of an exemplary process for instantiating multiple user sessions in an operating system environment. 
           [0016]      FIGS. 5A-B  graphically depict exemplary operating systems configured to implement fast user switching. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    Exemplary embodiments of the present invention are now described in detail, including depiction of the hardware components which serve as the context for the process embodiments. 
         [0018]    Embodiments of this disclosure may employ the Remote Desktop Protocol, the X Window System, the Virtual Network Computing system, and/or other known protocols for facilitating network communications. Remote Desktop Protocol (“RDP”) is a multi-channel capable protocol that allows for separate virtual channels for carrying device communication and presentation data from a server, as well as encrypted client mouse and keyboard data. RDP provides an extensible base and supports up to 64,000 separate channels for data transmission and provisions for multipoint transmission. Clients exist for most versions of Windows and other operating systems such as Linux, FreeBSD, Solaris and Mac OS X. The X Window System (commonly X11 or X) is a windowing system which implements the X display protocol and provides windowing on bitmap displays. It provides a toolkit and protocol with which to build graphical user interfaces (GUIs) on most Unix-like operating systems and OpenVMS, and has been ported to many other contemporary operating systems. X was specifically designed to be used over network connections rather than on an integral or attached display device. X features network transparency: the machine where an application program (the client application) runs can differ from the user&#39;s local machine (the display server). The client and server may run on the same machine or on different ones, possibly with different architectures and operating systems. A client and server can even communicate securely over the Internet by tunneling the connection over an encrypted network session. Virtual Network Computing (VNC) is a graphical desktop sharing system which uses the RFB protocol to remotely control another computer. The VNC protocol (RFB) is very simple, based on one graphic primitive from server to client (“Put a rectangle of pixel data at the specified X,Y position”) and event messages from client to server. It transmits the keyboard and mouse events from one computer to another, relaying the graphical screen updates back in the other direction, over a network. VNC is platform-independent—a VNC viewer on any operating system usually connects to a VNC server on any other operating system. There are clients and servers for almost all GUI operating systems and for Java. Multiple clients may connect to a VNC server at the same time. Popular uses for this technology include remote technical support and accessing files on one&#39;s work computer from one&#39;s home computer, or vice versa. 
         [0019]      FIG. 1  shows an example operating system  100 , which can include a plurality of architectural elements relating to a single user session (or context). For example, the operating system  100  can include a kernel  102 , a system bootstrap  104 , a window server  106 , a login windows  108 , and one or more daemons  110 . Further, the operating system  100  can include a user bootstrap  112  associated with the system bootstrap  104 , and one or more applications  114 . The operating system  100  can be hosted in any suitable computing architecture, such as a desktop computer, a laptop computer, a palm top computer, a server, a mobile communications device, and an embedded computing system. For example, the operating system  100  can be a Mac OS provided by Apple Inc. of Cupertino, Calif., a Windows operating system provided by Microsoft Corporation of Redmond, Wash., or a Linux operating system. Other configurations of the operating system  100  are possible. 
         [0020]    The kernel  102  can be one or more objects, modules, or processes that provide, at least in part, the core functionality of the operating system  100 . Further, the kernel  102  can serve as an interface between the operating system  100  and the hardware on which the operating system  100  is hosted. For example, the kernel  102  can provide functions such as low level scheduling, central processing unit (CPU) context switching, and interrupt handling. Examples of the kernel  102  can include, but are not limited to, the X is Not Unix (XNU) kernel provided by Apple Inc., the Linux kernel released under the GNU General Public License, and the Windows NT kernel provided by Microsoft Corporation. 
         [0021]    The system bootstrap  104  can be one or more objects, modules, or processes that can load operating instructions in the operating system  100  and that can manage one or more of the applications  114  hosted and executed in the operating system  100  context. Examples of the system bootstrap  104  can include, but are not limited to, launchd associated with the Mac operating system and Init associated with the Linux operating system. The window server  106  can be one or more objects, modules, or processes that can be configured to control the placement and appearance of graphical user interface elements, such as windows, in a display associated with the operating system  100 . Examples of the window server  106  include, but are not limited to, the Quartz window server associated with the Mac OS and the X window server. 
         [0022]    The login window  108  can be one or more objects, modules, processes, windows, or user interface screens that can be used to authenticate a user and/or to initialize a session in the operating system  100 . The login window  108  exists in the operating system context, outside of a user session, and can receive information identifying which user is seeking to login. Examples of the login window  108  include, but are not limited to, a GUI element or text interface including one or more prompts for a user name and/or a password, and/or a GUI element directing a user to enter authenticating biometric input, such as a fingerprint. In some implementations, the login window  108  also can be used to validate that the user is authorized to access one or more operating system  100  resources, such as a terminal server environment. Additionally, information collected via the login window  108  can be supplied to a login window included in the corresponding user session. For example, username and password information can be provided to a user session login window, such that the information need not be entered multiple times. 
         [0023]    The one or more daemons  110  can be objects, modules, processes, or programs that can execute in the operating system  100  context. One or more of the daemons  110  can run independently of user control and can run independent of any user session associated with the operating system  100 . Further, one or more of the daemons  110  can perform functions such as error logging, hardware monitoring, and/or power management. 
         [0024]    The user bootstrap  112  can be one or more objects, modules, or processes configured to load operating instructions in the operating system  100  and to manage one or more running applications. Examples of the user bootstrap  112  can include, but are not limited to, launchd associated with the Mac operating system and Init associated with the Linux operating system. 
         [0025]    The one or more applications  114  can be one or more objects, modules, processes, or programs that can run in accordance with a user&#39;s control. The one or more applications  114  can be initiated and/or managed by the user bootstrap  112 . The applications  114  can include, but are not limited to, file explorers such as the Finder application associated with the Mac OS or Nautilus provided by the GNOME Project, window organization programs, web browsers, and multimedia applications. 
         [0026]    Messaging between components in the operating system  100  can be facilitated by the system bootstrap  104  and the user bootstrap  112 . Additionally, the applications  114  can pass messages to one another as permitted by the operating system  100 . In some implementations, the applications  114  can communicate directly with the user bootstrap  112 . Further, communications between an application  114  and one or more other applications or the daemons  110  can be routed through the user bootstrap  112 . The user bootstrap  112  can be configured to forward messages received from an originating application to one or more of the other applications  114 . Similarly, a message sent by a daemon  110  to one of the applications  114  also can be routed through the bootstrap  104 . 
         [0027]      FIG. 2A  shows an example operating system  200  configured to host multiple user sessions (or contexts). Each user session can be thought of as an environment in which the user can interact with the operating system and utilize one or more available functions. In some implementations, a user session can be managed such that it is separate from each of the other user sessions hosted by the operating system. Thus, operations can be performed in one user session without affecting the other user sessions. It will be appreciated that some operations performed in a user session can affect the availability of system resources, such as processor and/or memory availability, for one or more other user sessions. In another example, a user session can be given special privileges to monitor or interact with one or more other user sessions hosted by the operating system, such as for maintenance or security purposes. 
         [0028]    In some implementations, a user session can have one or more associated applications, such as applications  214   a  or  214   b . The applications  214   a  and  214   b  can include, but are not limited to, file explorers, window organization programs, web browsers, and multimedia applications. A user session also can include a user bootstrap, such as user bootstrap  212   a  and  212   b , a local input/output (I/O) agent, such as I/O agent  216   a  and  216   b , and/or a local I/O device, such as I/O devices  218   a  and  218   b . Other configurations of the operating system  200  and/or one or more associated user sessions also are possible. 
         [0029]    A user session can include a user bootstrap, such as the user bootstrap  212   a  or  212   b , that can be configured to control communications between a plurality of applications associated with the user session. The first user bootstrap  212   a  controls communications with and between the first user applications  214   a . Further, the first user bootstrap  212   a  prevents communication between one or more of the first user applications  214   a  with one or more of the second user applications  214   b . Thus, the first user session can be maintained separate from all other user sessions hosted by the operating system, such as the second user session. Further, each of the user bootstraps, including the user bootstraps  212   a  and  212   b , can be a forked copy of the system bootstrap  104 . 
         [0030]    The local I/O agents  216   a  and  216   b  can pass input and output data from the corresponding user bootstraps  212   a  and  212   b  to the local I/O devices  218   a  and  218   b , respectively. The first user bootstrap  212   a  can control communication with the local I/O agent  216   a  and can prevent any communication between the local I/O agent  216   a  and any of the second user applications  214   b . Similarly, the second user bootstrap  212   b  can prevent communication between the local I/O agent  218   b  and any of the first user applications  214   a . A user bootstrap also can be configured to prevent communication between the local I/O agent and any object not associated with the corresponding user session. 
         [0031]    In some implementations, more than two user sessions can be instantiated. A user bootstrap, local I/O agent, local I/O device, and one or more applications can be generated for each user session executed in the operating system  100 . In some implementations, each of the user sessions can be configured to share the same local I/O devices. Thus, only one user session, the current session, is able to access the local I/O devices at a time. The other user sessions can be prevented from accessing the local I/O devices. When a single local I/O device is shared by all of the user sessions, the user sessions also can be configured to share one local I/O agent. Alternatively, a dedicated local I/O agent can be associated with each user session. 
         [0032]      FIG. 2B  shows an example operating system  224  configured to host multiple user sessions. A user session can include a user bootstrap, such as user bootstrap  222   a  or  222   b , a gateway, a local I/O agent, and one or more local I/O devices. Further, a user gateway, such as the user gateway  220   a  or  220   b , can be associated with each user session to control communications between the components of the operating system  224 , such as the daemons  110 , the applications  214   a  and  214   b , and the local I/O agents  216   a  and  216   b , respectively. 
         [0033]    Messages, e.g. from an application or from a local I/O agent, that are addressed to an object in a different user context can be halted by the corresponding user gateway. Thus, the user gateway can prevent messages from passing out of the user session. A user gateway, such as the user gateways  220   a  and  220   b , also can be configured to prevent the delivery of a message to an object in the corresponding user session that has been sent by a different user session. Thus, the user gateway also can prevent messages from passing to the user session. As a result, each user session can be maintained separate from any other user sessions executing in the operating system. 
         [0034]    However, some messages can be allowed to pass through the gateway, into or out of the associated user session. For example, messages from an application  214   a  or  214   b  to one or more of the daemons  110 , and messages from one or more of the daemons  110  to an application can be allowed to pass through the gateway. In some implementations, more than two user sessions can be instantiated. Each user session can include a gateway, a local I/O agent, a local I/O device, and one or more applications. 
         [0035]      FIG. 3  shows an example operating system  300  configured to support one or more remote user sessions and one or more local user sessions. Each user session can include a gateway, e.g. the gateway  220   a  or  220   b , a user bootstrap, e.g. the user bootstrap  212   a  or  212   b , and one or more applications, e.g. the applications  214   a  or  214   b . Further, a local user session can include a local I/O agent, such as the local I/O agent  216   b , and one or more local I/O devices, such as the local I/O devices  218   b . A remote user session can include one or more protocol specific agents  322 , each protocol specific agent corresponding to one or more I/O protocols, such as the Virtual Network Computer (VNC) protocol, the Remote Desktop Protocol (RDP), or the X11 protocol. Additionally, a remote user session can include a keyboard-video-mouse (KVM) agent  328  and one or more remote clients  326  communicatively connected to the remote user session via a network, such as the Internet  324 . Other configurations of the operating system  300 , the local user session, and/or the remote user session are possible. 
         [0036]    The protocol specific agents  322  can be configured to provide input and output support for a user session with respect to one or more of the remote clients  326 . Further, a remote client  326  can utilize a different protocol for input and output than another of the remote clients  326 . Thus, a protocol specific agent  322  can be used to generate and transmit messages to a corresponding remote client  326  using the appropriate protocol. In some examples, more than one remote client can be associated with a single protocol specific agent  322 . In some implementations, a protocol specific agent  322  can communicate with one or more additional protocol specific agents, such as where no direct translation is possible. Further, the KVM agent  328  can be configured to process and/or translate the I/O messages for a protocol. In some implementations, the KVM agent  328  can logically precede a protocol specific agent  322 . 
         [0037]    In one example, the cell phone remote client can receive input through its directional buttons and key pad indicating a request to access a webpage. Similarly, the laptop remote client can receive input through its keyboard, mouse, or other input device indicating a request to access the same webpage. The corresponding protocol specific agents  322  can receive the request messages, translate the messages, and transmit the messages to the user bootstrap  212 . The request messages passed by the protocol specific agents  322  to the user bootstrap  212  can be similar, since each requests the same resource. However, the requested web page returned to the protocol specific agents  322  can be translated in one way to render the web page on the laptop remote client and in a different way to render the web page on the cell phone remote client  326 . 
         [0038]    In some implementations, only one of the remote clients  326  is permitted to send messages through the bootstrap  212   a  to the applications  214   a  and the daemons  110 . The remaining remote clients  326  can be configured to receive output from the user bootstrap  212   a , but input from those remote clients  326  to the bootstrap  212   a  can be blocked. For example, one of the remote clients  326  can act as a presenter and can be permitted to send input to the user session as well as to receive output from the user session. The remaining remote clients  326  can be configured to receive output from the user session, such as to see what actions are being performed in the user session. The remaining remote clients  326 , however, will not be permitted to affect the actions being performed in the user session. This is known as shadowing. 
         [0039]    In some other implementations, a plurality of the remote clients  326  can interact with the user bootstrap  212   a , such as to transmit messages to the applications  214   a  and/or the daemons  110 . In such implementations, each of the remote clients  326  can view actions performed by the other remote clients. For example, a ‘primary user’ that uses the user session in the normal course of their work can receive assistance from an ‘administrative user’ who also can access the user session. In another example, two users working in different cities can be permitted to share a user session, such as to collaborate on a task. 
         [0040]      FIG. 4  shows an example process  400  for instantiating multiple user sessions in an operating system environment. A window server can launch a login screen ( 402 ). The login screen can be a window or screen presented to the user, such as a prompt requesting information. Further, the login window can prepare the system for a login associated with a new user. A login screen can prompt the user to supply one or more user credentials ( 404 ). For example, the user credentials can include identification and verification data, such as a user name and password. Further, the user credentials can include information indicating the type of session to be created, such as the server or system that will be logged into, the type of environment that is to be generated, the connection protocol to be used, and/or the rights desired by the user. 
         [0041]    Further, a login screen can be used to launch one or more applications, such as a file management application or web browser ( 406 ). In some implementations, one or more applications can be associated with every user session and can be launched automatically during initialization, so that the user does not have to launch them. During session initialization, a system bootstrap also can create forked copies of itself to generate one or more user bootstraps ( 408 ). Additionally, using the login screen to launch one or more applications ( 406 ) and the generation of one or more user bootstraps ( 408 ) can be performed in parallel, independently, or in any sequence. 
         [0042]    Further, a login window can pass ownership of the applications, such as the file management application and/or the web browser, to a forked copy of the system bootstrap  410  associated with the user session. In some implementations, one or more applications launched by the login screen are controlled by the login screen. The login screen can then pass control of the applications to the associated bootstrap. Thus, the login screen is not needed by the user session once the user session has been initialized and control of the applications has been passed. 
         [0043]    The process  400  can determine whether a new user request to log in has been received ( 412 ). If a new user request has not been received, the process  400  waits to receive a new user request. When a user request to log in has been received, the process  400  can be repeated. In some implementations, more than one user session can exist concurrently. It will be appreciated that different configurations of the process  400  are possible for different user sessions, including processes that include more or fewer steps. In some implementations, multiple processes  400  can execute at the same time, allowing multiple users to login at the same time. 
         [0044]      FIG. 5A  shows a block diagram of an operating system  500  configured to implement fast user switching. The operating system  500  can simultaneously host multiple user sessions, such as user sessions  506   a - g . In some implementations, local input and output devices  508  can be associated with a current user, such as the user session  7   506   g . Other user sessions  506   a - 506   f  cannot receive input or transmit output while user session  7   506   g  is the current session. Thus, the user sessions  506   a - f  are still active, but are running in the background of the operating system  500 . 
         [0045]    For example, the operating system  500  can provide functionality to many users who only need to use the operating system  500  for short periods of time. The load on the operating system is distributed if the periods of time required are spread out through the day. Fast user switching allows the users to keep a session running in the background of the operating system  500 . Thus, the user does not need to spend the time to log in and log out every time they need to perform a task. 
         [0046]    Fast user switching further can be used to associate the I/O devices  508  with the current user session  506 , as required. In some implementations, changing the association between a user session and the I/O devices  508  can be accomplished by a command received in the user interface of the current user session. For example, the login name of another user can be selected from a list of all running user sessions  506 . In another example, a login screen can require the login name and password of another user session  506 . 
         [0047]      FIG. 5B  shows a block diagram of the operating system  500  configured to implement fast user switching. The local I/O devices  508  can be associated with a new current user session  506   a . For example, a different user can require access to their user session, so the user can select their username from an on screen drop-down menu. 
         [0048]    In some implementations, a remote user  510  can connect via a network, e.g. the Internet  324 , to the operating system  500  and can become associated with the user session  506   c . The remote user  510  can be given full input and output control over the user session  506   c . In some implementations, a remote user  510  also can create a new user session instead of becoming associated with one of the existing user sessions  506 . 
         [0049]    The embodiments described above are given as illustrative examples only. It will be readily appreciated by those skilled in the art that many deviations may be made from the specific embodiments; accordingly, the scope of the invention is to be determined by the claims below rather than being limited to the specifically described embodiments above. In addition, the flowcharts found in the figures are provided to instruct a programmer of ordinary skill to write and debug the disclosed embodiments without undue effort; the logic flow may include other steps and the system other components. The invention is not limited to a particular expression of source or object code. Accordingly, other implementations are within the scope of the claims.