System and method for using virtual IP addresses in a multi-user server system

A method of handling network access in a multi-user server system is disclosed. In the disclose system, a virtual network adapter is created for each user session on the multi-user server system. Each virtual network adapter receives its own independent IP address such that each individual user session appears to be a unique network node to other systems on the computer network.

TECHNICAL FIELD

The present invention relates to the field of multi-user server systems. In particular, but not by way of limitation, the present invention discloses techniques for allowing multiple users to have individual concurrent sessions on a server system wherein each user may use an individual IP address.

BACKGROUND

Centralized computer systems with multiple terminals for accessing the centralized computer systems were once the dominant computer architecture. Mainframe computers were shared by multiple users wherein each user had access to a terminal system coupled to the mainframe computer.

In the late 1970s and early 1980s, personal computer systems revolutionized the computing industry by allowing each individual user to have access to their own full computer system. Each user could run their own applications and did not need to share any of the personal computer's resources with any other user.

Although personal computers have become the dominant form of computing, there has been a resurgence of the centralized computer with multiple terminals form of computing. Terminal based systems can have reduced maintenance costs since users cannot easily introduce viruses into the system or load in unauthorized program. Furthermore, modern personal computer systems have become so powerful that their substantial computing resources generally sit idle for the vast majority of the time.

DETAILED DESCRIPTION

The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the invention. It will be apparent to one skilled in the art that specific details in the example embodiments are not required in order to practice the present invention. For example, although the example embodiments are mainly disclosed with reference to a thin-client system, the teachings can be used in other environments. The example embodiments may be combined, other embodiments may be utilized, or structural, logical and electrical changes may be made without departing from the scope what is claimed. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents.

Computer Systems

The present disclosure concerns networked computer systems.FIG. 1illustrates a diagrammatic representation of machine in the example form of a computer system100that may be used to implement portions of the present disclosure. Within computer system100there are a set of instructions124that may be executed for causing the machine to perform any one or more of the methodologies discussed herein. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system100includes a processor102(e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory104and a static memory106, which communicate with each other via a bus108. The computer system100may further include a video display adapter110that drives a video display system115such as a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT). The computer system100also includes an alphanumeric input device112(e.g., a keyboard), a cursor control device114(e.g., a mouse or trackball), a disk drive unit116, a signal generation device118(e.g., a speaker) and a network interface device120.

The disk drive unit116includes a machine-readable medium122(such as a magnetic or optical disk) on which is stored one or more sets of computer instructions and data structures (e.g., instructions124also known as ‘software’) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions124may also reside within, completely or at least partially, and be read from the main memory104, the static memory106, or the processor102during execution of the instructions124by the computer system100. Thus, the main memory104, the static memory106, and the processor102also constitute machine-readable media.

The instructions124may further be transmitted or received over a network126via the network interface device120. Such a transfer of the instructions may occur utilizing any one of a number of well-known transfer protocols such as the well known File Transport Protocol (FTP).

For the purposes of this specification, the term “module” includes an identifiable portion of code, computational or executable instructions, data, or computational object to achieve a particular function, operation, processing, or procedure. A module need not be implemented in software; a module may be implemented in software, hardware/circuitry, or a combination of software and hardware.

The Resurgence of Terminal Systems

Before the advent of the inexpensive personal computer, the computing industry largely used mainframe or mini-computers that were coupled to many “dumb” terminals. Such terminals are referred to as ‘dumb’ terminals since all of the computing ability resided within the mainframe or mini-computer and the terminal system merely displayed an output and accepted alpha-numeric input. No user application programs executed locally on the terminal system. Computer operators shared the mainframe computer to multiple individual users that each used individual terminals coupled to the mainframe computer. These terminal systems generally had very limited graphic capabilities and were mostly visualizing only alpha-numeric characters on the display screen of the terminal.

With the introduction of reasonably low-cost personal computer systems, the use of dumb terminals largely disappeared since personal computer systems usually provided a much more cost effective computing solution. If the services of a dumb terminal were required in order to interface with a legacy terminal-based computer system (such as a main-frame or mini-computer system), a personal computer could easily execute a terminal application program that would emulate the operations of a dumb terminal at a cost very similar to the cost of a dedicated dumb terminal.

During the mid-1980's of the personal computer revolution, personal computer systems with high-resolution graphics were introduced to the personal computer market. Such high-resolution graphics allowed for the creation of much more intuitive and user-friendly computer user interfaces than could be created with a display system that could only display text. For example, all of the current personal computer user interfaces that use multiple different windows, icons, and pull-down menus are implemented using high resolution graphics. The introduction of high-resolution graphics also allowed for many new types of computer applications that used photos, videos, and graphical images.

In recent years, a new generation of terminal systems have been introduced into the computer market as people have rediscovered some of the advantages of a terminal based computer systems. For example, the use of computer terminals allows for greater security and reduced maintenance costs since users of computer terminals cannot introduce malicious computer viruses into the computer system since the user cannot install new software into a terminal system. The use of computer terminals can also allow more people to access computer services at a lower cost since modern computer terminal systems can be manufactured at a very low cost. This new generation of computer terminal systems includes high-resolution graphics capabilities and cursor control devices (such as mice or trackballs) that personal computer users have become accustomed to using.

Terminal-based computer system environments allow multiple users at individual high-resolution terminal systems to share the computing resources of a single personal computer system and all of the software installed on that personal computer system. In this manner, a modern high-resolution terminal system is capable of delivering the functionality of a personal computer system to a user without the full cost and the maintenance requirements of a personal computer system. One category of these modern terminal systems is called “thin-client” systems since these devices are created with only enough resources to operate as a terminal system. Although the techniques set forth this document will mainly be disclosed with reference to thin-client terminal systems, the techniques described herein are applicable in other area of the IT industry as well.

A Thin-Client System

FIG. 2Aillustrates a high-level block diagram of one embodiment of a thin-client server computer system220coupled to one (of possibly many) thin-client terminal system240. The thin-client computer server system220and thin-client terminal system240are coupled together a with a digital communications channel230. The digital communications channel230may be a serial data connection, an Ethernet connection, or any other suitable bi-directional digital communication means. In one particular embodiment, a convention computer networking system is used since such equipment is ubiquitous, inexpensive, well-supported, and able to server many thin-client terminal systems240concurrently.

FIG. 2Billustrates a conceptual diagram of an example of thin-client system environment wherein a single thin-client computer server system220provides computing resources to eight individual thin-client terminal systems240coupled to the thin-client server computer system220. In the example embodiment ofFIG. 2B, each of the thin-client terminal systems240are coupled to the thin-client server computer system220using a local area network (LAN)230as a communication channel. In the embodiment ofFIG. 2B, each thin-client terminal system240includes a video display system for output along with a keyboard and cursor control device (such as a computer mouse) for input.

Referring back toFIG. 2A, the thin-client terminal system240provides terminal access to the computing resources of the server computer system220. The thin-client server computer system220may be a typical computer system such as the computer system100illustrated inFIG. 1. Since modern personal computer systems have become such powerful computer systems that are rarely ever used at their full capacity during normal usage by a typical personal computer user, a thin-client server computer system220may be a standard personal computer system.

The goal of thin-client terminal system240is to provide most or all of the standard input and output features of a typical personal computer system to the user of the thin-client terminal system240. However, this goal is to be achieved without providing the full computing resources or software of personal computer system since those features will be provided by the thin-client server system220that will interoperate with the thin-client terminal system240. A thin-client terminal system240may be implemented with a standard microprocessor, however, a thin-client terminal system240may also be implemented with an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA) in order to keep the cost low.

From an output perspective, the thin-client terminal system240ofFIG. 2Agenerates a visual display and provides an audio signal. The visual display is generated by a high-resolution video display system.

The high-resolution video display system consists of a screen buffer260, a video adapter265, and a video display system267. The screen buffer260contains the contents of a bit-mapped display image and a video adapter265reads that bit-mapped display image to generate a video display signal that drives a video display system267. The screen buffer260is filled with display information provided by thin-client control system250using video information sent as output221by the thin-client computer server system220across a communications channel230.

The audio output system of the thin-client terminal system240consists of a sound generator271coupled to an audio connector272for creating a sound signal. The sound generator271creates a sound signal using information provided by thin-client control system250using audio information sent as output221by the thin-client server computer system220across a communications channel230.

From an input perspective, thin-client terminal system240ofFIG. 2Aallows for both alpha-numeric input and cursor control input from a user using the thin-client terminal system240. The alpha numeric input is provided by a keyboard283coupled to a keyboard connector282that supplies signals to a keyboard control system281. Thin-client control system250encodes keyboard input from keyboard control system281and sends that keyboard input as input225to the thin-client server system220. Similarly, the thin-client control system250encodes cursor control input data received from cursor control system284and sends that cursor control input data as input225information to the thin-client server system220. Cursor control system284receives input from a cursor control device such as mouse286that is coupled to the cursor control system284through mouse connector285.

The thin-client terminal system240may include other input, output, or combined input/output systems in order to provide additional functionality to the user of the thin-client terminal system240. For example, the thin-client terminal system240ofFIG. 2Afurther includes an input/output control system274coupled to an input/output connector275. Input/output control system274may be a Universal Serial Bus (USB) controller and input/output connector275may be a USB connector such that the these components provide USB capabilities to thin-client terminal system240.

The thin-client server system220is equipped with software for interacting with multiple thin-client systems. As illustrated inFIG. 2A, thin-client interface software210in thin-client server system220supports thin-client terminal system240as well as any other thin-client terminal systems coupled to thin-client server system220. Each thin client terminal system will have its own screen buffer in the thin-client server system220as depicted by the stack of thin-client terminal screen buffers215.

Multiple Different Session v. Multiple Personal Computer Systems

As previously set forth, the single thin-client server system220inFIG. 2Acan support multiple concurrent individual user sessions. Each user session refers to a set of programs and resources inside the operating system associated with a user at a thin-client terminal system240. Thus, a single inexpensive personal computer set up as a thin-client server system220can provide a personal computer experience to multiple concurrent users each using a thin-client terminal system240. Such arrangements have become very popular in environments wherein multiple computer systems are needed for a low price such as school classrooms and when greater security is required.

In general, having multiple different users at thin-client terminal systems240run multiple different applications on a single thin-client server system220works very well. However, there are occasionally certain personal computer applications that do not work very well on a thin-client server system220. For example, if two different users on the same thin-client server system220attempt to use an internet-based communication application (such as an instant messaging application) to communicate with each other, the communication application may not work properly since both users may have the same internet IP address, the one IP address of the thin-client server system220.

Similarly, a network firewall device that connects a thin-client server system220to the global internet may have difficultly distinguishing between multiple different user sessions on the thin-client server system220since all the different user sessions may be using the single internet protocol (IP) address assigned to the thin-client server system220. And even if the network firewall device operates properly with the thin-client server system220having a single IP address, the logging information that the network firewall device collects may not be very useful since it may be impossible to distinguish which particular user using the thin-client server system220was responsible for which specific network usage since all of the network usage may appear in the network usage log as using the same IP address. It would be desirable if the behavior of each different user of the thin-client server system220could be individually exampled at the firewall.

FIGS. 3A and 3Billustrate this traditional approach to network resource usage by a thin-client server system220that supports multiple thin-client terminal systems240. As illustrated inFIG. 3A, there are several user application sessions205. All of these different application sessions205may have network access needs but there is only a single instance of network hardware326available on the thin-client server system220. To share the single instance of network hardware326, each of the different application sessions205makes network resource calls to the operating system222and the operating system will handle the network requests and responses.

FIG. 3Billustrates high-level data flow diagram of an example of wherein application session n on the left side of the diagram needs to access a network resource329on the right side of the diagram. Application session n initially makes a request to the operating system222with goal of accessing the network resource329. The operating system222then accesses the single instance of network hardware326on behalf of the application session n by making a request to the network adapter software328. InFIG. 3B, this is illustrated as a network resource request1(NNReq1) from operating system222to the network adapter software328. The network adapter software328then instructs the network hardware326to access the network resource329with network resource request2(NNReq2). In some embodiments, the application sessions may communicate directly with the network adapter software328instead of going through the operating system.

Communication in the other direction is handled in a similar manner. Referring toFIGS. 3A and 3B, a network resource response2(NNResp2) message from the network resource329is communicated through the network hardware to the network adapter software328. The network adapter software328then relays a corresponding network resource response (NNResp1) to the operating system222on the thin-client computer server system220. Finally, the operating system222informs the proper application session n about the information received from the network resource329. As set forth above, in some embodiments, the network adapter software328may communicate directly with the application session instead of communicating through the operating system222.

Virtual IP Addresses

To prevent the potential problems caused by having multiple different user sessions using the same internet protocol address on a thin-client server system, the present disclosure introduces the concept of ‘virtual IP addresses’ and virtual network adapters. In this disclosure, a virtual IP address is a real IP address that is assigned to a particular user session in a thin-client server system such that each user session may have its own individual unique IP address. To create and handle the various different virtual IP addresses an instance of a virtual network adapter software is created for each individual user session. In addition, the operating system itself may have its own instance of a virtual network adapter for network communication that is unrelated to any of the user sessions. The IP addresses assigned to the virtual network adapters may be assigned from a pool of addresses assigned to the thin-client server system220or may be obtained from a Dynamic Host Configuration Protocol (DHCP) server coupled to the local network.

One embodiment of a thin-client server system220that uses virtual IP addresses and virtual network adapters is illustrated inFIGS. 4A and 4B.FIG. 4Aillustrates a high-level block diagram of a thin-client server system220with multiple virtual network adapters for handling network communication for various different application sessions205.FIG. 4Billustrates a data flow diagram of an example of wherein application session n on the left side of the diagram accesses a network resource429on the right side of the diagram through the use of a virtual network adapter n.

Referring to the thin-client server system220illustrated inFIG. 4A, a network handler427has been added to handle all network requests in a new manner. The network handler427monitors all network resource requests on the thin-client server system220that would normally be handled by the legacy network adapter428. The network handler427intercepts these network requests to handle these network requests with new system using virtual network adapters. Once again, it should be noted that in some alternate embodiments, the application sessions205may be able to access the network handler427directly instead of communicating through the operating system222as illustrated in the example embodiment ofFIG. 4A.

Referring toFIGS. 4A and 4B, when an application session205wishes to request network services then that application session205may make a network service request to the operating system222(illustrated as ‘Request’ inFIG. 4B). The operating system222then makes a corresponding request that would have previously gone to the legacy network adapter software428. However, the network handler427intercepts this network request to handle the network request. InFIG. 4B, this request from the operating system222is illustrated as a network resource request1(NNReq1) to the network handler427. The network handler427stops the legacy network adapter428from handling the request. This may be accomplished by not having the legacy network adapter ever receive the request. For example, in one embodiment the operating system is instructed to redirect calls to the legacy network adapter to a different location.

After the network handler427has intercepted a network request, the network handler427analyzes the network request to identify which specific application session initiated the network request (or to determine if the request may was initiated by the operating system itself). After analyzing the network request (NRReql), the network handler427then initiates a corresponding network resource request to a virtual network adapter n (such as virtual network adapters431,432, and433inFIG. 4A) that is associated with the application session that made the original request (or the virtual network adapter associated with the operating system222if the operating system222itself initiated the network request). InFIG. 4B, this network resource request is illustrated as a network resource request (NNReq2) to a virtual network adapter n (the virtual network adapter associated with the application session or operating system that made the network request).

Note that if no virtual network adapter has been associated with the application session that made the network request, then the network handler427may create a new instance of a virtual network adapter. The new virtual network adapter will be assigned its own unique IP address such that each instance of virtual network adapter software (such as virtual network adapter software431,432, and433inFIG. 4A) will have its own unique IP address. In this manner, each application session205will have its own unique IP address such that each application session205in thin-client server system220will appear as completely distinct personal computer system to other entities on the computer network. Indeed, each application session205will appear to other application sessions205on the very same thin-client server system220as existing on a completely distinct personal computer system. In this manner, all of the different user sessions205will be distinguishable by any firewall device that couples thin-client server system220to the global internet. Similarly, any network interactions between applications in different application sessions205will appears as being on completely different personal computer systems such that the applications will not be confused by having the same IP address.

When an instance of virtual network adapter software (such as virtual network adapter software431,432, and433) receives a network request from the network handler427, the virtual network adapter software (431,432, or433) will handle the network request using the unique IP address that the virtual network adapter software has been assigned. Specifically, the instance of virtual network adapter software (431,432, or433) will instruct the network hardware426to access the network resource429as illustrated inFIG. 4A. This communication is illustrated inFIG. 4Bby a network resource request3(NNReq3) from virtual network adapter n to network resource429.

Referring toFIG. 4A, responses back from the network resource429will be analyzed by the network hardware426and sent back to the appropriate instance of virtual network adapter software (431,432, or433) in a similar manner. This is illustrated withinFIG. 4Bby network request response3(NRResp3) sent back to virtual network adapter n. This is performed by having the network hardware426examine the IP address in the received network message and deliver that message to the appropriate instance of virtual network adapter software based upon the IP address.

Upon receiving a network response message from the network hardware426, an instance of virtual network adapter software (such as431,432, and433) may then relay this network response back to the operating system222as illustrated inFIGS. 4A and 4Bwith network resource response1(NRResp1) from virtual network adapter n to operating system222. Note that the network handler427does not see the network resource responses. These network resource responses are then passed to the operating system222in this embodiment. (Again, note that in other embodiments, the virtual network adapter n may be communicating directly with the application session.) In the embodiment ofFIG. 4B, the operating system222examines the network resource response (NRResp1) and returns a corresponding network response to the appropriate application session n. (Unless the network response was directed to the operating system222itself.)

The Abstract is provided to comply with 37 C.F.R. §1.72(b), which requires that it allow the reader to quickly ascertain the nature of the technical disclosure. The abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.