System and method for performing remote requests with an on-line service network

Abstract

A remote request system and method monitors and controls the execution of remote requests on an on-line services network. When a remotely located client sends a remote request to the on-line service network, the remote request system monitors the remote request while returning operating control back to the client while the remote request remains pending in the on-line service network. The remote request system also provides for the concurrent execution of multiple pending remote requests, provides status information about each remote request, provides for the cancellation of a pending remote request and optimizes the use of memory. In addition, the remote request system dynamically allocates memory when data blocks of unknown size are transmitted over the on-line services network.

Claims

What is claimed is:

1. A remote request system for creating and monitoring remote requests sent to an interactive, on-line services network, comprising:

at least one client application executing in a end-user computer, said client application containing at least one execution thread, said execution thread capable of generating a plurality of concurrently pending remote requests; and

a client request layer executing in said end-user computer and in communication with said execution thread, said client request layer configured to receive said remote requests and to uniquely label each of said remote requests, said client request layer further configured to monitor said pending remote requests while said execution thread continues execution, wherein said unique label contains a first identifier that identifies a set of remote requests, a second identifier that identifies a remote request function and a third identifier that identifies each instance of said remote request.

2. The remote request system of claim 1 further comprising an object-oriented data structure in communication with said remote request layer, said data structure storing at least one object for each of said pending remote requests.

3. The remote request system of claim 2, wherein said unique label in each of said uniquely labeled remote requests identifies at least one of said objects in said data structure.

4. The remote request system of claim 3 wherein said unique label identifies a remote request interface.

5. The remote request system of claim 4 wherein said second identifier identifies a remote request method.

6. The remote request system of claim 5 wherein said third identifier identifies a remote request instance.

7. The remote request system of claim 1, wherein said remote request system contains a plurality of said end-user computers connected to an on-line network via a wide area network and wherein said remote request layer in each of said end-user computers sends said uniquely labeled remote requests to said on-line network via said wide area network.

8. The remote request system of claim 3 wherein said data structure contains a method object for each instance of said remote request.

9. A machine for monitoring the status of remote procedure calls sent to an interactive, on-line services network, comprising:

at least one client application executing in a computer, said client application capable of sending at least one remote procedure call to an on-line network;

a status data structure resident in said computer, said status data structure containing status information about said remote procedure call, wherein said status information allows said client application to obtain the progress of a data upload or a data download operation with the on-line network;

a remote procedure layer in communication with said client application, said status data structure and a wide area network, said remote procedure layer executing in said computer, said remote procedure layer responsive to said remote procedure calls generated by said client application, wherein said remote procedure layer subdivides said remote procedure call into a plurality of remote messages and sends said remote messages to said on-line network via said wide area network; and

a status routine in communication with said status data structure, said remote procedure layer and said client application, said status routine executing in said computer and responsive to each of said remote messages wherein said status routine obtains status information from said remote messages and updates said status data structure with said status information.

10. The machine of claim 9, wherein said status data structure communicates said status information to said client applications.

11. The machine of claim 10, wherein said client application uses said status information to create a fuel gauge that indicates the progress of a remote procedure call.

12. The machine of claim 11, wherein said remote procedure call uploads data to said on-line network.

13. The machine of claim 10, wherein said remote procedure layer receives a plurality of response messages from said on-line network and wherein said status routine obtains status information from said response messages and updates said status data structure with said status information.

14. The machine of claim 13, wherein said remote procedure call downloads data from said on-line network.

15. A remote request system for creating and monitoring the status of remote requests sent to an interactive, on-line services network, comprising:

at least one client application executing in a computer, said client application capable of sending a plurality of concurrently pending remote requests to an on-line network;

a data structure resident in said computer, said data structure containing a plurality of identifiers that uniquely identify said remote requests, said data structure further containing at least one status data structure linked to said identifiers;

a request layer in communication with said client application sand said on-line network, said request layer executing in said computer, said client applications invoking said request layer to generate said remote requests wherein said request layer uses said identifiers to locate and update said status data structure when said remote requests are sent to said on-line network; and

wherein said plurality of identifiers contain a first identifier that uniquely identifies a remote request interface, a second identifier that identifies a remote request method, and a third identifier that identifies a remote request instance.

16. The remote request system of claim 15, wherein said request layer periodically communicates said status information to said client application.

17. The remote request system of claim 15, wherein said remote requests are remote procedure calls.

18. The remote request system of claim 15, wherein said data structure further contains a plurality of identification objects that contain said plurality of identifiers.

19. The remote request system of claim 18, wherein said data structure further contains a plurality of status objects linked to said plurality of identification objects, said status objects containing at least one of said status data structures.

20. A distributed on-line network for processing remote requests comprising:

a plurality of interconnected servers, said interconnected servers containing at least one service application that executes a plurality of remote requests;

an object-oriented service data structure resident in said on-line service, said service data structure containing a plurality of request objects that uniquely identify each of said remote requests, each of said request objects containing a plurality of identifiers that identify a remote request type and the origin of said remote request;

a service request layer in communication with said service data structure and said service application, wherein said service request layer uses said identifiers in each of said request objects to direct said service application to execute said remote request and wherein said service request layer combines said identifiers with the results of said remote request to create at least one response message,

wherein said plurality of identifiers contain a first identifier that uniquely identifies a remote request interface, a second identifier that identifies a remote request method, and a third identifier that identifies a remote request instance.

21. The distributed on-line network in claim 20 wherein said service request layer uses said identifiers in said response messages to identify the destination of said response messages.

22. In a remote request system, a method for creating and monitoring remote requests sent to an on-line network, comprising:

creating multiple pending remote requests with an end-user computer;

creating a plurality of identifiers that uniquely identify each of said remote requests, said plurality of identifiers containing a first identifier that uniquely identifies a set of remote requests, a second identifier that uniquely identifies a remote request function and a third identifier that uniquely identifies each instance of said remote request;

storing said plurality of identifiers in a data structure;

combining said first, second and third identifiers to create at least one remote message; and

sending said remote message via said wide area network to an on-line network.

23. The method of claim 22 wherein said step of creating a plurality of identifiers further creates a plurality of objects that store said plurality of identifiers.

24. The method as defined in claim 22 further comprising the step of creating a status data structure for each of said plurality of remote requests.

25. The method as defined in claim 24 further comprising the step of updating said status data structure when said remote messages are sent to said on-line network.

26. The method as defined in claim 24 further comprising the step of updating said status data structure when said remote messages are sent to said on-line network.

27. The method as defined in claim 24 further comprising the step of accessing said status data structure to obtain status information about said remote requests.

28. The method as defined in claim 22 further comprising the steps of:

creating a cancel request that cancels at least one of said remote requests, said cancel request containing a cancel command and said identifiers that uniquely identify at least one remote request; and

sending said cancel request to said on-line network.

29. The method as defined in claim 22 further comprising the step of creating a dynamic object in response to a remote request for a data block of unknown size.

30. The method as defined in claim 29 further comprising the step of expanding said dynamic data structure to hold said data block of unknown size in continuous sections of memory when said end-user computer receives said block of unknown size from said on-line service.

31. The method as defined in claim 30 wherein said step of expanding said dynamic data structure comprises subdividing said dynamic data structure into a plurality of data buffers.

32. The method as defined in claim 31 further comprising the step of accessing said data buffers before all of said data block of unknown size is received from said on-line network.

33. The method as defined in claim 32 further comprising the step of deleting at least one of said plurality of data buffers before receiving all of said data block of unknown size from said on-line network.

34. In a computer, a method for monitoring the status of remote procedure calls sent to an interactive, on-line services network, comprising:

creating at least one remote procedure call that is sent to an on-line network;

creating a status data structure for said remote procedure call wherein said status data structure contains status information about said remote procedure call, wherein said status information allows said client application to obtain the progress of a data upload or a data download operation with the on-line network;

subdividing said remote procedure call into a plurality of remote messages;

sending each of said remote messages to said on-line network via a wide area network;

obtaining status information from said remote messages; and

updating said status data structure with said status information.

35. The method of claim 34, wherein said status information comprises the amount of data each of said remote messages sends to said on-line network.

36. The method of claim 35, further comprising the step of accessing said status data structure to obtain the progress of a data upload to said on-line network.

37. The method of claim 36 further comprising the steps of:

receiving a plurality of response messages from said on-line network;

obtaining status information from said response messages; and

updating said status data structure with said status information.

38. The method of claim 37, further comprising the step of accessing said status data structure to obtain the progress of a data download from said on-line network.

39. The method of claim 34, wherein said step of creating a status data structure further comprises the creation of a plurality of identifiers that uniquely identify said remote request and the linking of said status data structure to said plurality of identifiers.

40. The method of claim 39, wherein said step of updating said status data structure comprises the use of said plurality of identifiers contained within said request messages to locate said status data structure.

41. A data stream for sending a plurality of remote messages to an on-line network, said data stream comprising:

a plurality of remote procedure messages, each of said remote procedure messages corresponding to a pending remote request, said remote procedure messages further comprising:

a header, said header containing an interface identifier, a method identifier, and a instance identifier that identifies the instance of said remote request, wherein said interface identifier, said method identifier and said instance identifier uniquely identify one of said pending remote requests; and

a plurality of data packets.

42. The data stream of claim 41 wherein said interface identifier is a one-byte value.

43. The data stream of claim 42 wherein said method identifier is a one-byte value.

44. The data stream of claim 43 wherein said instance identifier is at least a one-byte value.

45. The data stream of claim 41 wherein each of said plurality of data packets includes a type field, a length field and a data field.

46. The data stream of claim 41 wherein said plurality of remote messages for one of said remote requests is interleaved with a plurality of remote messages for another of said remote requests.

47. A remote request system for creating and monitoring remote requests sent to an interactive, on-line services network, comprising:

at least one client application executing in a end-user computer, said client application containing at least one execution thread, said execution thread capable of generating a plurality of concurrently pending remote requests;

a client request layer executing in said end-user computer and in communication with said execution thread, said client request layer configured to receive said remote requests and to uniquely label each of said remote requests, said client request layer further configured to monitor said pending remote requests while said execution thread continues execution; and

an object-oriented data structure in communication with said remote request layer, said data structure storing at least one object for each of said pending remote requests;

wherein said unique label in each of said uniquely labeled remote requests identifies at least one of said objects in said data structure, and said unique label identifies a remote request interface.

48. The remote request system of claim 47, wherein said unique label contains a first identifier that identifies a set of remote requests, a second identifier that identifies a remote request function and a third identifier that identifies each instance of said remote request.

49. The remote request system of claim 47, wherein said second identifier identifies a remote request method.

50. The remote request system of claim 49, wherein said third identifier identifies a remote request instance.

51. The remote request system of claim 47, wherein said data structure contains a method object for each instance of said remote request.

52. The remote request system of claim 47, wherein said remote request system contains a plurality of said end-user computers connected to an on-line network via a wide area network and wherein said remote request layer in each of said end-user computers sends said uniquely labeled remote requests to said on-line network via said wide area network.

53. A remote request system for creating and monitoring remote requests sent to an interactive, on-line services network, comprising:

at least one client application executing in a end-user computer, said client application containing at least one execution thread, said execution thread capable of generating a plurality of concurrently pending remote requests; and

a client request layer executing in said end-user computer and in communication with said execution thread, said client request layer configured to receive said remote requests and to uniquely label each of said remote requests, said client request layer further configured to monitor said pending remote requests while said execution thread continues execution;

an object-oriented data structure in communication with said remote request layer, said data structure storing at least one object for each of said pending remote requests;

wherein said unique label in each of said uniquely labeled remote requests identifies at least one of said objects in said data structure; and wherein said data structure contains a method object for each instance of said remote request.

54. The remote request system of claim 53, wherein said unique label contains a first identifier that identifies a set of remote requests, a second identifier that identifies a remote request function and a third identifier that identifies each instance of said remote request.

55. The remote request system of claim 53, wherein said unique label identifies a remote request interface.

56. The remote request system of claim 55, wherein said second identifier identifies a remote request method.

57. The remote request system of claim 56, wherein said third identifier identifies a remote request instance.

58. The remote request system of claim 53, wherein said remote request system contains a plurality of said end-user computers connected to an on-line network via a wide area network and wherein said remote request layer in each of said end-user computers sends said uniquely labeled remote requests to said on-line network via said wide area network.

Description

BACKGROUND OF THE INVENTION

FIELD OF THE INVENTION

This invention relates to on-line network communication systems and, more particularly, to a system for performing remote requests over a wide area network.

BACKGROUND

A common example of network communications is a plurality of personal computers communicating over a network with a remotely located file server. In such systems, the personal computers are called clients and the file server is called a server. The clients access data on the server by sending requests to the server, which carries out the work and sends back the replies. This model is typically referred to as the client-server model.

In the client-server model, communication takes the form of request-response pairs. Conceptually, the request and the response is similar to a program calling a procedure and getting a result. In such cases, the requester initiates an action and waits until the results are available. Ordinarily, when a program calls a local procedure, the procedure runs on the same machine as the program. With a remote procedure call, however, the remote procedure runs on the remotely located server. In order to standardize remote client-server requests, the computer industry has implemented the Remote Procedure Call (RPC).

In conventional systems, remote procedure calls act as if they execute locally. The programmer developing an application invokes a remote procedure just like local procedure calls. Consequently, an application programmer does not need to write software to transmit computational or Input/Output-related requests across a network, to handle network protocols and to deal with network errors. Remote procedure calls handle such tasks automatically.

Conventional remote procedure calls operate within the network architecture connecting the client with the server. In general, networks are organized as a series of layers or levels as defined by the International Standards Organization (ISO) Open Systems Interconnection (OSI) Reference Model. The OSI reference model contains seven layers which are called the application layer, the presentation, layer, the session layer, the transport layer, the network layer, the data link layer and the physical layer.

In most systems, a library of the remote procedure calls are created and provided to an application programmer. Typically, the remote procedure calls are software routines which the application uses at run time. During the development of an application, the application programmer writes the application software code which contains references to the remote procedure calls. As an application program runs, it invokes a remote procedure call in the dynamic link library and passes a number of parameters to the invoked remote procedure call.

Once invoked, the remote procedure call receives the parameters and marshals them for transmission across the network. Marshaling parameters means ordering them and packaging them in a particular way to suit a network link. In addition, the remote procedure call locates the proper remote computer which executes the remote procedure call, determines the proper transport mechanisms, creates a network message and sends the message to the network transport software. Furthermore, the remote procedure call deals with network errors which may occur and waits for results from the remote server.

When the remote procedure call arrives at the server, the transport layer passes it to the remote procedure calls running on the server. The remote procedure call on the server then unmarshalls the parameters, reconstructs the original procedure call and directs the server to complete the actions requested by the client. After the server has completed its work, the remote procedure call running on the server sends the results back to the client in a similar manner.

While remote procedure calls operate efficiently on fast local area networks, they suffer from several disadvantages when implemented on wide area networks with slow speed communication lines. Local area networks typically transfer data at over ten Megabits per second. A wide area network with slow speed communication lines, on the other hand, typically transfers data over telephone lines via a modem at 28 Kilobits per second or less.

As explained above, conventional remote procedure calls do not return control to the application program until the server has completed a request. Consequently, the client application suspends operations until it receives a response from the server. This may result in substantial delays, for example, when a client application has requested the server to transfer a large block of data. Consequently, unless implemented in a complex multi-threaded manner, the client application waits for a response before the client application executes other remote procedure calls. As a result, the client application wastes processor cycles while waiting for a response from the server.

In many applications, users may request large amounts of data such as audio, multimedia, and large data files. While a remote procedure call allows the transfer of large blocks of data, a conventional remote procedure call fails to provide timely status information about such data transfers. Consequently, the client cannot query the server regarding the status of the requested information. Thus, a system may appear to "hang" when executing a remote procedure call over a wide area network connected by modems to telecommunication lines. Because users typically expect a high degree of user interaction, lack of status information over slower wide area networks means that many users will simply avoid requesting files with large amounts of data.

In addition, to implement remote procedure call systems in multitasking operating systems requires the use of complex multi-threading techniques. A multitasking operating system allows a single personal computer to work on more than one task at one time. For example, a personal computer with a Microsoft Windows operating system can simultaneously run a database program, a word processing program, a spreadsheet, etc.

For example, in a multi-threaded operating system a thread represents one of possibly many subtasks needed to accomplish a job. For example, when a user starts a database application, the operating system initiates a new process for the database application. Now suppose the user requests the generation of a payroll report from the database application. While this request is pending, the user enters another database request such as a request for an accounts receivable report. The operating system treats each request--the payroll report and the accounts receivable report--as separate threads within the database process.

Because conventional operating systems schedule threads for independent execution, both the payroll report and the accounts receivable report can proceed at the same time (concurrently). Accordingly, it is possible to generate multiple pending remote procedure calls by creating an execution thread for each remote procedure call. However, the implementation of a multi-threaded remote procedure call system is very complex and requires a high level of expertise about the operational details of the operating system.

Another deficiency of current remote procedure calls is that they do not allow an efficient cancellation of a pending request sent to a server. In many wide area network applications, a user may wish to download a large block of data and later wish to cancel the request. Over a wide area network, such transfers of large data blocks take a significant amount of time. Current remote procedure calls, however, do not allow the cancellation of pending remote procedure calls. As a result, current remote procedure calls can waste system resources on unwanted requests.

In addition, conventional remote procedure calls typically require the client to allocate enough memory space to hold an entire data block before requesting data from the server. In many multimedia applications, however, the client does not know the size of a data block before it requests the data block from the server. Therefore, in conventional systems, the client typically issues two requests prior to receiving a data block from the server. The first request directs the server to send the size of the data block. The client then uses the data block size to allocate enough memory to hold the data block. The second request then directs the server to download the data block. Two requests, however, increase response times and increase network communication traffic.

Finally, in many instances, a client can immediately begin using incremental data blocks before receiving the entire data block from the server. For example, in some multimedia applications, a client can begin to display incremental data blocks of an image before receiving the entire image. In current remote procedure call systems, however, the client waits until receiving the entire image before attempting to display the image. This leads to delays in using data. Furthermore, since current remote procedure call systems do not allow the use of incremental data blocks, these systems also waste computer memory since the memory cannot be freed for other uses until an entire block of data is received from the server.

SUMMARY OF THE INVENTION

The disadvantages outlined above are overcome by the method and apparatus of the present invention. The present invention provides an enhanced remote request system which optimizes communications over a Wide Area Network. When a remotely located client sends a remote request to a server, the unique remote request system of the present invention creates an internal data structure and returns operating control to the client before completion of the remote request by the server.

Returning operating control to the client before receiving a response from the server, allows the client to perform other tasks while waiting for the response. Thus, when the client requests large amounts data, such as audio, multimedia, and large data files, the client can continue to execute other instructions while waiting for the requested data or results.

Another feature of the present invention provides an internal data structure which allows the client to concurrently execute multiple remote requests within the same thread of execution. Thus, the present invention allows a single thread to issue multiple remote requests without having to determine the status of other requests previously sent to the server. Unlike conventional remote procedure calls which require complex multi-threading techniques to execute more than one remote procedure call at a time, the present remote request system monitors multiple pending requests in a single execution thread and routes a response to the appropriate pending request.

Another feature of the present invention provides a status data structure which monitors the state of each remote procedure request sent to the server. Whenever the client sends or receives data, the present invention updates the status data structure. To obtain current status information, a client application program queries the status data structure. In the preferred embodiment, the status data structure contains information about data sent to the server and data received from the server.

A still further feature of the present invention provides an identification scheme which uniquely identifies each pending remote request. To cancel a pending remote request, the client sends a message to the server which identifies the pending remote request and directs the server to cancel the pending remote request.

Another feature of the present invention provides a dynamic data structure which expands to receive data blocks of unknown size. With the dynamic data structures of the present invention, the client can request a data block of unknown size and allocate memory when the client receives the requested data block.

Furthermore, the present invention optimizes the efficient use of memory by subdividing a large data block into incremental data blocks. The present invention then sends the incremental blocks over the wide area network. As the client receives each incremental data block, the client immediately begins to use the incremental data blocks. Furthermore, as the client uses each incremental data block the client frees the memory for other uses thus optimizing memory usage.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects, advantages, and novel features of the invention will become apparent upon reading the following detailed description and upon reference to accompanying drawings in which:

FIG. 1 is a high level drawing illustrating the architecture of an on-line services network in accordance with one embodiment of the invention;

FIG. 2 illustrates a simplified block diagram of a client microcomputer communicating with the host data center in accordance with one embodiment of the present invention;

FIG. 3 illustrates the primary software and hardware communications components of one presently preferred embodiment of on-line network of the present invention;

FIG. 4A is a block diagram illustrating a preferred embodiment of the client data structure used in the present invention;

FIG. 4B is a table illustrating an exported interface list in a preferred embodiment of the present invention;

FIG. 5 is a detailed block diagram illustrating a client data structure used with multiple pending remote requests in the preferred embodiment of the present invention;

FIG. 6 is a block diagram illustrating a preferred embodiment of the server data structure used in the present invention;

FIG. 7 is a detailed block diagram illustrating a server data structure used with multiple pending remote requests in the preferred embodiment of the present invention;

FIGS. 8A, 8B, 8C illustrate the message format for remote messages sent between the client microcomputer and the host data center;

FIG. 9 is a block diagram illustrating the routines used to send and receive remote requests;

FIG. 10 is a flow chart illustrating the overall functional operation in the preferred embodiment that generates and sends a remote request;

FIG. 11 is a flow chart illustrating one embodiment of the routine invoked to initialize the client data structure;

FIG. 12 is a flow chart illustrating one embodiment of the routine invoked to establish a connection with a particular service executing on the servers;

FIG. 13A is a flow chart illustrating one embodiment of the routine invoked to create a method object;

FIG. 13B is a flow chart illustrating one embodiment of the routine invoked to add parameters to a remote message;

FIG. 14 is a flow chart illustrating one embodiment of the routine invoked to create a status data structure before sending a remote request to the servers;

FIGS. 15, 15A and 15B are flow charts illustrating one embodiment of the routines invoked to receive a remote request, process the remote request and send a response from the service applications back to the client applications;

FIG. 16 is a flow chart illustrating one embodiment of the routine invoked to receive a response from the service applications;

FIG. 17 is a flow chart illustrating one embodiment of the routine invoked to cancel a pending remote request;

FIG. 18 is a block diagram showing data buffers stored in contiguous sections of memory;

FIG. 19 is a block diagram showing buffer objects which reference incremental portions of a response;

FIG. 20 illustrates the two component layers of a control protocol;

FIGS. 21A and 21B illustrate a packet format used for data communications between client microcomputers and Gateway microcomputers over a wide area network; and

FIG. 22 illustrates a multiplexing technique for combining multiple client-server message streams within packets transmitted over the wide area network.

In the drawings, the first digit of any three-digit number indicates the number of the figure in which the element first appears. For example, an element with the reference number 402 first appears in FIG. 4. Where four-digit reference numbers are used, the first two digits indicate the figure number.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The detailed description which follows is broken up into the following three sections: ARCHITECTURAL OVERVIEW, THE MICROSOFT NETWORK PROCEDURE CALL LAYER and THE MICROSOFT NETWORK CONNECTION PROTOCOL.

1. Architectural Overview

FIG. 1 is a high level drawing illustrating the architecture of an on-line services network 100 in accordance with one embodiment of the invention. The on-line services network 100 includes multiple client processors 102 connected to a host data center 104 by one or more wide area networks (WANs) 106. The wide area network 106 of the preferred embodiment includes wide area network (WAN) lines 108 which are provided by one or more telecommunications providers. The wide area network 106 allows client users (i.e., users of the client processors 102) dispersed over a wide geographic area to access the host data center 104 via a modem. The WAN lines 108 preferably include both X.25 lines, ISDN (Integrated Service Digital Network) lines, the Frame Relay interface, or the Transport Control Protocol/Interface Program (TCP/IP) which is a suite of protocols developed for use on the Internet.

The X.25 lines 108 comply with CCITT X.25 specifications which define the protocols for a packet-switched wide area network 106. The letters of the CCITT acronym stand for the Comite Consultatif Internaionale de Telegraphie et Telephonie, an organization based in Genevia, Switzerland. The CCITT recommends use of communications standards that are recognized throughout the world. The X.25 standard documents the interface required to connect a computer to a packet-switched network.

The host data center 104 comprises a plurality of servers 120 connected to a high speed local area network (LAN) 122. Also connected to the local area network 122 are multiple Gateways 124 linking incoming calls from end users to the servers 120. In the preferred embodiment, the servers 120 and the Gateways 124 are Pentium-class (or better) microcomputers which run the Windows NT operating system available from Microsoft Corporation.

The servers 120 typically have at least 128 MB of random-access memory (RAM) and at least 4 GB of disk space. Processing power may vary from server to server. For example, one server 120 may have four 100 Mhz processors, while another server 120 may have one 90 Mhz processor. Each Gateway 124 typically has at least 64 MB of RAM and at least 2 GB of disk space, and is capable of supporting approximately 1000 simultaneous users at T1 (1.544 Mbps) or greater data rates. The local area network 122 is preferably a 100 Mbps LAN based on the CDDI (Copper Distributed Data Interface) standard. The CDDI specification is a variant of the well-known ANSI Fiber Distributed Data Interface specification, but uses a single copper ring instead of a dual fiber ring.

The host data center 104 provides a variety of communications-based and information-based on-line services to client users. Typical services include, for example, a mail service for allowing users to send electronic mail messages to one another, a bulletin board system (BBS) service for allowing users to post and review bulletins on specific topics, a chat service for allowing users to communicate in real time with one another on specific topics, a mediaview service for allowing users to view on-line multimedia titles, an interactive games service for allowing users to compete against one another in real time in on-line interactive games, various news services for allowing users to access news and magazine articles, and a Network Shell for allowing users to view a hierarchy of services and data entities on the network.

The host data center 104 also includes multiple Arbiter microcomputers 126 (hereinafter referred to as "Arbiters") that monitor, record and process certain types of transactions to ensure consistency among servers 120. The host data center 104 also includes one or more custom Gateway microcomputers 130 which link the host data center 104 to one or more external service providers 132, such as a news provider, a stock quote service or a credit card service which validates and executes credit card transactions. Each custom Gateway microcomputer 130 uses the communications protocol required by the external service provider 132 to which the custom Gateway is linked.

The services offered by the on-line services network 100 are in the form of client-server application programs. Each client-server application includes a client portion and a server portion. To facilitate the description that follows, the following terminology and conventions are used. The term "client user" is used to refer to a client processor 102 under the control of an end user. An application executing on a client is called a "client application" and a service running on one or more servers 120 is called a "service application." Names of specific client applications and on-line services are written in capital letters (for example, CHAT or MAIL).

The client applications run on the client processor 102 and the server applications run on the servers 120. In the preferred embodiment, service applications are preferably Windows NT executables running on one or more servers 120. The client applications, on the other hand, are in the form of Windows '95 executables.

During a typical logon session, a client user maintains a communications link with a single Gateway 124, but may access multiple service applications (and thus communicate with multiple servers 120). Accordingly, the Gateway 124 performs protocol translation, translating messages between the protocol of the wide area network 106 and the protocol of the local area network 122 and establishes links between a client processor 102 and a particular server 120.

To initially access a service, the client user initiates a "service session." Each time the user initiates a new service session, the Gateway 124 handling the logon procedure establishes a communications channel via the local area network 122 with the selected server 120. These service sessions may execute concurrently in the same client thread executing on the client processor 102. The Gateway 124 establishes a service instance channel by accessing a service map 134 to select a server 120 which is allocated to the particular service. This service instance channel remains throughout the service session, and passes messages between the Gateway 124 and the server 120 as the client and service applications interact.

In a preferred embodiment, the servers 120 are arranged into service groups, with each service group corresponding to a particular service. Each server 120 of a service group is preferably a "replicated" version of the other servers 120 within the service group, meaning that each runs the same service application as the other servers 120 to implement a common service. For example, the servers 120 within a bulletin board system ("BBS") service group all run a BBS service application.

The service map 134 contains information about the state of every service executing on the servers 120, and the unique identifiers of the servers 120. The service map 134 is preferably generated by a service map dispatcher 136, which may be implemented as a single microcomputer. To generate the service map 134, the service map dispatcher 136 periodically polls the servers 120, prompting the servers to transmit their respective local maps 138 to the service map dispatcher 136. Each local map 138 is generated by the corresponding server 120, and contains the unique identifier of the server and other information about loading and processor type. The service map dispatcher 136 builds the service map 134 from all of the local maps 138 it receives, and then broadcasts the service map 134 to all of the Gateways 124 over the local area network 122.

In addition to generating a service map 134, the service map dispatcher 136 maintains a central repository of information referred to as the "global registry" 135. The global registry 145 contains various information about the present configuration of the host data center 104. For example, for each service group, the global registry 135 indicates the identification codes of the servers 120 of the service group, and the identity of the Arbiter microcomputer 126 (if any) which is assigned to the service group. In other embodiments, the global registry 135 could be maintained by some entity other than the service map dispatcher 136.

In the preferred embodiment, the service map dispatcher 136 broadcasts a new service map 134 every 30 seconds. Each time the service map dispatcher 136 broadcasts a new service map 134, every Gateway 124 receives and locally stores a copy of the new service map 134. The Arbiters 126 also receive and store copies of the service map 134, and use the service map 134 to identify the servers 120 which are currently assigned to service groups.

Referring to FIG. 2, a block diagram of two of client applications 200a communicating with the service applications 200b is shown. The client applications 200a execute on the client processor 102 and the service applications 200b execute on the servers 120. The client applications 200a communicate with the service applications 200b normally in the form of remote requests (i.e., a request which directs a service application 200b running on the server 120 to perform particular actions).

In the present invention, remote requests are managed by a request layer. In the preferred embodiment, the request layer 206 is called the Microsoft Network Procedure Call and is referred to herein as the "MPC layer 206." The MPC layer 206 also includes a client application programming interface ("the client MPC layer 206a"), and a service application programming interface ("the service MPC layer 206b and 206c") for interfacing with client and service applications. The client MPC layer 206a and the service MPC layers 206b and 206c contain a variety of routines which allow the client and service applications to communicate with each other.

The client MPC layer 206a application programming interface resides in a dynamic link library. The dynamic link library contains the set of routines which each application program uses to request and carry out remote requests. For example, as discussed in more detail below, during development of a client application 200a, a programmer writes software that calls or invokes the routines in the client MPC layer 206a. During execution of the program, the application retrieves the desired routine from the client MPC layer 206a dynamic link library and executes the routine like any other software routine. The dynamic link libraries reduce storage space requirements because the dynamic link libraries allow each of the client applications 200a to share the routines in the client MPC layer 206a. The service MPC layer 206b exists in each Gateway 124 and the service MPC layer 206c exists on the servers 120. In the preferred embodiment, the service MPC layer 206b existing in each Gateway 124 and the service MPC layer 206c existing in the servers 120 are identical.

Underneath the MPC layers 206a, 206b and 206c is a transport layer. In the preferred embodiment, the transport layer is called the Microsoft Network Connection Protocol or "MCP layer" and for convenience will be referred to as the MCP layer throughout the application. The MCP layer 210 also includes a client API ("the client MCP 210a") which runs on the client processors 102 and a server API ("the Gateway MCP 210b and the server MPC 210c") which runs on the Gateways 124 and the servers 120. The MCP layer 210 manages client-Gateway-Server communications that support simultaneous service sessions, allowing a client user to access multiple services simultaneously.

The Gateway MCP layer 210b then multiplexes and packetizes the messages and sends the messages over the local area network 122 to the server MCP layer 210c in the servers 120. The server MCP layer 210c in the servers 120, reformats the messages into function calls and passes the function calls to the service MPC layer 206c. As discussed in more detail below, the service MPC layer 206c then directs the service applications 200b such as the CHAT service 202b and the WEATHER service 204b to execute the function calls and send responses back to the client applications 200a.

When sending a response back to the client applications 200a, the service MPC layer 206c formats responses from the CHAT service 202b and the WEATHER service 204b into messages. The service MPC layer 206c then passes the messages to the server MCP layer 210c in that server 120. The server MCP layer 210c multiplexes (and packetizes) the messages and sends the multiplexed data over the local area network 122 to the Gateway MCP layer 210b. The Gateway MCP layer 210b then sends the multiplexed data over the wide area network 106 to the client MCP layer 210a in the client processor 102.

Focusing now on the client processor 102, when receiving a message, the client MCP layer 210a running on the client demultiplexes the messages received via the wide area network 106 and routes the messages to the client MPC layer 206a. The client MPC layer 206a then sets an event which signals the client application 200a that data has been received from the on-line network 104.

FIG. 3 illustrates a more detailed block diagram of the basic communications components for a preferred embodiment of the on-line services network 100. Assuming the client user accesses the on-line services network 100 by a modem 300, the client MCP layer 210a communicates with a modem engine layer 302, which in-turn communicates with the modem 300. In client microcomputers 102 which do not use a modem, the modem engine layer 302 is replaced with a transport engine layer. The modem 300 communicates over a telephone line 304 with a carrier-provided PAD (packet assembler disassembler) 306, which translates data between a standard modem format and the WAN format (which is X.25 in the FIG. 3 example). At the Gateway 124, an X.25 network card 310 sends and receives data over an X.25 line 108, and communicates with an X.25-specific network layer 312.

The Gateway MCP layer 210b receives the data from the X.25 network card 310, formats the messages and forwards the messages to the service MCP layer 210c. The Gateway 124 also includes a locator program 314 which performs the function of (1) selecting servers 120 for handling requests to open connections with services, and (2) routing the open connection requests so as to distribute processing loads within service groups. (As indicated above, a client-user will typically generate a number of open connection requests throughout a logon session, since the user will typically access multiple services. Additional service requests will normally be generated by the client-user throughout the course of each service session.)

The locator program 314 accesses a locally-stored copy of the service map 134 whenever a request to open a connection is received from a client processor 102. Each time the locator program 314 selects a server 120 to handle a service request, the locator program 314 records various information about the newly created service session (including the selected server's unique identifier) within a service map 134.

The service MPC layer 206c communicates with the server MCP layer 210c. The server MCP layer 210c performs various transport-layer-type functions, such as packetization of message data for transmission over the local area network 122, and multiplexing of message data for transmission over TCP/IP links of the local area network 122. The MCP layers 210b and 210c communicate with Copper Distributed Data Interface local area network layers 322a and 322b, which in-turn communicate with Copper Distributed Data Interface network cards 324a and 324b.

It will be recognized that although the implementation depicted by FIG. 3 uses specific communications protocols various alternative protocols, request layers and transport layers could be used. The MPC layers 206a, 206b and 206c are further described below under the heading THE MPC LAYER while the MCP layers 210a and 210b are further described below under the heading THE MCP LAYER.

2. The Microsoft Network Procedure Call Layer

Client applications 200a make use of a high-level client MPC layer 206a via an application programming interface (API) which is optimized to permit efficient client-server communications over relatively slow/high latency wide area networks 106. In the preferred embodiment, the client contains the client MPC layer 206a while the Gateways 124 and the service applications contain the service MPC layers 206c.

The MPC layers 206a, 206b and 206c are similar to the session layer defined by the International Standards Organization (ISO) Open Systems Interconnection (OSI) Reference Model. The MPC layers 206a, 206b and 206c contain routines which allow the client applications 200a and service applications 200b to send and receive function calls.

In the preferred embodiment, when a programmer develops the client application 200a, the programmer adds software that communicates with the client MPC layer 206a. Furthermore, when a programmer develops the service application 200b, the programmer adds software that communicates with the service MPC layer 206c. For example, to develop the client application 200a, the programmer inserts code that "calls" or invokes the routines in the client MPC layer 206a. The routines in the client MPC layer 206a then execute the necessary instructions to create a remote request and to send the remote request to the other layers in the on-line services network 100. Consequently, the programmer does not need to know the details about the operation of other layers in the on-line services network 100.

In the preferred embodiment, the MPC layers 206a, 206b and 206c do much more than send remote messages to each other. The MPC layers 206a and 206c create internal data structures for monitoring pending remote requests. In addition, the MPC layers 206a and 206c create remote request identifiers which uniquely identify each remote request. The MPC layers 206a and 206c use the identifiers to properly route the remote requests to their proper destinations. As described in more detail below, the MPC layers 206a, 206b and 206c, in the present invention, are compatible with the Object Linking and Embedding (OLE) 2.0 architecture defined by Microsoft Corporation. The Object Linking and Embedding (OLE) 2.0 architecture routine is well known in the art, and is described in OLE 2 Programmer's Reference Vol. I, Microsoft Press, 1993, and in OLE 2 Programmer's Reference Vol. II, Microsoft Press, 1993. Also, while the following description describes the MPC layers 206a, 206b and 206c in object-oriented terminology, a person of ordinary skill in the art will appreciate that other programming techniques can be used to implement the MPC layers 206a, 206b and 206c without using an object-oriented programming language.

Focusing now on the client MPC layer 206a, FIGS. 4A and 5 show the unique client data structure created by the client MPC layer 206a in the present invention. The client MPC layer 206a creates the client data structure 208a to monitor each remote request sent to the host data center 104. The client data structure 208a, in the preferred embodiment, is a binary tree.

The first layer of the client data structure 208a identifies the on-line services network 100 with a Main MOS object 400 (the MOS acronym stands for the Microsoft On-line Service). The Main MOS object 400 has assigned to it an Object Linking and Embedding (OLE) Main MOS identifier 402 which uniquely identifies the Main MOS object 400 from other Object Linking and Embedding (OLE) objects. In the preferred embodiment, the Main MOS identifier 402 is a 16 byte number which is assigned by the Microsoft Corporation.

The second layer in FIG. 4A, contains a service proxy object 404 which stores information about a particular service existing on the on-line services network 100. For example, a service proxy object 404 for the CHAT service contains information about the CHAT service 202b. The service information stored in the service proxy object 404 includes a service identifier 406 and an exported interface list 408. In the presently preferred embodiment, the Main MOS object 400 can point to many service proxy objects 404. The number of service proxy objects 404 is only limited by the storage capabilities of the local processor 102.

As discussed in more detail below, each service proxy object 404 is created when a client user invokes a particular client application 200a such as the client CHAT application 202a or the client WEATHER application 204a, etc. The service identifier 406 is predefined by the on-line network provider.

In the preferred embodiment, a remote request is submitted to the service applications by calling a function also known as a method that exists in the service MPC layer 206c. The list of service requests for the CHAT service 202b, for example, might contain methods for posting comments, methods for reading comments and so on. All of the methods for a client and service application 200a and 200b are organized into interfaces.

Interfaces organize methods into groups. Thus, each interface is a group of methods. In the preferred embodiment, each interface contains a group of up to 256 methods. Because an application may have more than one interface, the interfaces are further organized into an exported interface list 408. As shown in FIG. 4A, the exported interface list 408 in the preferred embodiment contains up to 220 interfaces. Thus, in the present invention, each service application 200b offers up to a maximum of 66,320 methods (220 interfaces.times.256 methods=62,500 methods). The different interfaces and the methods within each interface are implemented by the service application software developer.

As explained in more detail below, the exported interface list 408 is downloaded or exported to the client MPC layer 206a after connection with the service MPC layer 206c is established. As shown in FIG. 4B, the exported interface list 408 is a two-column table with multiple rows. Each row corresponds to one of the interfaces in the service application 202. The first column contains a 16-byte OLE interface identifier for each interface in the service application 202. The second column contains a list of corresponding one-byte service interface identifiers 412. The present invention uses the exported interface list 408 to convert OLE 16-byte interface identifiers into their corresponding one-byte service interface identifiers 412.

Referring now to FIG. 4A, the next level of the client data structure 208a contains an interface object 410 which is instantiated when the client application 200a has successfully established a connection with the service application 200b. The interface object 410 contains a service interface identifier 412 and a method instance counter 414. In the presently preferred embodiment, each service proxy object 404 can point to as many interface objects 410 as have been exported by the service application 200b.

The service interface identifier 412 identifies a particular interface in the exported interface list 408. As shown in FIG. 4B, the exported interface list 408 numerically lists each interface, thus the first interface is identified with the number one, the next interface is identified with the number two, and so on. The single-byte service interface identifier 412 references up to 220 interfaces in the exported interface list 408. Thus, the service interface identifier 412 identifies the interface containing a particular method. For example, if the "post comment" method in the CHAT client application 202a exists in the first exported interface, the interface identifier is set to one.

In one embodiment of the present invention, the interface objects for each service are identified with 16-byte Object Linking and Embedding (OLE) interface identifiers. During development of an application program, a programmer assigns the 16-byte Object Linking and Embedding identification codes which correspond to the service interface identifiers 412. The preferred embodiment of the present invention, reduces the 16-byte Object Linking and Embedding (OLE) interface identifier into a single byte based on the corresponding single-byte service interface identifiers 412 in the exported interface list 408. Thus, in the preferred embodiment, the service interface identifier 412 is a single-byte number which ranges from one to 220.

The interface object 410 also stores the method instance counter 414. In the present invention, an application can invoke identical, concurrently pending methods. This is best illustrated by an example, if a user desires to post two different comments on the CHAT service 202b. The client MPC layer 206a uses the same "post comment" request twice, but combines each "post comment" request with different comment data. The first "post comment" request is called the first instance, while the second "post comment" request is called the second instance. A method instance counter, therefore, counts the number of times the client MPC layer 206a has used a method within an interface.

In the preferred embodiment, the value of the incremented method instance counter 414 is stored as a method instance identifier 420 in the method object 416. Each method instance identifier 420 is represented as a four byte number. As discussed in more detail below, the method instance identifier 420 is sent to the service MPC layer 206c as a variable length value. In the preferred embodiment, the first two bits of the method instance identifier 420 indicate whether the method instance identifier 420 should be transmitted as a one, two, three or four byte number.

For example, the first time the client CHAT application 202a requests a "post comment" method, the method instance counter 414 is incremented to one and the value of the method instance counter 414 is stored as the method instance identifier 420. Since the value of the method instance counter is one, the first two bits of the instance identifier are set to zero. Thus, when the instance identifier is transmitted to the service MPC layer 206c, the instance identifier is sent as a single byte value.

The next level of the client data structure 208a contains a method object 416. Each method object 416 corresponds to a particular remote request. In the preferred embodiment, each interface object 410 can point to many method objects 416 as memory will permit. As discussed in more detail below, when a client application 200a sends a remote request to the service application 200b, the client MPC layer 206a instantiates a method object 416 which corresponds to the remote request. For example, when the client CHAT application 202a generates a "post comment" remote request, the client MPC layer 206a instantiates a method object 416 which represents a "post comment" request.

In the preferred embodiment, when the client MPC layer 206a instantiates the method object 416. The client MPC layer 206a creates a method identifier 418, and the parameters 424 associated with the method object 416. The present invention uses the service interface identifier 412, the method identifier 418 and the method instance identifier 420 to uniquely identify each remote request.

The parameters 424 contain data related to the remote request or indicate that parameters are expected to be returned from a service application 200b. As explained in more detail below, when all of the parameters 424 have been added to the method object 416, the client application 200a can direct the client MPC layer 206a to issue the request to the service MPC layer 206c.

The method identifier 418 is a single-byte number. Like the interfaces, each method is numbered based on the location of the method in an interface. The initial method is identified with the number zero, the next method is identified with the number one and so on. Thus the single-byte method identifier 418 ranges from zero to 255.

If the client MPC layer 206a were to embed Object Linking and Embedding (OLE) interface identifiers in the messages sent to the service MPC layer 206c, the present invention would need up to 21 bytes of information to identify each remote request including 16 bytes to identify the interface, one byte to identify the method and four bytes to identify the method instance. The preferred embodiment, in contrast, typically uses three bytes (at most six bytes) to identify a particular remote request, one byte for the service interface identifier 412, one byte for the method identifier 418 and typically one byte for the method instance identifier 420. As explained above, the method instance identifier 420 is typically a one byte value, but can expand up to a four byte value. Thus, the single-byte service interface identifier 412, the single-byte method identifier 418 and the variable sized method instance identifier 420 significantly reduce the amount of data which uniquely identifies each remote request. In addition, the identifiers allow the present invention to monitor and track the requests sent to the service applications 200b.

The next layer of the client data structure 208a contains a status object 426 and an optional dynamic object 430. In the presently preferred embodiment, a method object 416 points to only one status object 426. The status object 426 points to its corresponding method object 416 and contains status data 428. The status data 428 holds remote request information. In the preferred embodiment, the status data 428 stores the amount of data sent to the service application 200b and the amount of data received from the service application 200b.

Associated with the status object 426 is an optional dynamic object 430. In the presently preferred embodiment, a status object 426 points to only one dynamic object 430. The dynamic object 430 points to its corresponding status object and is used to receive dynamic data. As discussed in more detail below, the dynamic object 430 contains the reserved data block size 432, the committed data block size 436 and a pointer to a linked list of data buffers 434.

The present invention reserves and commits memory when needed. The client MPC layer 206a reserves memory by notifying the operating system that the client MPC layer 206a needs a block of memory. Reserving memory is a fast and efficient operation because the operating system reserves the block of virtual memory addresses in its virtual memory map. Committing memory is the process of actually storing the data in the reserved block of memory. When committing memory, the operating system allocates a physical memory space for the virtual memory addresses and stores the data in the committed physical memory space. As discussed in more detail below, the dynamic object 430 stores the amount of reserved memory in the reserved data block size 432. The dynamic object stores the amount of the committed memory in the committed data block size 436.

As shown in FIG. 5, the client data structure 208a can contain many service proxy objects 404, interface objects 410, method objects 416, status objects 426 and dynamic objects 430. The Main MOS object 400 contains a list of pointers to the service proxy objects 404. The service proxy objects 404 contain a list of pointers to the interface objects 410. The interface objects contain a list of pointers to the method objects 416. Each method object 416 contains a pointer to a status object 426 and the status object 426 contains a pointer to the dynamic objects 430.

Referring now to FIG. 6, the service data structure 208b of the preferred embodiment is shown. The server data structure contains the main server object 608, the exported interface objects 610, a connection object 600, request objects 602, a request queue 604 and service threads 606. The main server object 608 contains pointers to the exported interface objects 610 and the connection object 600. The exported interface objects 610 contain implementations of the remote request methods.

The connection object 600 is instantiated when the client MPC layer 206a opens a connection to a service application 200b. A connection is a communications channel that a client uses to issue remote requests and to pass information to a particular service application 200b executing on the servers 120. The connection object 600 connects two processes (the client MPC layer 206a with the service MPC layer 206c) so that the output of one can be used as the input to the other.

As illustrated in FIG. 7, the main server object 608 contains the exported interface list 408 and pointers to the exported interface objects 610. The exported interface objects 610 contain the implementation of the remote request methods. The connection object 600 contains the connection information 700 and user identification information 702.

The connection information 700 contains data identifying the particular connection with the client MPC layer 206a. The user identification information 702 contains information about the particular client user. In the preferred embodiment, multiple connection objects 600 can exist. Each connection object 600 represents a different client process that communicates with the service MPC layer 206c.

As explained in more detail below, when a remote request message is received by the service MPC layer 206c, the service MPC layer instantiates the request object 602. The service MPC layer parses the remote request message and stores the values of the service interface identifier 412, the method instance identifier 420, the method identifier 418, the parameters 424 in the request object 602. Furthermore, the request object 602 is added to the request queue 604. The request queue 604 is a linked list of request objects 602. When a service thread 606 is ready for another request, the service thread 606 retrieves the next request from the request queue 604.

This unique implementation greatly improves remote request processing. Unlike conventional systems, the present invention does not attempt to start a new service thread 606 each time a request is received. Further, the present invention does not reject a request if all of the service threads 606 are unavailable. Instead, the present invention uses only a few service threads 606 (typically less than ten) to efficiently service many thousands of requests.

Referring now to FIGS. 8A, 8B and 8C remote request messages 800a and 800b are shown. The MPC layers 206a, 206b and 206c communicate by sending the messages 800a and 800b. As shown in FIG. 8A, each message 800a comprises a header 802 and multiple parameters 804. In the preferred embodiment, each message 800a contains one header 802 and up to 16 parameters 804.

In order to properly route the messages 800a, the MPC layers 206a and 206c use the header 802 to identify the remote request associated with the message 800a. As illustrated in FIG. 8B, the header 802 contains the service interface identifier 412, the method identifier 418 and the method instance identifier 420. The MPC layers 206a and 206c build the message header 802 by retrieving the service interface identifier 412, the method identifier 418 and the method instance identifier 420 from the method object 416.

As explained above, the service interface identifier 412 and the method identifier 418 are single-byte numbers. The method instance identifier 420 ranges from one to four bytes. After creating the header 802, the client MPC layer 206a attaches up to 16 parameters 804 to the header 802. Each pharameter 804 contains a type field 806, an optional length of memory block field 808 and a data field 810.

                  TABLE 1
    ______________________________________
    TYPE FIELD VALUES
                 DEFINED MEANING
    ______________________________________
    0 .times. 01h
                 Byte Parameter Sent From Client To Server
    0 .times. 02h
                 Word Parameter Sent From Client To Server
    0 .times. 03h
                 Double Word Parameter Sent From Client To
                 Server
    0 .times. 04h
                 Data Blocks Less Than 400 Bytes Sent From
                 Client To Server
    0 .times. 05h
                 Data Blocks Greater Than 400 Bytes Sent From
                 the Client To Server
    0 .times. 0Fh
                 Client To Server Cancellation Message
    0 .times. 81h
                 Byte Parameter Sent From Server To Client
    0 .times. 82h
                 Word Parameter Sent From Server To Client
    0 .times. 83h
                 Double Word Parameter Sent From Server To
                 Client
    0 .times. 84h
                 Data Block Sent From Server To Client
    0 .times. 85h
                 Dynamic Data Sent From Server To Client
    0 .times. 86h
                 End of Dynamic Data Sent From Server To
                 Client
    0 .times. 87h
                 Last Parameter Sent From Server To Client
    0 .times. 89h
                 Server To Client Error Message
    ______________________________________

                  TABLE 2
    ______________________________________
                                  Length of
    Service
           Method  Method         Memory
    Interface
           Identi- Instance Type  Block  Data  Type
    Identifier
           fier    Identifier
                            Field Field  Field Field
    ______________________________________
    0 .times. 01h
           0 .times. 04h
                   0 .times. 01h
                            0 .times. 04h
                                  0 .times. 000Ch
                                         weather
                                               0 .times. 85h
                                         map 17
    ______________________________________