Multi-player computer game, system and method

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to Provisional Patent Application Ser. No. 60/183,318 filed on Feb. 17, 2000.

FIELD OF THE INVENTION

[0002] The present invention relates to a multi-player and enhanced single-player computer game, system and method.

BACKGROUND OF THE INVENTION

[0003] Computer game players constantly demand more challenging, visually and mentally exciting games. The games must hold a player's attention, draw a player back to the game again and again, and, facilitate multi-player game play. While certain types of multi-player game play are already possible (e.g., video arcade, side-by-side platform game play), the increasing sophistication of game players, the high-powered computing devices now available to the general public, and the quick Internet connection speeds now available, have all assisted in raising the standard for multi-player game play.

[0004] What has not yet been possible, is multi-player game play among players having different computing devices. For example, side-by-side gameplay requires that each player have a computing device compatible with the other player(s)' device(s). Even multi-player game play over the Internet requires that the multiple players have the same or at least compatible computing devices. The reason being that the software each player executes on his/her computing device must be compatible (i.e., must be able to bi-directionally communicate) with the software on the other players' devices.

[0005] Development of multi-player computer games is also currently time-consuming and expensive. One reason is the variety of hardware platforms currently available for multi-player game play. A multi-player game must be developed for each platform, with little cross-over or reuse of the application code from one platform to another. In addition, there is a significant learning curve for new software developers and even for experienced developers for hardware specific protocols, communication specifications, and new platform and development tools. Thus, current methods of developing multi-player computer games suffer from significant shortcomings.

SUMMARY OF THE INVENTION

[0006] The present invention is directed to a multi-player computer game, system and development method.

[0007] The present invention provides special purpose software operable in connection with a processor of a client computing device to enable multi-player game play between and among different hardware platforms in any of a client/server, client/client, or client/client/server configurations. The present invention also provides special purpose software operable in connection with a processor of a server computer (or a plurality of server computers) to facilitate and manage multi-player game play over a network. The special purpose software on each of the client computer and server computer facilitates and manages communication between and among client computers (i.e., players) and server computers, regardless of the different hardware platforms and operating systems installed and operable on the various client computers to provide seamless connectivity among game players over a network. The amount of functionality provided by the client special purpose software and server special purpose software depends on a number of variables, such as, for example, type of multi-player game, number of players, connection configuration (e.g., client/client, etc.), game status (e.g., initiation, new players being added, players leaving, etc.).

[0008] In accordance with embodiments of the present invention, special purpose software operable in connection with a processor of a client computer for facilitating a multi-player computer game includes a plurality of components (e.g., modules, libraries, sub-systems, etc.) that facilitate communication between the client computer, server computer, and at least one other client computer having special purpose software installed thereon and operable in connection with a processor thereof. The components provided on the client computer depends on the level of multi-player functionality required for a particular multi-player game.

[0009] The client computer may comprise any computing device having a processor in connection with which special purpose software in accordance with the present invention may be operated. Such computing devices include, by way of non-limiting example, a personal computer (desktop, laptop), hand-held computing devices (e.g., personal digital assistants (PDAs) such as Palm®, BlackBerry®), computer game consoles (e.g., Sony Playstation® and Playstation <b>2</b>, Sega Dreamcast®), cellular devices, and any other now known of hereafter developed computing device suitable for multi-player game play.

[0010] The present invention is also directed to a multi-player game system for facilitating multi-player computer game play over a network such as the Internet, for example. In accordance with this embodiment of the present invention, a server or a plurality of servers connectable to each other and to a network each include special purpose software operable in connection with a respective processor thereof for facilitating multi-player game play over that network among a plurality of client computers. A single server, a plurality of servers in a single location, or a plurality of geographically displaced servers may be provided, in accordance with various embodiments of the present invention. The server(s) provide various functionality to the client computers to facilitate multi-player game play. For example, the server(s) may maintain client (i.e., player) registration information, a logical map of the names and locations of all servers in the multi-player game system, resources which may be provided or made available to players during game play (but which may not be provided on the client computers for security or efficiency reasons), and various other functionality and information, as described in more detail below.

[0011] The server architecture of the inventive system provides flexibility, robustness, and performance enhancement, among other features and advantages. Typically, a server provides a category of functionality. In essence, server A provides functionality A. Within a networked environment, such as provided in accordance with the present invention, there exists a set of servers providing different functions; sometimes redundant (i.e., providing backup), sometimes completely separate and different. When servers of the same type (i.e., functionality) work together, they may provide a primary function, scalability, load balancing, quicker response and thus game performance, reliability, consistency, and may be capable of working together. Servers providing different functionality, on the other hand, may or may not collaborate to provide enhanced functionality.

[0012] The coordinated server configuration of the multi-player game system of the present invention advantageously provides a plurality of servers specifically designed and intended to cooperate with each other. That enhances the overall functionality of the inventive system. The servers provided in accordance with the present invention are complementary in services and can leverage some or all of each other's functionality. One of the key benefits of the present invention is provided in the server interoperability. Different applications can be developed to inter-operate with specific other applications. This is typically done by having engineers develop custom solutions for the applications to work together. However, a more advanced system like that of the present invention will provide a set of infrastructure tools, that allows various applications to work with various other applications without custom solutions (e.g., in a manner analogous to the “cut &amp; paste” functionality provided by certain word processing programs yet usable for other applications outside of the word processing program). Server interoperability and functionality “sharing” in accordance with embodiments of the present invention may provide, by way of non-limiting example, service finding tools, common user registration, common authentication/security, common administration, open database, common protocols, common data formats, and the ability to operate with other systems.

[0013] The present invention is also directed to a method of software development that facilitates rapid development (i.e., software development) of new multi-player computer games by eliminating the need for a software engineer to write specific application code for each hardware platform, communication protocol, or operating system (OS). In accordance with this embodiment of the present invention, the software developer need only write software code specific for the multi-player game application, without concern for the hardware platform or OS upon which the game may be played, or which communication protocol will be utilized. In accordance with the present invention, a cross-platform core provides an interface between the specific application code and the operating system, hardware devices, and communication protocols of a computing device (which are generally different from one computing device to the next). The software developer thus need only code to the cross-platform core, which is always the same regardless of the hardware platform or operating system. The cross-platform core handles all communication between the application code and the client computing device, including communication between the client computing device and the server(s).

[0014] Other aspects, features, and functionality of the present invention will become apparent from the following detailed description, considered in conjunction with the accompanying drawing figures. It is to be understood, however, that the drawings, which are not to scale, are designed solely for the purpose of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In the drawing figures, which are not to scale, and which are merely illustrative, and wherein like reference characters denote similar elements throughout the several views:

[0016] FIGS. <b>1</b>A-<b>1</b>G are schematic diagrams of various configurations of a multi-player computer game system constructed in accordance with embodiments of the present invention;

[0017]FIG. 2 is a schematic diagram of a plurality of servers arranged as a server cluster and provided as part of the multi-player computer game system of FIG. 1A;

[0018]FIG. 3 depicts various components provided by the special purpose software operable in connection with a processor of the client computing device in accordance with an embodiment of the present invention;

[0019]FIGS. 4A and 4 B depict the architecture of an application program, cross-platform core, and client computer hardware and operating system in accordance with embodiments of the present invention;

[0020]FIG. 5 depicts a protocol stack for the service layer of the cross-platform core depicted in FIG. 4A;

[0021]FIG. 6 depicts data flow for pass-through mode operation of the communication engine of the cross-platform core of the present invention;

[0022]FIG. 7 depicts data flow for synchronous mode operation of the communication engine of the cross-platform core of the present invention; and

[0023] FIGS. <b>8</b>A-<b>8</b>C depict various embodiments of a matchmaker server in accordance with the present invention.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS

[0024] The present invention is directed to multi-player computer game, system and development method that facilitate multi-player game play between and among various hardware platforms employing various operating systems and communication protocols. The terms “client”, “user”, and “player” are used interchangeably herein to denote a player of a multi-player computer game.

[0025] As used herein, the term “multi-player game” includes, by way of illustrative example and not limitation, a sports simulation game such as basketball, baseball, football, hockey, motor-cross, wrestling, car racing, skiing, and virtually any competition between at least two players, a fast twitch type game such as, for example, first-person shooter games, a turn-based game such as chess, card games, checkers, etc. in which two players take turns playing the game, a massively multi-player game in which hundreds or thousands of players simultaneously play the game.

[0026] The present invention provides special purpose software operable in connection with a processor of a client computing device to provide a multi-player computer game. The special purpose software provides an interface between an application module, which provides the functionality for a specific multi-player computer game, and the operating system and hardware devices and protocols of the client computing device. For example, the application module may provide functionality for a racer-type game, a sport-type game, etc. That application module communicates (i.e., bi-directional data exchange) with a cross-platform core that handles all communications between the application module and the computing device hardware, operating system, and protocol requirements. Thus, in accordance with the present invention, different application modules may be written to provide different multi-player game functionality, each of the different application modules being used in connection with the same cross-platform core to provide the various multi-player computer games.

[0027] The present invention also provides a system that facilitates multi-player game play between and among a plurality of players regardless of the different hardware platforms (i.e., different client computing devices) used by the various players. Each client computing device may be running the same multi-player application module (or code), and each client computing devices includes the cross-platform core. Each client computing device also communicates with a server having special purpose software to facilitate multi-player game play between and among the various players. The server provides various functionality that may enhance and/or supplement the functionality provided on the client computing device, and generally manages and facilitates multi-player game play over a network (e.g., the Internet, an intranet (LAN, WAN), or other network), such as modem-to-modem or direct link.

[0028] In accordance with the various embodiments of the present invention, multi-player game play between and among a plurality of players is now possible regardless of the hardware platform, communication protocol, and operating system of each of the player's computing devices. It is thus possible, in accordance with the present invention, for players having different hardware and software configurations on their respective computing devices and communicating using various communication protocols to engage each other in multi-player game play.

[0029] New application modules may be developed in accordance with the present invention using the cross-platform core and other foundation technologies of the present invention (e.g., communications engine, client/server architecture) to simplify and speed software development. Coding to a specific operating system or hardware device or protocol is no longer required. Thus, software development intervals are significantly reduced. In addition, the reusable cross-platform core does not require integration testing for each new application module, because the cross-platform core has previously been tested and integrated with a plurality of hardware platforms, operating systems and hardware devices and protocols.

[0030] The terms “computers”, “computing devices”, and “computing hardware” (and variations thereof) are used interchangeably herein and are intended to be broadly construed. Those terms are not intended to define or otherwise limit the scope or content of the present invention. A computer (either client or server) may include some or all of the following components: a processor (e.g., central processing unit (CPU)); memory (e.g., RAM, ROM); a harddrive unit (HDU); communications interface (e.g., modem, ROM BIOS); data input device (e.g., keyboard, mouse, etc.); and a display. The computer may also include additional known hardware components and devices (e.g., joystick); the configuration of the server and client computers not being a limitation of the present invention. They also includes general purpose software that provides for overall operation of the client or server computer, and may include the operating system, commercially available software (e.g., database), communications software, etc. A computer may be, by way of illustration only, a personal computer (desktop, laptop), hand-held computing devices (e.g., personal digital assistants (PDAs) such as Palm®, BlackBerry®), computer game consoles (e.g., Sony Playstation® and Playstation <b>2</b>, Sega Dreamcast®), cellular devices, and any other now known of hereafter developed computing device suitable for multi-player game play.

[0031] The special purpose software provides the functionality of the present invention, may comprise one or more web-native modules, library files, etc., may reside on a client and/or server computer, and may utilize the general purpose software. It will be obvious to persons skilled in the art and from the disclosure provided herein that the programming language (C, C++, Java, etc.) used to create (i.e., code) the special purpose software is a routine matter of design choice. Thus, the present invention is not limited to a particular embodiment of the special purpose software as defined by the programming language used to code that software.

[0032] Referring next to the drawings and specifically to FIGS. <b>1</b>A-<b>1</b>G, a system for multi-player computer game play in accordance with embodiments of the present invention is there depicted and designated generally by reference numeral <b>100</b>. The inventive system <b>100</b> may utilize a client/server architecture that requires client computers <b>200</b> to connect through a server <b>120</b> with other client computers <b>200</b> and prevents direct client-to-client (i.e., player-to-player) connection (see, e.g., FIGS. <b>1</b>A-<b>1</b>E). Such a configuration reduces the bandwidth requirements of each player, facilitates intervention by the server in decision making between players, and provides increased security by “overseeing” all aspects of game play and by restricting client access to certain data provided on the server <b>120</b>. A preferred embodiment of the client/server architecture of the present invention provides a central data center <b>20</b> having at least one server <b>120</b> provided therein.

[0033] Alternatively, the system <b>100</b> may utilize a peer-to-peer architecture (i.e., client-to-client) in which all players (i.e., clients) may communicate directly with each other, such as depicted in FIG. 1F. In such an architecture, there is no central data center <b>20</b> or server <b>120</b>, and client computers <b>200</b> may connect and communicate directly with each other. Multi-player game functionality is provided by each client computer <b>200</b>, as described in more detail below.

[0034] Still alternatively, the system <b>100</b> may utilize a hybrid between the client/server and peer-to-peer architectures, as depicted in FIG. 1G. Communication between and among client computers <b>200</b> may be any combination of the peer-to-peer model, where clients communicate directly with each other, and the client/server model, where clients communicate with each other only through a server. A server referee <b>120</b> may monitor game-play for cheating and take appropriate action (e.g., drop a cheater's connection to the server <b>120</b> ).

[0035] With continued reference to FIG. 1A, and with additional reference to FIG. 2, an embodiment of the inventive system <b>100</b> includes a primary data center <b>20</b> having at least two substantially identical server computers <b>120</b>, each comprised of a plurality of computers, including, by way of non-limiting example, a web server <b>122</b>, a match maker server <b>124</b>, a resource server <b>126</b>, a user (client) identification server <b>128</b>, a chat server <b>180</b>, a tournament server <b>182</b>, a ranking server <b>184</b>, an ideal service finder <b>130</b>, a domain name server <b>132</b>, and a game server <b>134</b>. Alternatively, the functionality provided by those servers (as described in more detail below) may be provided on a single server <b>120</b> (or a primary and backup server <b>120</b> ), or grouped as appropriate so as to provide fewer servers. The server computers <b>120</b> are protected against unauthorized access, exposure to unauthorized data, etc., by a firewall <b>110</b> located between each server <b>120</b> and the network <b>10</b> and software such as security algorithms on servers and in operating systems, and may thus also be referred to herein as “protected” servers. Protected servers <b>120</b> are not directly accessible or connectable to a public network such as the Internet, for example. Those servers <b>120</b> typically have sensitive information (e.g., client identification and account data) stored in a database <b>144</b>, <b>146</b> of a data storage device <b>140</b>, <b>142</b>.

[0036] The primary data center <b>20</b> may also include public server computers <b>1120</b> as part of the inventive multi-player game system <b>100</b>. Those server computers <b>1120</b> connected directly to the network <b>10</b> and are accessible by a client computer <b>200</b>. The public server computers <b>1120</b> may have additional security, as a matter of design choice, provided by appliances, firewalls, operating system, server applications, routers, or other known or hereafter developed applications or devices. For example, a web server <b>122</b> and resource server <b>126</b> may comprise public server computers <b>1120</b>.

[0037] The protected servers <b>120</b> are connected to a backend network <b>150</b> that is self-contained within the primary data center <b>20</b> (e.g., a local area network (LAN)). The backend network <b>150</b> may comprise virtually any wired (e.g., twisted-pair, coaxial, fiber, etc.) or wireless (e.g., infrared, radio-frequency, etc.) network local to and contained within the building(s) that comprise the primary data center <b>20</b> (it being obvious to persons skilled in the art and from the disclosure provided herein that the primary data center <b>20</b> may comprise one or more buildings). Data storage devices <b>140</b>, <b>142</b> are connected to the protected servers <b>120</b>, each having a database <b>144</b>, <b>146</b> provided thereon. In a preferred embodiment, data storage device <b>142</b> and the database <b>146</b> provided thereon provide mirror images of data storage device <b>140</b> and database <b>144</b>, respectively. A further description of the data storage devices <b>140</b>, <b>142</b> and databases <b>144</b>, <b>146</b> are provided below. One or more backup server computers <b>2120</b> ) may be provided at a backup data center <b>30</b> which is connected via a private virtual connection (PVC) <b>40</b> and a firewall <b>110</b> to the backend network <b>150</b> of the primary data center <b>20</b>.

[0038] Connection between the primary data center <b>20</b> and the network <b>10</b> may be via a primary connection <b>60</b> and a secondary connection <b>62</b> provided by an Internet Service Provider (ISP). Both the primary and secondary connections <b>60</b>, <b>62</b> may be wired or wireless, as a routine matter of design choice.

[0039] With continued reference to FIG. 1A, additional server computers may be connected to the network <b>10</b> and may provide certain functionality of multi-player game play in accordance with the present invention. For example, a public server <b>1320</b> may be located remote from the primary data center <b>20</b>, but geographically closer to a client (e.g., client A). During game play, it may be more efficient to provide certain functionality to client A from the public server <b>1320</b> than from the primary data center <b>20</b>. The present invention enables and facilitates that situation. In addition, a rogue server <b>1220</b> may be connected to the network <b>10</b> and may similarly provide certain functionality to the client computers <b>200</b> during game play.

[0040] Each client computer <b>200</b> in the inventive system <b>100</b> has installed thereon special purpose software operable in connection with a processor of that computer. The special purpose software facilitates multi-player game play between and among client computers <b>200</b> regardless of the hardware platform, operating system, and hardware and communication protocol of each client computer <b>200</b>. Depending upon the network configuration (se, e.g., FIGS. <b>1</b>A-<b>1</b>G), communication between a client computer <b>200</b> and a server <b>120</b>, or directly between client computers <b>200</b>, will be facilitated by the special purpose software on the client computer <b>200</b>. Special purpose software installed on the server <b>120</b> and operable in connection with a processor thereof also facilitates and coordinates multi-player game play between and among client computers <b>200</b>. The functionality provided by each of the server <b>120</b> and client computers <b>200</b> depends upon the network configuration. For example, and as depicted in FIG. 1D, the server <b>120</b> may merely pass-through all client data, with all of the functionality being provided on each client computer <b>200</b>. Alternatively, and as depicted in FIG. 1E, the functionality may be apportioned between and among the server and client computers (<b>20</b>/<b>80</b> in that embodiment). Moreover, all of the functionality is provided on each client computer <b>200</b> for the configuration of FIG. 1F.

[0041] With reference next to FIG. 2, the protected server computer <b>120</b> of the primary data center <b>20</b> will now be discussed in more detail. As described above, the server <b>120</b> may comprise one or more computers including, by way of non-limiting example, a web server <b>122</b>, a match maker server <b>124</b>, a resource server <b>126</b>, a user (client) identification server <b>128</b>, a chat server <b>180</b>, a tournament server <b>182</b>, a ranking server <b>184</b>, an ideal service finder <b>130</b>, a domain name server <b>132</b>, and a game server <b>134</b>. Some of those servers may alternatively be provided as unprotected servers (see, e.g., <b>1120</b> in FIG. 1A), depending upon the functionality of the particular server and the sensitivity of an data stored on the server, for example. Which servers are provided as protected and which are provided as unprotected is a routine matter of design choice. Each server depicted in FIG. 2 may connect to the network <b>10</b> via a separate switch <b>136</b> or a plurality of servers may share a single switch <b>136</b>. The connections depicted in FIG. 2 are exemplary of one of the many different connection schemes available between the servers and the network <b>10</b>, and should not be interpreted in any way as limiting the scope or content of the present invention.

[0042] The functionality provided by the various servers depicted in FIG. 2, individually and/or collectively, facilitate and manage multi-player game play by a plurality of client computers <b>200</b> in accordance with the present invention. As described in further detail below, any of the servers (and its respective functionality) may be used at a particular time by the system <b>100</b> and accessed by a client computer <b>200</b>, depending upon a particular game activity. For example, the matchmaker server <b>124</b> and its functionality may be utilized when a player (i.e., client computer <b>200</b>) first attempts to connect to the server <b>120</b> and participate in multi-player game play. However, once that player has established a connection to a game server <b>134</b>, the matchmaker server <b>124</b> and its functionality may no longer be required. Similarly, the other servers of the server cluster <b>120</b> may be utilized by the client computer(s) <b>200</b> at various times and in various different ways during the course of multi-player game play.

[0043] The multi-player functionality provided in accordance with embodiments of the present invention by the various servers <b>120</b> and by each client computer <b>200</b> are generally provided by special purpose software installed on the respective computer and operable in connection with a processor and, in some cases, with general purpose software also installed on the respective computer and operable in connection with the respective processor. The same or similar functionality may be provided on both the server <b>120</b> and client computer <b>200</b>, depending upon the multi-player functionality requirements of a particular multi-player game and upon the configuration of the system <b>100</b> (e.g., client/server, client/client, etc.). At a minimum, the functionality provided on the client computer <b>200</b> will be a subset of the functionality provided on the server <b>120</b>. This relationship is depicted diagrammatically in FIG. 3, in which the client computer functionality and server functionality, and the interrelationship therebetween, is depicted. While FIG. 3 depicts a single client computer <b>200</b> in relation to a single server <b>120</b>, it should be noted that multiple client computers <b>200</b>, having the same or similar functionality, may also “map” the functionality of the server <b>120</b>, as depicted in FIG. 3.

[0044] With continued reference to FIG. 3, the functionality provided on a client computer <b>200</b> by the special purpose software in accordance with an embodiment of the present invention will now be discussed in detail. It will be obvious to persons skilled in the art that the special purpose software may be provided on any now known or hereafter developed storage medium (e.g., CD-ROM, DVD, etc.), downloaded to the client computer <b>200</b> (included on ROM or on cartridge), either in whole or in part, or otherwise loaded into memory of the client computer <b>200</b>, as a routine matter of design choice. The functionality is provided by a plurality of components including name service <b>202</b>, gaming <b>204</b>, lobby <b>206</b> (including matchmaker <b>208</b> and chat <b>210</b> components), tournament <b>212</b>, ranking system <b>214</b>, user registration <b>216</b>, and resource up/download <b>218</b> components. Each component provides functionality to facilitate communication between the client computer <b>200</b> and various functionality provided by the server <b>120</b>.

[0045] In the embodiment depicted in FIG. 3, each of the functionality provided by the special purpose software in the client computer <b>200</b> has a corresponding and complementary functionality in the server <b>120</b>. The connections between the client computer <b>200</b> and server <b>120</b> depicted in FIG. 3 are functional, and may not all concurrently exist, depending upon the functionality required at a particular point during game play. For example, the ideal service finder <b>130</b> and name service component <b>202</b> provide functionality to identify and locate, via symbolic names provided in a database on the ideal service finder <b>130</b>, various resources and other functionality not provided via the special purpose software on the client computer <b>200</b>. For example, a game server <b>134</b> may be provided as part of the primary data center <b>20</b> and also as part of a public server <b>1320</b>. During game play, the client computer <b>200</b> may require information from a game server <b>134</b> that can be provided to that player from a game server <b>134</b> located on a public server <b>1320</b> that is geographically closer to the player than the game server <b>134</b> in the primary data center <b>20</b>. The ideal service finder functionality facilitates the location of that closer game server <b>134</b>. The use of symbolic names by the ideal service finder functionality eliminates the need to hard-code a network location for game servers and thus permits movement of the network location of the desired resource or functionality. More than one ideal service finder <b>130</b> may be provided in the system <b>100</b> (i.e., an ideal service finder <b>130</b> may be provided in both the primary data centers <b>20</b> and public server <b>1320</b> ). If more than one ideal service finder <b>130</b> is provided, the database of symbolic names is replicated to all ideal service finders <b>130</b> in the system <b>100</b>.

[0046] With continued reference to FIG. 3, the game server <b>134</b> and gaming component <b>204</b> provide gaming functionality, which includes providing an in-game library and may facilitate game data communication between and among players during game-play. The game server <b>134</b> provides functionality to facilitate communication between and among client computers <b>200</b> through the server <b>120</b>. The game server <b>134</b> may have stored thereon game state and synchronization information, and game management responsibilities (as between the various client computers <b>200</b> and various servers that comprise the server <b>120</b> ). The corresponding gaming component <b>204</b> facilitates connection between the client computer <b>200</b> and a game server <b>134</b> (client/server architecture), or between client computers <b>200</b> (peer-to-peer architecture).

[0047] The matchmaker server <b>124</b> and the matchmaker <b>208</b> component provide matchmaking functionality to enable a player to locate game servers <b>134</b> in the network <b>10</b> that satisfy player-defined requirements (e.g., game name, number of players, rules, ping time). The matchmaker server <b>124</b> preferably has a database of game servers <b>134</b> located in the network <b>10</b> with specifications (e.g., game type, number of simultaneous players, etc.) for each game server <b>134</b> included in the database. More than one matchmaker server <b>124</b> may be provided in the system <b>100</b>.

[0048] Referring next to FIGS. <b>8</b>A-<b>8</b> C, the functionality of the matchmaker server <b>124</b> will now be discussed in greater detail. A matchmaker server <b>124</b> may have stored in a database thereon a list of game servers <b>134</b> for one or more multi-player games, e.g., game X, game Y, etc. When a client computer <b>200</b> requests a game server for game X via the matchmaker component <b>208</b>, matchmaker server <b>124</b> can return to the client computer <b>200</b> available game X game servers <b>134</b>. With that information returned to the client computer <b>200</b> from the matchmaker server <b>124</b>, the client computer <b>200</b> can connect to and participate in multi-player game play on any of the game X game servers <b>134</b>. Similarly, the matchmaker server <b>124</b> can direct a client computer <b>200</b> to a game Y game server <b>134</b>. For example, if client computer <b>200</b> desires to participate in game Y, a request may be communicated by the matchmaker component <b>208</b> resident on the client computer <b>200</b> to the matchmaker server <b>124</b> (designated as <b>1</b> in the figure). Matchmaker server <b>124</b> determines the game Y servers <b>134</b> available to the client computer, and communicates a list of those servers to the client computer <b>200</b> (designated as <b>2</b> in the figure). Selection of the game Y server <b>134</b> to which the client computer <b>200</b> ultimately connects is then left up to the user of the client computer <b>200</b>. In FIG. 8A, client computer has elected to connect with game server Syl (designated as in the figure).

[0049] Alternatively, and as depicted in FIG. 8B, the matchmaker server <b>124</b> can return to the client computer <b>200</b> a particular game X game server <b>134</b>, to which the client computer <b>200</b> can then connect and engage in multi-player game play of game X. In FIG. 8B, the client computer has communicated a request to the game server <b>124</b> (via the matchmaker component <b>208</b> ) for a list of any game X server <b>134</b> (designated as <b>1</b> in the figure). Game server <b>124</b> returns information on game server Sx<b>2</b> to the client computer <b>200</b> (designated as <b>2</b> in the figure). The client computer <b>200</b> then establishes a connection to game server Sx<b>2</b> (designated as <b>3</b> in the figure).

[0050] In another embodiment, depicted in FIG. 8C, a plurality of matchmaker servers <b>124</b> may have respectively stored thereon lists of game servers <b>134</b> for one or more multi-player games, e.g., game X, game Y, game Z, etc. That configuration provides enhanced reliability and load balancing between and among the plurality of matchmaker servers <b>124</b>. If one matchmaker server <b>124</b> is experiencing problems or is overwhelmed with requests from a plurality of client computers <b>200</b>, another matchmaker server <b>124</b> can provide matchmaker functionality. A request from client computer A for a game X server may be handled by matchmaker server <b>1</b> (MM<b>1</b>) or <b>2</b> (MM<b>2</b>), both servers having information on game X servers. Similarly, matchmaker server <b>2</b> (MM<b>2</b>) and <b>3</b> (M<b>3</b>) can handle request for game Y servers.

[0051] In each of the above-described embodiments of the matchmaker server <b>124</b> (depicted in FIGS. <b>8</b>A-<b>8</b>C), the request from the client computer <b>200</b> to locate a game server <b>134</b> may include certain performance characteristics desired of the game server <b>134</b> and client computer <b>200</b> and the connection therebetween. For example, a client may submit, in its request to the matchmaker server <b>124</b>, criteria such as game name, number of players, rules, world in which the game is being played, and ping-time (e.g., best performance, least latency, random selection, etc.).

[0052] The chat server <b>180</b> and the chat component <b>210</b> provide chat functionality to enable players to communicate (typically via textual messages) over the network <b>10</b>, i.e., to send and receive instant messages, chat-room messages, group messages, and the like. The chat server can receive a textual message from the chat component <b>210</b> of a first client computer <b>200</b> (e.g., client A). Included in the message will be the identification of the desired recipient(s) (e.g., client B, client C, etc.). The chat server <b>180</b> receives that message, interprets the recipient(s), and transmits the message for receipt by the chat component <b>210</b> of the client computer(s) <b>200</b> of the desired recipient(s).

[0053] The tournament server <b>182</b> and the tournament component <b>212</b> provide tournament functionality that facilitates tournament game-play between and among a plurality of client computers <b>200</b>. The tournament server <b>182</b> provides a forum for registered clients to demonstrate their game skills by participating in game tournaments which server to eliminate and rank players according to their skill as demonstrated by their success over other players.

[0054] The ranking server <b>184</b> and the ranking system component <b>214</b> provide ranking functionality to track individual and/or group player statistics, compare players, rank players, etc.

[0055] The user (client) identification server <b>128</b> and the user registration component <b>216</b> provide user identification and registration functionality the permits players to register, assigns a unique player identifier for each player, defines player profiles for each player, and authorizes or denies player access to game services via the system <b>100</b>. The user (client) identification server <b>128</b> communicates directly with the data storage device <b>140</b> and database <b>144</b> provided in the primary data center <b>20</b>. New clients must first register, with that registration data being stored by the user identification server <b>128</b>.

[0056] The resource server <b>126</b> and the resource up/download component <b>218</b> provide resource functionality that enables a client to upload and download game resources from other servers to the client computer <b>200</b> during game-play. For example, a client may download new game graphics, updated sports statistics, post-production advertisements, and client-customized data (e.g., racetrack, player representations, etc.). A client may also upload client-customized data (e.g., from the client computer to the resource server <b>126</b> ). The resource server <b>126</b> may be provided in the primary data center <b>20</b> and may function as a master resource server and preferably includes complete data on the location in the network <b>10</b> of all available resources (e.g., all other public servers <b>1320</b>, rogue servers <b>1220</b>, and other unprotected servers <b>1120</b> ).

[0057] The server <b>120</b> (or one or more of the above-mentioned servers that may comprise the server <b>120</b> ), may also provide a buddy list manager that is operable in connection with the user (client) identification server <b>128</b>. For example, a client computer <b>200</b> may initiate a particular multi-player game with appropriate restriction instructions that only buddies of that client (as provided by the buddy list manager) can participate in that game.

[0058] An ideal service finder may also be provided by the server <b>120</b> (or by one or more of the above-mentioned servers) that enables a client to locate a service that best suits that client's particular requirements. For example, a client may locate optimal services on the Internet (i.e., the network <b>10</b> ) without experiencing any IP-related address problems. The ideal service finder maintains data (e.g., performance, local feedback, etc.) on registered services (i.e., those services of which the ideal service finder is aware) and utilizes that data in selecting an ideal service for a particular client requirement.

[0059] With reference next to FIGS. 4A and 4 B, special purpose software operable in connection with a processor of a client computer <b>200</b> in accordance with an embodiment of the present invention utilizes a cross-platform core (CPC) <b>320</b> which is a collection of modules that allows programmers to develop similar programs (i.e., games) operable on and in connection with multiple hardware and operating system platforms with minimal development overhead. For example, the CPC <b>320</b> provides cross-platform compatibility with Windows 95, 98, NT, Win 2000, Windows CE, Linux, Unix, Solaris operating systems, and with various hardware platforms and gaming consoles. The CPC <b>320</b> of the present invention enables multi-player computer games (or virtually any other software) installed and operating on a first hardware platform in connection with a first operating system to seamlessly communicate with multi-player computer games (in most cases, the same multi-player computer game) installed and operating on a second hardware platform in connection with a second operating system. The CPC <b>320</b> provides for cross-platform communication that enables game algorithms and programs to operate on different hardware platforms regardless of differences in operating systems, system application programmer interfaces (APIs), memory, file system, threads, times, etc. Thus, player A running a multi-player game utilizing the present invention and installed on a personal computer and living in New Jersey may play against player B having the same multi-player game installed on a Sega Dreamcast® and living in California.

[0060] The special purpose software also includes a communications (comm) engine <b>402</b> to facilitate communication (i.e., bi-directional data transfer) between an application module or code <b>302</b> and the operating system <b>310</b>, hardware devices <b>312</b>, and communication protocols <b>314</b> of the client computer <b>200</b>. The comm engine <b>600</b> (also referred to herein as a comm engine API) is a cross-platform library which provides standardized functionality for communication between certain hardware devices such as, for example, choosing, initializing, connecting, and sending/receiving data to/from a device. The comm engine <b>600</b> comprises a service layer <b>410</b> and a device layer <b>450</b>. The CPC <b>320</b> and comm engine <b>600</b> provide a communication foundation for software application development and that provides hardware, software, and protocol independence, and that provides for customizable software algorithm features. The CPC <b>320</b> eliminates the need for software programmers to consider communication details (i.e., protocols) when writing a multi-player computer game.

[0061] The CPC <b>320</b> identifies the computing device hardware platform and operating system, provides a cross-platform ANSI C library, a cross-platform hardware emulation layer (HEL), and provides release and debug options. The CPC ANSI C library includes main system files such as, for example, hardware platform target and storage type files, ANSI C compatibility layer files, and advanced hardware abstraction layer (HAL) files. Those files in turn will include the various sub-components of the CPC <b>320</b>, as discussed in more detail below. The various sub-components can be called individually, or through their grouping file or through the complete file listing.

[0062] The platform target and storage type files contain all the definitions and constants which are required to determine platform specific functionality as well as cross-platform type standards.

[0063] The ANSI C compatibility layer file contains ANSI C compatible functionality definitions. The ANSI compatibility layer file provides function that are found in the ANSI C library. That includes standard features such as, by way of non-limiting example, memory, string and math. The ANSI C compatibility layer file provides those features without any operating system deviations. For example, although ANSI C has defined standard ways to carry out time functions, certain operating systems use modified versions of that standard. Thus, it is difficult to develop time functions that are portable across multiple operating systems. The ANSI C compatibility layer file obviates that problem by providing ANSI-equivalent interfaces to access time functions in any operating system. In addition, certain operating systems may not provide a full ANSI C library. In that case, the ANSI C compatibility layer file of the present invention provides the missing functionality.

[0064] The advanced HAL files include functionality that are not included as part of the ANSI C standard. That includes functions that define what operating system is running, threads, debugging and other important functions that are fairly standard but not available or not consistent on all platforms. For example, C++ new and delete functions may be defined in these files.

[0065] Referring next to FIGS. 4A and 4B, the components and architecture of the special purpose software of the present invention will now be discussed in detail. A multi-player game constructed in accordance with the present invention will have the architecture generally depicted in FIG. 4A and generally designated by reference numeral <b>300</b>. The game <b>300</b> includes an application component or module <b>302</b> which comprises the application software specific to the game type (e.g., sports, fast twitch, turn-based, etc.). The application module <b>302</b> interfaces directly with the core technology which comprises a communications (comm) engine <b>600</b> that sits on top of a cross-platform core (CPC) <b>320</b>. The CPC <b>320</b> comprises a plurality of files (i.e., a collection of modules) that enables programmers to develop similar programs (e.g., multi-player computer games) that will run on multiple hardware and operating system platforms with minimal software development overhead. The CPC <b>320</b> provided cross-platform compatibility with Windows 95, 98, NT, Win 2000, Windows CE, Linux, Unix, Solaris and various gaming consoles. Thus, multi-player computer games may be quickly and easily developed to operate in connection with any hardware and software platform and configuration, and to communicate with any other hardware and software platform and configuration.

[0066] The comm engine <b>600</b> provides the interface between the application module <b>302</b> and the operating system <b>310</b> and various hardware devices <b>312</b> and communication protocols <b>314</b> specific to each computing device hardware platform. When writing the application module <b>302</b>, the software developer need not code to a specific operating system, nor consider the hardware or protocol requirements of a particular hardware platform. Instead, the application module <b>302</b> is written (i.e., coded) to interface to the comm engine <b>600</b>, may be run on any operating system, and may utilize any hardware device and communication protocol supported by the comm engine <b>600</b>. The comm engine <b>600</b> is a general-purpose cross-platform communications engine that makes programming network applications quicker, simpler, more efficient and more robust. It provides a technological foundation for multi-player games and web-based applications. The comm engine <b>600</b> satisfies cross-platform necessities, and may support operating systems such as, by way of non-limiting example, Microsoft Windows 95, 98, 2000, NT, and CE, Linux, Solaris, SGI, personal digital assistant (PDA) operating systems, and wireless operating systems. It will be obvious to persons skilled in the art, and from the disclosure provided herein, that other now known or hereafter developed operating systems may also be supported by the comm engine <b>600</b>.

[0067] The comm engine <b>600</b> includes a comm engine API <b>402</b>, which includes a main module <b>404</b>, message (msg) module <b>406</b>, external api (ex_api) module <b>408</b>, error (err) module <b>412</b>, and service protocol (svc prot) module <b>414</b>. The message module <b>406</b> provides the application <b>302</b> a generic way to send data through the comm engine infrastructure without the client having to wary about memory allocation and speed issues. The error module <b>412</b> is used by comm engine <b>600</b> as a way to let the client know that an error has occurred in the comm engine <b>600</b>. Along with the broad errors, helper functions are provide in other to extend the functionality of the error module <b>412</b>. These helpers provide a textual representation of the errors. The service protocol module <b>414</b> extends the functionality of comm engine <b>600</b> by providing commonly used services like compression and encryption to the client.

[0068] The comm engine <b>600</b> interfaces with a service layer <b>410</b> which includes a channel manager (chan mgr) <b>416</b>, a session manager (sess mgr) <b>418</b>, and a message queue manager (msg queue mgr) <b>452</b>. The channel manager <b>416</b> manages channel lists for the sessions. The session manager <b>418</b> drives the channel manager <b>416</b> by causing it perform operations on its channel lists. Any tasks that need to be performed through the device layer channels will be processed via the channel manager <b>416</b>. An example would be sending a message through the device layer <b>450</b>. Each channel contains send and receive queues, a device protocol, device information, addressing information, a software protocol stack, and configuration information.

[0069] The service layer <b>410</b> shields application modules <b>302</b> of specific operating systems (OS), hardware device, and communication protocol requirements. Programmers need only code to the service layer <b>410</b> (via the comm engine <b>600</b> ), which performs all conversions required for the application module <b>302</b> to interface to the operating system and various devices and protocols. The service layer <b>410</b> also provides access by the application module <b>302</b> to advanced engine protocols and permits software developers to easily insert custom application protocols.

[0070] The service layer <b>410</b> may be generally considered a hardware-emulating layer (HEL) because it forwards hardware implemented calls to the device layer <b>450</b> and may supply hardware features/emulation. The service layer <b>410</b> may also supply optional internal protocols that can be used by the application module <b>302</b>, if needed. The service layer <b>410</b> may also permit an application module <b>302</b> to supply its own protocols, which can be inserted at different points within the service layer protocol stack <b>420</b>, an illustrative example of which is depicted in FIG. 5. That protocol stack <b>420</b> includes high protocol functionality such as compression <b>422</b>, encryption <b>424</b>, keep alive <b>426</b>, and stream support <b>428</b>, and low protocol functionality including advanced routing techniques, <b>430</b>, error correction <b>434</b>, buffering <b>436</b>, guaranteed messages <b>438</b>, virtual ISP <b>440</b>, and insert noise/debug <b>442</b>.

[0071] Send priorities can be used by the protocol stack <b>420</b> to optimize bandwidth, optimize protocol buffer management and conserve CPU usage. In essence it allows outgoing packets to be combined if possible into a single outgoing packet. Every incoming and outgoing packet must be packed, processed, cause a CPU context switch, do hardware send, etc. If no optimization is done, high packet counts can cause significant local overload and latency. Depending on the particular communication medium employed by an application module <b>302</b>, send priorities may be optimized. When accessing the Internet using a relatively slow connection (e.g., 28.8 K modem), latency may be greater than 200 milliseconds (ms). With that knowledge, normal priority packets may be grouped within a predetermined time window. As an example, any pending normal packets not timed to be sent yet, may be flushed and sent if a high priority packet is about to be sent. The expiration time window for each send priority can be configured so that send priorities can map to send within the next predetermined time window.

[0072] The buffering <b>436</b> protocol of the service layer protocol stack <b>420</b> may consider any unnecessary memory allocations, freeing, copying, etc. In addition, internal receive buffers may be directly examined, used, and copied. An example of some of the optimal packet manipulation operations is the ability to add/remove header/footer from the data packet with high probability that no memory allocations/free/copying will be done. A dynamic protocol buffer pool is also provided, containing pre-allocated and previously configured protocol buffers for use as needed.

[0073] The virtual ISP protocol <b>440</b> provides all the necessary hooks to simulate an application's performance over the Internet. The virtual ISP protocol <b>440</b> enables an application module <b>302</b> to be tested using a LAN configured (from the application module's perspective) as an Internet ISP connection. The virtual ISP protocol <b>440</b> enables simulation, to the service layer <b>410</b>, of the following situations: random failure to connect, random loss of connection, random latency injection with variance, and random loss of packets. The virtual ISP protocol <b>440</b> options are fully configurable to provide the many types of ISP connections over different mediums. For example, both tier I and tier <b>3</b> Internet connections may be simulated. Fast or slow connections and device behavior, such as disconnect packet drops, may also be simulated using the virtual ISP protocol <b>440</b>.

[0074] Another benefit of the virtual ISP protocol <b>440</b> is security. Connection to the Internet is no longer required to see how communications software will behave.

[0075] The device layer <b>450</b> is the low-level, cross-platform, device independent layer of the comm engine <b>600</b>. It handles the operating system specific API calls, platform specific issues of byte-ordering and data alignment, and device specific programming techniques to present a common API for all platforms. The device layer <b>450</b> provides a unified interface to different communication devices on all operating systems; for direct and immediate function performance; makes it easy to add new devices by adding a new device API; hides operating system specific details from the software engineer; hides details of device-specific types or structures from the software engineer; hides details of device-specific APIs from the software engineer; can be used as a direct API to devices (for example, the device layer will map a generic “SEND( )” command to a specific “DevApi_Send( )” command); and provides a common interface regardless of the intended operating system, platform, network protocol, etc., the application module <b>302</b> is intended to operate on or in connection with.

[0076] The device layer <b>450</b> hides implementation details about different networking protocols, operating systems and communications devices. In this way, programming a modem on the Linux OS using a dial-in mechanism is programmed from a higher level exactly the same as a Windows machine using a network interface card (NIC) and the TCP/IP protocol. From the application module's <b>302</b> perspective, the same sequence of subroutine calls are used and only the addressing parameters are different. Additionally, the different address types can be prepared using helper subroutines so that the actual implementation of the address is hidden from the user.

[0077] The device layer <b>450</b> provides a unified interface to all hardware devices and protocols for any operating system. The device layer <b>450</b> contains all the hardware platform specific code, including any code that deals with different hardware, protocol implementations and the various operating systems. Thus, support in the comm engine <b>600</b> for a new operating system, network device or protocol may be done by adding support for it in the device layer <b>450</b> alone.

[0078] The device layer <b>450</b> may be considered a hardware abstraction layer (HAL) and includes code to provide an interface between an application module <b>302</b> (via the service layer <b>410</b> ) and various devices (i.e., hardware platforms), operating systems, and networking protocols.

[0079] The comm engine <b>600</b> generally has three modes of usage: pass-through mode; synchronous mode; and asynchronous mode. Each mode utilizes the functionality of the comm engine <b>600</b> differently. These modes and how they require usage of the comm engine <b>600</b> functions are described in more detail below, and with reference to FIGS. 6 and 7.

[0080] In pass-through mode, depicted in FIG. 6, the comm engine <b>600</b> acts as an interface to the functionality of the device layer <b>450</b>. An additional feature of pass-through mode is the ability to set data filters through which the data is passed before being communicated over the network <b>10</b> (with corresponding filters on reception). For example, data may be compressed and/or encrypted before being transmitted and then decrypted and decompressed when received.

[0081] For pass-through mode operation, the application module <b>302</b> creates a session and then creates and opens channels in that session. Connections are accepted if applicable, and data is sent back and forth directly between the device layer <b>450</b> and application module <b>302</b> via the comm engine <b>600</b> without buffering or queuing the data in any way. Essentially, pass-through mode expects that the application module <b>302</b> is familiar with network program and is simply using the comm engine <b>600</b> to hide device, protocol, and operating system details.

[0082] Data flow for synchronous and asynchronous mode operation of the comm engine <b>600</b> is depicted in FIG. 7. In asynchronous or synchronous mode, the comm engine <b>600</b> buffers data, provides data filtering services, and queues messages for the application module <b>302</b>. Additionally, an event-driven methodology may be employed in which the library user (i.e., the application module <b>302</b> ) is notified about events such as a new connection, when new data has been received, channel disconnection, etc.

[0083] In synchronous mode, depicted in FIG. 7, the application module <b>302</b> controls when the comm engine <b>600</b> performs its work. It is different from the pass-through mode in that message queues and notification methods are available so an event-driven methodology may be used when programming the application module <b>302</b>. However, the comm engine <b>600</b> must frequently and unequivocally be permitted to perform work by calling a subroutine that enables synchronous operation and functionality, such as CommEng_DoSynchronousWork (discussed in more detail below). The term “subroutine”, as used herein, includes subroutines, callbacks, functions, etc., and is used herein to refer to instances where additional functionality is provided to/for an application program by virtue of that application program (or an application program relating thereto) invoking, executing, causing to execute, etc., another application having that additional functionality. The subroutine may perform some functionality for the application program, receive data from and pass data to the application program (or to another application program, subroutine, library, etc.), invoke other subroutine(s), etc., as directed by the application program. The subroutine names provided herein are merely illustrative, non-limiting examples of names used to facilitate discussion of the present invention and are not intended to define or otherwise limit the scope of the present invention, it being obvious to persons skilled in the art and from the disclosure provided herein that any subroutine name may be used. The functionality of the various subroutines referred to herein as described in more detail below.

[0084] Synchronous mode is useful for taking advantage of priority message queues and the event-driven programming paradigm. In synchronous mode, no threads are used in the underlying networking code and the comm engine <b>600</b> only does its processing of data when the application module <b>302</b> calls a subroutine such as the CommEng_DoSynchronousWork. Additionally, the application module <b>302</b> may take advantage of several protocol services (such as encryption, compression, streaming, etc.) without having code specific to that functionality.

[0085] In asynchronous mode, depicted generally in FIG. 7, the comm engine <b>600</b> runs using threads and allows the programmer (i.e., the application module <b>302</b> ) to be notified when an event occurs asynchronously. For instance, when a new connection occurs, the application module <b>302</b> will be notified via an appropriate notification method. Whenever data is available on a channel of communication, the application module <b>302</b> is notified that the data is available in the same way, thus obviating the need for the application module <b>302</b> to poll for events and also prevents the application module <b>302</b> from having to allow the comm engine <b>600</b> to work periodically.

[0086] Asynchronous mode is similar to synchronous mode except that there is no need to cause the comm engine library to call the CommEng_DoSynchronousWork subroutine, or to create threads to handle performing network communications asynchronously.

[0087] When the application module <b>302</b> sends data, a CommEng_Send subroutine is called which results in a message getting placed onto an appropriate send queue. The send queue is eventually processed (either when the CommEng_DoSynchronousWork subroutine is called or when an internal thread does so) and each message is passed to a ChanMan_ProcessSend subroutine which in turn routes it to either the appropriate channel's protocol stack or directly down to the device layer <b>450</b>.

[0088] The functionality provided by the comm engine <b>600</b> is provided, at least in part, by subroutines invoked by the comm engine <b>600</b>. Those various subroutines enable the comm engine <b>600</b> to operate in pass-through mode, synchronous mode, or a asynchronous mode, as required by the application module <b>302</b>. Those subroutines also shield the application module <b>302</b> from the specific hardware, operating system, and protocol requirements of specific computing device. Thus, the comm engine <b>600</b>, service layer <b>410</b>, and device layer <b>450</b>, and the various comm engine subroutines, facilitate rapid and economic development of multi-player computer games and facilitate and manage communication between and among players in computing devices, regardless of differences in hardware, operating system, or protocol for those computing devices, to provide seamless conductivity among game players over a network.

[0089] The following description and names for the comm engine <b>600</b> subroutines are provides as illustrative, non-limiting examples to facilitate discussion of the present invention.

[0090] CommEng_Startup

[0091] This subroutine causes the application module <b>302</b> to initialize any necessary libraries. In the case where the implementation is a static library, this subroutine is called only once by the application module <b>302</b> to allocate and initialize global library resources. If the implementation is as a shared library (.so) or Dynamic Link Library (.DLL), then each executable (provided as part of or used by or in connection with the application module <b>302</b> ) which makes use of the comm engine <b>600</b> calls the CommEng_Startup subroutine before accessing any other subroutines. That ensures that the comm engine <b>600</b> library is initialized properly for performance and memory management reasons.

[0092] The comm engine <b>600</b> keeps a reference count of current users of the comm engine <b>600</b> so that it knows when it can unload itself from memory and perform other cleanup tasks.

[0093] CommEng_Shutdown

[0094] This subroutine is called when the comm engine <b>600</b> is no longer necessary to the executable file or software module <b>302</b> using it's API. By calling this subroutine, the library reference count is reduced and any unnecessary resources are de-allocated and given back to the system (i.e., made available for use by the computing device hardware and software) as appropriate. As used herein, the term “system” refers generally to the computing device and general and special purpose software.

[0095] CommEng_OpenSession

[0096] This subroutine is called by the application module <b>302</b> to create and initialize a session. A session can be open in three ways. For pass-through operation, an eCommSession_PassThrough subroutine may be invoked by which the service layer <b>410</b> does the minimum amount of work on the data and simply passes the data straight to the device layer <b>450</b>. For synchronous operation, an eCommSession_Sync subroutine may be invoked, which is recommended for a platform that does not have threads. That subroutine allows the service layer <b>410</b> to function as if threads are available in the system. When an eCommSession_Sync session is opened, the application module <b>302</b> (or other application that established that session) is responsible for ticking the service layer <b>410</b> in a timely manner.

[0097] For asynchronous operation, an eCommSession_Async subroutine may be invoked, which provides the most efficient and fastest way to open a session. The application module <b>302</b> is notified of any data or errors that occur through the callback subroutine.

[0098] If synchronous or asynchronous mode with notifications is required, then the pNotifyMethodData parameter must point to a structure providing the notification details.

[0099] CommEng_CloseSession

[0100] This subroutine is called to destroy and cleanup an existing session.

[0101] CommEng_GetDeviceCount

[0102] This subroutine returns the number of communications devices on the system.

[0103] CommEng_GetCommDevices

[0104] This subroutine is called to retrieve the list of COMM_DEVICE_ID's (i.e., communication device) and/or the count of devices detected which other APIs may use to determine further information about each device ID. When called with a NULL pointer for pCommDevices, then the number of items retrieved is returned. The application module <b>302</b> preferably allocates (size of(COMM_DEVICE_ID)* number of devices) bytes and passes that buffer to this subroutine in the next call.

[0105] CommEng_GetDeviceCaps

[0106] This subroutine returns the capabilities of the device specified by DeviceID. This subroutine can be used to determine which device to use based on its type and capabilities.

[0107] CommEng_GetDeviceType

[0108] This is a helper subroutine, which returns the type of the device specified by DeviceID.

[0109] CommEng_GetProtocolCount

[0110] This subroutine returns the number of communications protocols registered on the system.

[0111] CommEng_GetCommProtocols

[0112] This subroutine works similar to the CommEng_GetCommDevices subroutine except that it returns communications protocols instead of communications devices. When called with a NULL pointer for pCommProtocols, the number of registered protocols is returned. Tip Allocation of (sizeof(COMM_PROTOCOL_ID)* Number of Protocols) bytes may be buffered and passed to this subroutine on a subsequent call. The caller can then retrieve the capabilities of each protocol. Note that it is more efficient to call CommEng_GetProtocolCount rather than this subroutine with a NULL pointer for the first parameter.

[0113] CommEng_GetProtocolID

[0114] This subroutine is called to get a pointer to the COMM_PROTOCOL_ID given a communications protocol enumeration value.

[0115] CommEng_GetProtocolCaps

[0116] This subroutine retrieves the communication protocol's capability structure, which may then be used to determine the specified protocol's capabilities.

[0117] CommEng_CreateChannel

[0118] This subroutine is called to allocate a channel. If a configuration structure is supplied then it will be used to configure the channel. Otherwise the channel may be configured as necessary before or after opening.

[0119] CommEng_OpenChannel

[0120] This subroutine is called to open a channel for sending and/or receiving data, as defined below in Table 1. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77PT" align="center" /><colspec colname="2" colwidth="140PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 1</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ChannelID</entry><entry>The ID of the to open.</entry></row><row><entry>PRemoteAddress</entry><entry>Remote address to open (if applicable).</entry></row><row><entry>PLocalAddress</entry><entry>Local address to open (if applicable).</entry></row><row><entry>CommProtID</entry><entry>Communication protocol ID to use.</entry></row><row><entry>DeviceID</entry><entry>Device ID with which to open the channel.</entry></row><row><entry>dwFlags</entry><entry>Channel open flags - to be documented</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0121] CommEng_CloseChannel

[0122] This subroutine is called to close an open channel. It may be re-opened if necessary. Note that this subroutine does not de-allocate all resources allocated to an existing channel (CommEng_DestroyChannel's described below, below does that).

[0123] CommEng_DestroyChannel

[0124] This subroutine is called to de-allocate a channel. If necessary, it will close a channel before destroying it.

[0125] CommEng_SetChannelConfig

[0126] This subroutine is called to configure a channel's attributes and software protocol stack as necessary, as defined below in Table 2. <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77PT" align="center" /><colspec colname="2" colwidth="140PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 2</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ChannelID</entry><entry>The ID of the channel to configure</entry></row><row><entry>pChanConfig</entry><entry>The configuration information structure.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0127] CommEng_GetChannelConfig

[0128] This subroutine is called to retrieve the channel configuration attributes, as defined below in Table 3. <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77PT" align="center" /><colspec colname="2" colwidth="140PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 3</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ChannelID</entry><entry>The ID of the channel of which to get the</entry></row><row>&lt;entry /&gt;<entry>configuration information.</entry></row><row><entry>pChanConfig</entry><entry>The configuration information structure.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0129] CommEng_PeekMsg

[0130] This subroutine allows a user (i.e., application module <b>302</b> or comm engine API <b>402</b> ) to look at the next message in the queue if there is one. The ppMsg parameter is stuffed with a pointer to an internal message buffer in the comm engine <b>600</b>, and is treated as read-only and used for peeking only. The CommEng_RecvMsg (see description below) subroutine may be called to remove the message from the buffer. If ppMsg is NULL then the message pointer will not be filled. The subroutine will simply return a code indicating whether or not there is data. If there is a message, then CommEng_Peekmsg will set pbData to a non-zero value. If there is no message, the value pointed to by pbData it will be set to zero.

[0131] CommEng_RecvMsg

[0132] This subroutine is called to retrieve a message from the message queue. When calling it, the pointer ppMsg gets filled with a pointer to the appropriate message data structure. Message helper subroutines (i.e. message crackers) can be called to extract the appropriate data from each message type. The caller must de-allocate the message by calling CommEng_FreeMsg when they are finished with it.

[0133] CommEng_Send

[0134] This subroutine is called to send data, and is defined below in Table <b>4</b>. If queue buffering is not enabled for the associated session (i.e., in pass-through mode), then the message is simply sent out (after optionally being processed by data filters in the channel's protocol stack). Otherwise, the data is placed onto the appropriate send queue and processed at the appropriate time. When the message is processed, it is sent through the channel's software protocol stack and then eventually to the device layer <b>450</b>. Internally, in pass-through mode, if the channel is configured to use a protocol stack, then a COMM_MSG structure is allocated and the data is filtered through the protocol stack's data filter protocols. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="center" /><colspec colname="2" colwidth="147PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 4</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ChannelID</entry><entry>Channel ID through which to send the data.</entry></row><row><entry>pDestAddress</entry><entry>Destination address (if applicable)</entry></row><row><entry>dwDataSize</entry><entry>The size of the data buffer</entry></row><row><entry>pvData</entry><entry>Points to a buffer of data to send.</entry></row><row><entry>dwSendFlags</entry><entry>Send flag may be any combination of the</entry></row><row>&lt;entry /&gt;<entry>following:</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_SND_NOFLAGS</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_SEND_BROADCAST</entry></row><row><entry>pMsgFlags</entry><entry>Points to a structure containing flags for this</entry></row><row>&lt;entry /&gt;<entry>particular message to be sent. These flags</entry></row><row>&lt;entry /&gt;<entry>specify settings for the software protocol stack</entry></row><row>&lt;entry /&gt;<entry>as well as priority, timeout, etc. See the</entry></row><row>&lt;entry /&gt;<entry>description of the COMM_MSG_FLAGS</entry></row><row>&lt;entry /&gt;<entry>structure below. If pMsgFlags is NULL then</entry></row><row>&lt;entry /&gt;<entry>the default configuration of the protocol stack</entry></row><row>&lt;entry /&gt;<entry>is used.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0135] CommEng_SendMsg

[0136] This subroutine can be used to send an existing message. This subroutine is useful when the user wants to send a custom message type or when a received message is to be echoed or forwarded.

[0137] CommEng_Peek

[0138] This subroutine is a pass-through subroutine to the device layer's COMM_Peek API subroutine, as defined below in Table <b>5</b>. However, if a channel has been closed from the remote end, it is not always possible for the CommEng_Peek to detect this. Sometimes, the subroutine will return successfully that there is data, but the data happens to be the fact that the channel was closed remotely. Therefore, a send or receive operation on the channel will then cause the disconnection to be detected. <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63PT" align="center" /><colspec colname="2" colwidth="154PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 5</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ChannelID</entry><entry>The channel on which to peek for data.</entry></row><row><entry>pbDataAvail</entry><entry>On return, a non-zero value specifies that there is</entry></row><row>&lt;entry /&gt;<entry>data available. It is zero otherwise.</entry></row><row><entry>dwFlags</entry><entry>Peek flags may be any combination of the</entry></row><row>&lt;entry /&gt;<entry>following:</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_PEEK_DATATORECV</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_PEEK_CONNTOACCEPT</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_PEEK_OPENCONNECTION</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_PEEK_WAIT_FOR EVER</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0139] CommEng_Recv

[0140] This subroutine is called to receive data directly on a channel, as defined below in Table 6. It will block until there is data to be received or the timeout occurs (as per the channel's configuration) so the caller must handle the possibility that it doesn't return right away. If the receiving channel (i.e., ChannelID) is configured with a protocol stack, then the data is processed up through the protocol stack before being returned to the caller. Unless the API is being used as a pass-through to the device layer, the caller should use to CommEng_RecvMsg to retrieve data and messages asynchronously. It should be noted that the user must de-allocate the data buffer returned since this subroutine will allocate the data and return a pointer to that data. <tables id="TABLE-US-00006" num="6"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="77PT" align="center" /><colspec colname="2" colwidth="140PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 6</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ChannelID</entry><entry>ID of the channel from which to receive data.</entry></row><row><entry>pSrcAddress</entry><entry>The source address of the received data (if</entry></row><row>&lt;entry /&gt;<entry>applicable).</entry></row><row><entry>dwBufferSize</entry><entry>The size of the buffer pointed to by pvData.</entry></row><row><entry>pvData</entry><entry>The address of user allocated buffer.</entry></row><row><entry>pdwRecvDataSize</entry><entry>Filled with the size of the data read.</entry></row><row><entry>dwRecvFlags</entry><entry>Receive flags may be any combination of the</entry></row><row>&lt;entry /&gt;<entry>following:</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_RECV_NOFLAGS</entry></row><row>&lt;entry /&gt;<entry>COMMDVC_RECV_GETSRCADDR</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0141] CommEng_AcceptConnection

[0142] Calling this subroutine allows a channel to wait for a connection. This is to be used in pass-through mode and with a connection oriented protocol only.

[0143] CommEng_DoSynchronousWork

[0144] When in synchronous mode, the user must call this subroutine to allow the comm engine <b>600</b> to perform its tasks. The user must ensure that this subroutine is called frequently enough to handle the amount of data that needs to be sent and/or received.

[0145] CommEng_AllocMsg

[0146] This subroutine allocates a message based on the input parameters, as defined below in Table 7. <tables id="TABLE-US-00007" num="7"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63PT" align="center" /><colspec colname="2" colwidth="154PT" align="left" /><thead><row><entry namest="1" nameend="2" align="center">TABLE 7</entry></row><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Parameters</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ppMsg</entry><entry>Pointer which is filled with the address of the new</entry></row><row>&lt;entry /&gt;<entry>msg.</entry></row><row><entry>dwDataSize</entry><entry>Size of the data pointed to by pvData.</entry></row><row><entry>pvData</entry><entry>Address of data buffer to use as the source of the</entry></row><row>&lt;entry /&gt;<entry>message.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0147] CommEng_FreeMsg

[0148] This subroutine frees (i.e., returns to internal Msg pool) the message structure specified by the pointer.

[0149] CommEng_IsError

[0150] This subroutine will return non-zero if eErrorCode is an error, or zero otherwise. Additionally, if eErrorCode is an error, in debug mode, it will print out the error message's text description and the szFunctionName parameter so that the debug output contains the name of the subroutine that detected the error.

[0151] CommEng_IsProtocolSupported

[0152] This subroutine returns non-zero if the specified device (DeviceID) supports the device protocol indicated by ProtocolID.

[0153] The channel manager <b>416</b> module interface functionality and associated subroutines will next be discussed in more detail.

[0154] ChanMan_CreateChannel

[0155] This subroutine creates a channel structure and initializes it appropriately based on the flags specified. Additionally, the channel is added to the appropriate session's channel list. This is called by the CommEng_CreateChannel API subroutine to actually create the channel structure since the channel manager <b>416</b> hides the implementation.

[0156] ChanMan_OpenChannel

[0157] This subroutine actually opens the channel. A channel must be opened before it can be used to send or receive data. This is called by the CommEng_OpenChannel API subroutine.

[0158] ChanMan_InitChannelFromID

[0159] This subroutine initializes a comm engine <b>600</b> channel based on the device layer channel ID and address information.

[0160] ChanMan_CloseChannel

[0161] This subroutine is called to close a channel. Note that its resources are not de-allocated but rather, the channel is placed into an inactive mode. This is called either internally when a channel is closed implicitly or it is called via the CommEng_CloseChannel API subroutine.

[0162] ChanMan_DestroyChannel

[0163] This subroutine destroys the specified channel and ensures that any necessary cleanup is performed. The cleanup includes removing the channel from the appropriate session's channel list. This subroutine is called whenever a channel's resources must be de-allocated such as when the corresponding session shuts down or the channel is no longer needed. If the channel is still open, this subroutine will call the CommEng_CloseChannel subroutine to close it first before destroying it. This ensures that any reference counts are valid regardless of how a channel is destroyed.

[0164] ChanMan_InitChannelList

[0165] This subroutine creates and initializes the channel list for the specified session. Since the implementation of the channel list is hidden from the session manager <b>418</b> by the channel manager <b>416</b>, this subroutine is called to initialize the channel list.

[0166] ChanMan_DestroyChannelList

[0167] This subroutine destroys the channel list for the specified session.

[0168] ChanMan_ProcessSend

[0169] The send subroutine calls the appropriate protocol stack's send subroutine to do the actual processing (if necessary) and sending of the data or message. The message queue manager <b>452</b> will call this subroutine when it processes the send queues. When something is to be sent, the ChanMan_ProcessSend subroutine is ultimately called. This subroutine pushes the data through its protocol stack and then proceeds to send it down to the device layer <b>450</b>.

[0170] ChanMan_ProcessRecv

[0171] The ChanMan_ProcessRecv subroutine is called to process the message received before placing the message onto the queue to be retrieved or peeked by the library user. The subroutine may be called to pull a message from the protocol stack which is then placed onto the channel's receive queue by the caller. However, the protocol stack may have it's own receive queue, in which case this subroutine is called directly by the CommEng_RecvMsg API subroutine. When something comes in from the device layer <b>450</b>, ChanMan_ProcessRecv is called to process the data before being placed onto the message queue.

[0172] ChanMan_DoAsyncWork

[0173] This subroutine is the entry point to a channel's protocol stack tick subroutine. This subroutine is called by the session manager <b>418</b> to allow each channel a chance to do it's processing.

[0174] A channel configuration manager manages configuring the channel to use a specific device, device protocol, and a software protocol stack. It is mainly driven by the channel manager <b>416</b> to perform tasks on a channel's configuration substructure or by the comm engine <b>600</b> to configure a channel.

[0175] Each channel has its own channel specific configuration. This configuration includes a software protocol stack, the device with which it is associated, the device protocol being utilized to transport the data, and other attributes such as whether it is opened in send, receive, or send and receive mode.

[0176] The channel configuration manager's module API includes functions to enable the following: add/remove protocols to a channel's protocol stack; set the device protocol to use (this may be changeable at runtime via the channel manager <b>416</b> by saving the attributes that are needed to create the channel, closing the device layer channel, opening another device layer using the new device protocol, and setting the current Comm_channel's device layer channel ID to the newly created channel ID in the device layer); set the device to use; and set or change other attributes.

[0177] ChanCfg_DestroyChanCfg

[0178] The channel manager <b>416</b> calls this subroutine to de-allocate the configuration data for a channel.

[0179] ChanCfg_CopyChannelCfg

[0180] This helper subroutine copies the data from the source channel configuration structure to the destination structure.

[0181] The session manager <b>418</b> manages sessions and session specific data such as notification methods and channel lists. Each session has its own notification methods, channel lists, and session specific data and configurations of the library.

[0182] The session manager <b>418</b> drives the rest of the library including the channel manager <b>416</b> and message queue manager <b>452</b>. The channel manager <b>416</b> manages the sessions' channel lists. The message queue manager <b>452</b> manages the global comm engine <b>600</b> message queues.

[0183] A callback subroutine is registered with the device layer <b>450</b> to handle messages that are received. When a message is received, it is placed onto the receive queue (via a call to the message queue manager <b>452</b> ) and then the user is notified using the appropriate notification method set up for that particular session.

[0184] The session manager module interface functionality and associated subroutines will next be discussed in more detail.

[0185] SessMan_StartUp

[0186] This subroutine starts up the session manager <b>418</b>. All one-time initialization is done here.

[0187] SessMan_ShutDown

[0188] When called, this subroutine shuts down the session manager <b>418</b> and all resources used by the session are cleaned up.

[0189] SessMan_AddSession

[0190] This subroutine creates and initializes a session, including all necessary allocations of data specific to a session.

[0191] SessMan RemoveSession

[0192] This subroutine destroys a session and performs any necessary cleanup for the specified session.

[0193] SessMan_SetConfig

[0194] This subroutine allows the user to configure a session by state.

[0195] SessMan_GetConfig

[0196] This subroutine retrieves the current session state configuration.

[0197] SessMan_SetNotificationMethod

[0198] This subroutine sets the notification method and data for the specified session.

[0199] SessMan_DoSynchronous

[0200] This subroutine allows the session manager <b>418</b> to perform any necessary synchronous work. This subroutine in turn allows the channel manager <b>416</b> to perform synchronous work on the appropriate channels if necessary.

[0201] The message queue manager <b>452</b> manages the comm engine <b>600</b> message queues. The session manager <b>418</b> drives the message queue manager <b>452</b> via its module interface. The architecture for the message queue manager <b>452</b> is very simple: it inserts messages into the appropriate queue based on priority. When messages are received via the callback subroutine registered with the device layer <b>450</b>, the message queue manager <b>452</b> processes the message via the channel's protocol stack and then places the message onto the appropriate queue. When messages are sent via the comm engine <b>600</b> send subroutine (e.g., CommEng_SendMsg), the message is placed onto the send queue based on its priority. When the message queue manager <b>452</b> processes the send queues, it calls the channel manager's <b>404</b> send subroutine (e.g., ChanMan_Send) to perform the actual send through the protocol stack.

[0202] The message queue manager <b>452</b> module interface functionality and associated subroutines will next be discussed in more detail.

[0203] MQMan_Startup

[0204] The startup subroutine creates and initializes the message queues.

[0205] MQMan_Shutdown

[0206] The shutdown subroutine destroys all queues and cleans-up after itself.

[0207] MQMan_InitChannelQueue

[0208] This subroutine initializes the specified channel's receive message queue.

[0209] MQMan_DeInitChannelQueue

[0210] This subroutine cleans up the specified channel's receive message queue.

[0211] MQMan_InsertSendMsg

[0212] This subroutine inserts a message onto the appropriate send queue based on priority. This will be called most often from the mechanism that handles sending and receiving data. This mechanism will be done through the session manager <b>418</b>.

[0213] MQMan_ProcessSendQueues

[0214] This subroutine is called by the session manager <b>418</b> to process all the messages in the send queues. Essentially, this subroutine traverses the send queues, de-references the channel pointer, and calls the channel's send subroutine.

[0215] MQMan_FlushSendQueue

[0216] This subroutine flushes the specified message queue. Queued messages may be processed or discarded.

[0217] MQMan_InsertRecvMsg

[0218] This subroutine inserts a message onto the proper channel receive queue. The session manager <b>418</b> calls this subroutine whenever it receives a message via the callback subroutine registered with the device layer <b>450</b>.

[0219] MQMan_PeekMsg

[0220] This subroutine returns a pointer to the next message for the specified channel.

[0221] MQMan_RemoveMsg

[0222] This subroutine removes the message from the specified channel's receive queue. If the message pointer itself is not specified, then whatever message is at the head of the specified channel's receive queue is removed.

[0223] MQManFlushRecvQueue

[0224] This subroutine flushes the specified channel's receive queue.

[0225] The CPC <b>302</b> provides the following functionality: a cross platform ANSI (American National Standards Institute) C library; standard types across platforms and compilers; support for standardized compiler features, platforms types, Unicode; a cross platform Hardware Emulation Layer; and release and debug options. The CPC <b>302</b> may be operable in connection with the following hardware platforms (provided by way of non-limiting example): Windows 95/98/ NT 4.0/2000; Windows CE for Dreamcast; Shinobi for Dreamcast; Linux (Red hat 5.1/5.2/6.0/6.1 ); and Playstation 2. It will be obvious to persons skilled in the art, and from the disclosure provided herein, that other hardware platforms are contemplated by and within the scope and spirit of the present invention. Thus, the previously mentioned hardware platforms are merely illustrative, non-limiting examples. Supported hardware platforms may be defined in file such as, for example, C_targets.h.

[0226] Unicode is a standard for representing characters as integers. Unlike ASCII, which uses 8 bits for each character, Unicode uses 16 bits, which means that it can represent more than 65,000 unique characters. This may be unnecessary English-language and Western-European-language programs (i.e., computer games), but it may be necessary for some other languages, such as Greek, Chinese and Japanese. As the software industry becomes increasingly global, Unicode may eventually supplant ASCII as the standard character-coding format. The CPC <b>320</b> may include macros for converting he ASCII to Unicode, and vice versa.

[0227] Thus, while there have been shown and described and pointed out fundamental novel features of the invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the disclosed invention may be made by those skilled in the art without departing from the spirit of the invention. It is the intention, therefore, that the present invention be limited only as indicated by the scope of the claims appended hereto.