WO1999022301A1

WO1999022301A1 - Communications system with modular devices

Info

Publication number: WO1999022301A1
Application number: PCT/US1998/022598
Authority: WO
Inventors: James Bentley; Kenneth J. Klingenstein; Michael F. Braitberg; Charles W. Spaur
Original assignee: Cellport Labs, Inc.
Priority date: 1997-10-24
Filing date: 1998-10-23
Publication date: 1999-05-06
Also published as: AU1276699A

Abstract

Apparatus and method for communication between an external system (104) and a communications apparatus (112), preferably embedded in a vehicle and including a modular base system (124) comprising a number of network devices (132) and a network management module (130). The network devices (132) include network modules (134) and network resources (138). Each network module (134) includes a number of subsystems that provide communications-related functions (188) and one or more of them is part of different network layers. The network modules (134) are able to communicate with each other using a common interface (142) under the management of the network management module (130). The network resources (138) include first in first out buffers, circular buffers and no copy buffers. The base modular system (124) communicates with an applications module (116) and physical devices (120) located in the vehicle. After network module registration with the network management module (130), communications can be made utilizing the modular base system (124) between the applications module (116) and the physical devices (120).

Description

COMMUNICATIONS SYSTEM WITH MODULAR DEVICES

FIELD OF THE INVENTION The present invention relates to system and method for communicating between an application program and a device through multiple communication layers and, in particular, for communicating using one or more selected network modules at the different communication layers of the modular system.

BACKGROUND OF THE INVENTION Application programs are commonly involved with the transfers of information including data from/to a variety of devices including physical devices. Such information is typically used by the application program in conjunction with its processing-related functions. The transfers of information can involve a number of different network layers or levels. These network levels might include device drivers, device protocol drivers, routing protocols, transfer control protocols, sockets and other network links. It is commonplace to establish a communication path or channel using a particular defined set of network levels when transferring information between an application program and a device. That is, for a particular application and device, a single communication path or channel involving defined network levels is provided to handle desired information transfers. By way of example, for an Internet communication, network levels comprising an Ethernet device driver, an Ethernet protocol driver, TCP/IP (transmission control protocol/Internet protocol) and a socket interface can be operatively linked together.

In a pending patent application assigned to the same assignee as the present invention, a portable mobile communications system is described that includes a communications apparatus that can be embedded in a vehicle for controlling information transfers between physical devices, including a CAN (controller area network) bus and a wireless device. The communications apparatus enables users that are located remote from the communications apparatus to communicate with the embedded system using a standardized network, such as the Internet. The system is able to execute application programs and, where necessary or appropriate, utilize data that is received from or sent to one or more of the physical devices. A related pending application of the assignee is directed to a communications apparatus that also has primary utility in a mobile unit or vehicle and is used in selecting an acceptable communications channel for information transfers. Especially when such a communications apparatus is part of a mobile unit, it is often advantageous or necessary to change from one communication channel to another, depending upon the geographic location of the mobile unit.

Previously devised communication systems located within a vehicle achieve significant benefits. , However, it would be advantageous to offer the user more options in connection with the transfer of information relative to a vehicle. One option relates to achieving platform independence. Such platform independence allows the user to transfer information without requiring the user to employ or be subject to particular network layers or a particular communications channel in order to send/receive information, when using the communications apparatus in the vehicle.

SUMMARY OF THE INVENTION In accordance with the present invention, a communications system is provided for communicating between an external system and a modular base system. The base system is operatively connected to a number of peripheral devices including physical devices and is operatively connected to one or more applications including application programs. The base system provides the communications capability between the peripheral devices and the applications. Such communications include transfers of information including data between one or more of the peripheral devices and one or more of the applications. The base system is also involved with controlling and managing communications between the external system and the peripheral devices. Such communications can include the sending of information using results from running or executing an applications program, by means of data directly transmitted between the external system and one or more of the peripheral devices, and/or the downloading of applications programs. In one embodiment, the external system includes one or more remote stations that are located at a distance from the base system and one or more of the remote stations may utilize different communication protocols when accessing the base system. In such an embodiment, communications may occur wirelessly over an airlink to the base system, particularly where the base system is located at a great distance from the particular remote station.

The modular base system includes a network management module and a number of network devices that are controlled and/or managed by the network management module. The network devices include network modules in which at least some of them can be properly linked together to establish a communication path or channel between an application and one or more peripheral devices, such as peripheral devices found in or associated with a vehicle. These network modules include a number of well-known communication devices, such as sockets, TCP/IP, device protocol modules including Ethernet and device drivers that support the particular peripheral or physical device. Such network modules also include an address resolution protocol (ARP) module (typically combined with a reverse address resolution protocol module (RARP) that provides the ability to decouple the IP module from any underlying module or modules, such as Ethernet. The network modules are established in multiple layers similar to International Standards Organization (ISO) network layering. With regard to the afore-identified network modules, the lowermost layer of network modules includes the device driver module, the next lower layer includes the device protocol module (e.g. Ethernet), the next higher protocol layer includes the IP and ARP/RARP modules. Above that network layer is the layer that includes the TCP module. The next layer above the layer that includes the TCP module includes the socket interface module, which constitutes the interface for a substantial number of TCP communications. Importantly, many more network modules can be included as part of the modular base system, as well as adding more network modules as such communications-related tools or devices become available for use. Further, in establishing a particular communications channel within the base system, different network modules can be configured with one or more other network modules at the same network layer or at different network layers. In that regard, each of the network modules is required to register with the network management module. The network management module can track resources required at each network layer, for each protocol and dynamically resolve module interface procedure calls. The network management module is also involved with the network modules in connection with one network module utilizing the capabilities or service of another network module. Important to achieving such objectives, each of the network modules has a common interface associated with it by which each module is able to access or otherwise communicate with another module. Incorporation of such a registration requirement and common interface achieves platform independence since the implementation of such registration effectively renders the base system transparent to the code employed by the user when accessing the base system.

The common interface allows each network module to be connected to other network devices which implement and/or expect this interface. Each module implements a common interface of open, read, write, set options, get options and close functions or routines. Each such routine of each network module is provided to the network management module in connection with its management functions.

The network devices of the base system also include a number of network resources that are created by one or more of the network modules to assist them in their communication tasks. These network resources include one or more FIFO (first in first out) buffers. A FIFO buffer is useful in establishing queues for task or network module management. The TCP (transmission control protocol) module may create a FIFO buffer in order to provide a resource that is useful in its responding to connection requests from one or more network modules in another layer, such as the socket interface module. Other network resources include circular buffers (CBs) that have been determined to be flexible and effective in the organization and transfer of data within and between network modules. The IP (Internet protocol) module might utilize such a circular buffer to store route information related to one or more particular network devices that it communicates with. Still other network resources include one or more NCBs (no copy buffers) that are provided to reduce resource utilization and the need for copying data between network modules, which enhances throughput and responsiveness. In particular, the NCB can be passed bi-directionally between and among different network modules of the different layers. Further network devices include one or more error handling routines, information or statistics gathering routines, and information/data routing routines. In the preferred embodiment, a channel select error handling routine, together with associated channel select router and channel select scheduling routine are provided in accordance with the description in the previously noted pending patent application of the assignee of this application. Such custom or novel routines or functions are particularly useful in responding to a need for a different communications channel because, for example, the currently used communications channel is no longer reliable or is otherwise unacceptable. Each of such error handling, information gathering, routing and scheduling routines is typically called by a network module that requires the function or service of the particular routine. Additional network devices include callback routines. A callback routine can be used by one network module to receive incoming data from another network module within the modular base system. The data is passed to the callback routine by this particular module having or requesting such a callback routine. For example, data from a device protocol module, such as the Ethernet, may be passed directly to the IP module without invocation or use of the ARP/RARP module. A checksum routine is another routine useful to the network modules in checking data integrity. An operating system construct is also provided , which is identified as an event construct. The event construct is accessed or otherwise called by a network module in connection with providing notification, for example, that certain data has arrived and can be retrieved by the network module that desired or registered this event.

Network modules also include a network time module, a security module and an accounting module. The network time module is required in connection with desired routing/SNMP (system network management protocol) functions. The security module is used in authenticating and/or approving network connections as part of a firewall protection scheme. The accounting module enables users to obtain information related to network or other usage costs when utilizing the modular base system 124 and can use such information to reconcile it with their own usage records.

With regard to the operation of the modular base system, particularly involving the interactivity among and between network devices and the network management module, such operations or involvement can be categorized as involving registration of network modules, including resolutions of conflicts among network modules during the registration process and obtaining maximum transfer unit (MTU) information from network modules, together with creation of network resources and using them for information transfers. The registration of network modules with the network management module comprises the supplying of information by the registering network module to the network management module. This information includes: the protocol identification (ID) field, which refers to the assigned protocol numbers as provided in RFC (Request for Comments) 1700 ; the maximum transfer unit (MTU) field that represents the largest number of data, such as bytes, that the network module can send or receive; the network module's header information; and one or more of a number of routines for communication involving network modules, such as the open, close, read, write, set options and get options routines. The network management module returns a unique identification to the network module that the network module will use in its communications with the network management module. Additionally, the network management module will maintain a list of the particular network module's registration information that was supplied. The network management module will also keep a list, by network layer, of header information related to the maximum amount of information or data that can be transferred by the registered network module.

The network resources are created by network modules and involve communications with the network management module. A FIFO is established by a network module making a call with a predetermined call structure having a number of parameters to the network management module including a name for this FIFO and the number of elements of the queue associated with this FIFO. This particular FIFO structure is also maintained or stored by the network management module. Similarly, a CB (circular buffer) is created by the network module desiring such a network resource including by means of a CB call structure communicated to the network management module, which call structure has a number of parameters. These parameters include the name of the CB and the number of bytes that this particular buffer is allowed to hold. The network management module is used in generating a buffer control structure related to the CB being created. The buffer control structure includes a number of fields useful in managing, manipulating or otherwise controlling the CB. A NCB (no copy buffer) is established by a registered network module allocating this NCB by utilizing a particularly defined function that also has a number of parameters including a size parameter that indicates the number of bytes the caller is requesting for allocation and the name of this NCB so that it can be properly accessed or called.

With regard to information or data communications, when a first network module desires to communicate with a second network module, the first network module makes a call involving the network management module in order to open the interface with the second network module. Once the second network module is accessible, the first network module is able to make interface calls to transfer data, manipulate options and close the opened interface with the second network module. Registered error handling routines can also be called by network modules when they experience errors during operation. A predetermined call function is utilized for invoking a particular or desired error handling routine. In response, the error handling routine takes appropriate steps in accordance with its algorithms or predetermined steps. Similarly, a network module, such as the IP module, may invoke a particular routing routine, in conjunction with or separate from, the execution of the error handling routine. In one embodiment, as part of a routing routine, a channel scheduling module is employed related to controlling or buffering information that is to be transferred at an appropriate or available time. Fundamental steps are also taken when there are communications involving network resources. In the context of the TCP (transmission control protocol) module, it is invoked, for example, when a first connection request is received, with this first connection request being queued in the FIFO buffer and indication is given thereof. When a second connection request, for example, is received from another network module, it is also queued in the FIFO buffer. Subsequent reads of the FIFO buffer result in the first connection request being read or accessed before the connection request that arrived second. A CB can be invoked for accessing route information stored in a predetermined location in the CB. The NCB is defined to include a total number of bytes. When conducting the allocating function, data to be transferred is copied into the NCB. The data occupies less than the total number of bytes . The NCB with the copied data bytes can then be passed from a first network module to a second network module. When the NCB is passed, a pointer is adjusted from a first pointer position to a second pointer position. The second pointer position relates to the header information that is added to the NCB allocated space by the second network module. As the NCB is passed to further network modules, the pointer position continues to be changed based on the addition of header information of the succeeding network module (s) that receive (s) the NCB.

Based on the foregoing summary, a number of key aspects of the present invention are readily discerned. A communications apparatus is provided that enables one to utilize one or more network devices that are advantageously selected from a plurality of such devices in connection with transferring information, particularly transferring information between physical devices that may be located in a vehicle and one or more applications of a user. This main capability results in a robust communications engine that is less restrictive or limited in the communication channels that can be utilized or selected. In that regard, the capability exists for dynamically configuring network modules according to a variety of structures or communication channels, depending on user specifications or needs. Platform independence is achieved using network module registration procedures that are the domain of a network management module, with this architecture being transparent to the user applications. Efficient and effective management and control of network devices is achieved using the common network management module. The modular design allows for substantial adaptability or flexibility in connection with adding or removing network modules, as well as appropriate testing of such modular devices. Additionally, error handling is facilitated and customized routing of information is readily integrated, thereby providing desired control for the user in connection with selection of the communications channel being utilized for a particular application.

Additional advantages of the present invention will become readily apparent from the following discussion, particularly when taken together with the accompanying drawings .

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of the present invention illustrating major communication units;

Fig. 2 diagrammatically illustrates the network management module, network modules and network resources of the modular base system, as well as utility routines and opeiating system construct;

Figs. 3A-3B illustrate details of the network management module and representative network modules related to information lists, that are generated and stored using the network management module, having parameters useful in communication transfers and also illustrating representative network modules and their common interface;

Fig. 4 diagrammatically illustrates the interaction between and among network devices and the network management module in connection with information transfers among network layers in the modular base system; and

Figs. 5-9 constitute flow diagrams illustrating major steps that are conducted as part of information transfers among network devices of the network layers in conjunction with transferring information relative to one or more applications and one or more peripheral devices.

DETAILED DESCRIPTION

Referring to Fig. 1, a communications system 100 is illustrated, which includes an external system 104 and a communications apparatus 108, such as an embedded system, that communicate with each other using, preferably, a wireless communications system 112. In one embodiment, the embedded system 108 is embedded in a vehicle or other mobile unit to permit bi-directional communications from/to the vehicle. A disclosure directed to such an embedded system is found in the related co-pending U.S. Patent Application Serial No. 08/586,602 filed January 16, 1996 and entitled "Mobile Portable Wireless Communication System", which is hereby incorporated by reference and particularly pages 12-34 thereof including the referenced drawing figures, and even more particularly, pages 12-29 thereof including the referenced drawing figures.

The external system 104 might include one or more remote stations. Each remote station can include communications and processing related hardware and software that are different from that of the other remote stations. Each of such remote stations is able to separately communicate with the embedded system 108 including related to the transmission and reception of data germane to the vehicle, as well as downloading applications programs that use the hardware and software of the embedded system 108. The wireless communications system 112 is configured to perform all functions necessary related to the transfer of information to/from the embedded system 108. In one embodiment, the wireless communications system 112 includes a cellular telephone that is selected from a plurality of commercially available cellular phones. Such a cellular phone is operatively associated with a vehicle airlink transfer protocol modem for the proper handling of the airlink formatted transmission. The wireless communications system 112 also includes a network protocol converter that uses a wireless device interface. The wireless device interface establishes the necessary signal compatibilities and connections from the cellular telephone. The network protocol converter removes or otherwise converts the input information to a form that is acceptable to the embedded system 108 when communication transfers are being made to the embedded system 108 and, conversely, acceptable for airlink transmission to the external system 104 when communication transfers are occurring in that direction.

The embedded system 108 includes an applications module 116 having user programs with communication requirements relative to one or more sites different from the vehicle. That is, the external system 104 might require certain data or other information from the vehicle and one or more user programs function to provide such information. In that regard as well, the embedded system 108 includes one or more devices 120 located in or associated with the vehicle including physical devices (all such devices referred to as "peripheral devices"). By way of examples, such peripheral devices 120 can include one or more of the following: GPS (global positioning system) , dead reckoning sensors, facsimile machine, PDA (personal digital assistant) , laptop computer, printer, display unit, modem, CD-ROM unit, storage device (s), medical condition sensor (s), vehicle condition sensors, vehicle cargo sensor (s), air bag sensor and general alarm sensors related to unlocking the vehicle or unwanted intrusion into the vehicle. In one embodiment, one or more such peripheral devices 120 may communicate with and be under the common control of a vehicle controller area network (CAN) as will be discussed later herein. The embedded system 108 also includes a modular base system 124 for use in providing information transfers between the applications module 116 and the peripheral devices 120. The modular base system 124 is modular in design so that the modular base system 124 can readily adapt to the addition of later designed communications- related modules that provide different and/or additional beneficial functions. Furthermore, such modularity facilitates testing of units separately in the modular base system 124. The modular design also enables the user or others to configure the modules, for a particular application or use, in a desired and/or suitable way.

The modular base system 124 includes a network management module 130 and a number of network devices 132. The network devices 132 include a plurality of network modules 134 at least some of which communicate and/or are operative with one or more of the peripheral devices 120. The network modules 134 register with the common network management module 130 in order to communicate and function with each other in connection with information transfer processes. The network management module 130 also assists the network modules 134 in establishing network resources 138 using available storage devices, such as storage memory, buffers, registers and the like. The network modules 134 include a socket interface module 142 that communicates with the applications module 116 and includes a number of sockets, which act as an intermediary to render transparent to the applications module 116 the actual implementations found in the modular base system 124 including the functions of the other network modules 134. In that regard, the socket interface module 142 renders transparent any translation and mappings associated with other network modules 134. Accordingly, platform independence is achieved in the context of the user, e.g. through applications module 116, being able to transmit and receive data and other information relative to the peripheral devices 120. Such platform independence is important in allowing the user to structure and design its uses and applications in a manner suitable to the particular user, without being restricted to a particular platform in order to communicate with the embedded system 108. It should also be understood that the applications module 116 may communicate with one or more network modules 134 without reliance on or use of the socket interface module 142, especially where a particular application is not suitable for this socket interface.

With reference to Figs. 2 and 3A-3B, more information and greater details are next provided related to the modular base system 124. As seen in Fig. 2, there are a number of network modules 134. All or a substantial number of them can be defined as being part of a particular one of a number of network layers. The network layers are defined similar to International Standards Organization (ISO) network layering, such as in accordance with the following:

NFS/HTTP/FTP/TELNET/RLOGIN/USER Highest Network Layer

TCP/UDP Modules A

IP/ARP/RARP/ICMP/IGP/EGP/BGP Modules Device Protocol (Ethernet SLIP,

PPP, 802⁾ Modules Lowest Network Layer

Device Driver Modules

With regard to such network layers, it is anticipated that data/information cmpression is likely to occur at a number of the network layers, as well as in the applications. Such data compression will include the option to disable compression on lower network layers if such would impact higher-level applications. As an example, in the context of video data, under MPEG II, certain frames may not be suitable for compression, while streaming JPEG will be compressible again at a lower network layer.

Each of such network modules 134 has a common interface associated with it that enables each of them to communicate in a common manner with other network modules 134, on the same or different network layers. With regard generally to such network modules 134, each device driver module 146 supports the physical implementation of the one or more peripheral devices 120 that it is operatively connected to. A network layer above the network layer defined by device driver modules is the device protocol layer, which also implements the common interface to perform communications using the particular protocol over a selected peripheral device that uses that device protocol. The device protocol modules 140 of this layer may support multiple higher-level protocols in the network layer having the IP (Internet Protocol) module 154. Protocols are tightly coupled and must be addressed in the IP implementation. The IP module 154 supports multiple protocols using the routines associated with the common interface. Other network modules 134 can be categorized as being part of or associated with the same network layer as the IP module 154. Besides the ARP/RARP module 158, such network modules 134 in this common or particular network layer include the IPV6 (Internet Protocol Version 6) module 162, the ICMP module 166 and a number of network modules that are categorized or identified as gateway modules 170. TCP (transmission control protocol) module 174 and the UDP (user datagram protocol) module 178 are defined as being in the next higher network layer. These two modules 174, 178 operatively communicate with the socket interface module 142.

Additionally, other network modules 134, found in previously defined or, alternatively, different network layers, can be included and which have been generally termed support modules 182. These support modules 182 contribute to the implementation of the vast number of operations associated with achieving all-encompassing and widespread functionalities for managing and controlling information transfers. Certain of these support modules are noted, including a channel multiplexer module 184 that may be used for multiplexing communication transfers between a particular network module and a number of other network modules; a channel controller/monitor module 186 that is involved with monitoring and determining when a particular communications channel is available for use; a communications channel scheduling module 188, which commonly works with the channel controller/monitor 186, and functions to retain or store information until a particular communications channel is available. Other support modules 182 include: a data encryption module 190 for use in encrypting data before transmission, a data compression module 192 for preparing data in a reduced number of bytes for transfer and a modem control module 194 that is available for assisting in modem transfers; a network time module 196 for providing necessary time-related information for routing functions and system network management protocol; a security module 198 for insuring only proper and authorized access to the modular base system 124; and an accounting module 202 involved with the tracking of usage of the modular base system 124, particularly in the context of making suitable information available that is useful to the user in connection with monitoring or maintaining network usage costs. Other network devices 132 having special functions for performing a particular task when certain or predetermined circumstances occur are defined generally as routines/ utilities 202 and include: error handling routine (s) 206 , information gathering routine (s) 208, routing routine (s) 212, callback routine (s) 204 and checksum routine (s) 210. An error handling routine 206 is invoked when an error occurs, such as during the operation of a network module 134 and which module wishes to report the error and have the error handled by this routine 206. The information gathering routine 208 provides statistics-related data concerning error reporting and/or other functions of network modules 134. A routing routine 212 is beneficial in ascertaining a suitable or optimum communications path or channel for a particular information transfer. In one embodiment, such a routing routine 200 includes the capability of selecting a communications channel based on values associated with a number of parameters that are analyzed using one or more algorithms. Based on such a determination, a change or switch can be made from one communications channel to another. A callback routine 204 is utilized within the modular base system 124 to facilitate transfers between network modules 134. The callback routine 204 includes a function that is invoked for receiving incoming data by which a first network module receives the data via the callback routine 204 utilized by a second network module. A checksum routine 210 can also be utilized by the network modules 134 for data integrity analysis. In addition to such routines, one or more operating system constructs can be employed, e.g. an event construct 214 . Such an event construct 214 is typically accessed by one of the network modules 134 in connection with providing notification that data has arrived and can be retrieved from that network module 134.

In addition to the network modules 134, the network devices 132 include a number of network resources 138 that are available to the network modules 134 in connection with facilitating and enhancing information transfers. These network resources 138 include one or more first in first out (FIFO) buffers 216, control buffers (CB) 220 and no copy buffers (NCB) 224. The NCB 224 reduces resource utilization and eliminates the need for copying data that is being transferred between network modules 134 in order to improve throughput and responsiveness. The FIFO buffer 216 with queue and the CB 220 provide flexibility and are effective in the organization and transfer of data within and between network modules 134.

Further functional and structural aspects of these network devices are next described. The socket interface module 142 having a number of sockets constitutes the interface for all TCP module 174 and UDP module 178 communications. The socket interface module 142 of the present invention is based on the known Berkeley style socket routines . In connection with communications with network modules 134, the sockets of the socket interface module 142 rely on the common interface routines of the network modules 134, particularly to gain port numbers used in lower network layer protocol communications. The sockets of the socket interface module 142 may directly manipulate port structures returned to it or such sockets may make TCP module 174 and UDP module 178 calls using the common interface routines of these network modules 134.

The TCP module 174 is implemented or structured based on the standard RFC 793 including the specifications detailed therein. The TCP module 174 also has the common interface including access to routines useful with one or more sockets of the socket interface 142 for retrieving an instance of the TCP module 174. In conjunction with its operation, the TCP module 174 is invoked at initialization of the modular base system 124. The TCP module 174 is invoked after the IP module 154 is loaded and before implication of the services associated with the socket interface module 142. As applications use their instances of transmission control protocol, their state and current data values may change. To accommodate the multiple threads of execution, the TCP module 174 must be reentrant. The TCP module 174 will use data blocks to hold application state/port information and associate the appropriate data block to the instance of the TCP module 174. Similar to the TCP module 174, the UDP module 178 is based on previously established standards, namely, in RFC 768 and the specifications detailed therein. In addition to having the common interface, the UDP module 178, as will be explained further herein, must provide and register its own open routine to allow sockets of the socket interface module 142 to retrieve an instance of the UDP module 178. Like the TCP module 174, as applications use their instances of user datagram protocol, their state and current data values may change. To accommodate multiple threads of execution, the UDP module 178 must be reentrant. The UDP module 178 will use data blocks to hold application state/port information and associate the appropriate data block to the particular instance of the UDP module 178. The IP module 154 is based on the established standard of RFC 781 and the specifications detailed therein. Typically, the IP module 154 will handle many network module interfaces. The IP module 154 preferably has a working version of the ICMP (Internet Control Message Protocol) module 166 that is implemented based on the standard RFC 792 and the specifications detailed therein. The IP module 154 will be involved with a number of functions. It will be invoked with the names of each network device 132 it is to send/receive data over. The names of each network device 132 will be placed in an IP device table, such as a CB 220.

Each protocol connectable to the IP module 154 is able to open an Internet protocol stream indicating its protocol number using a predetermined routine registered with the network management module 130 by the IP module 154. The IP module 154 creates a protocol specific registry instance and returns the opened handle. In connection with a routing routine 200 being registered, the IP module 154 allows the application registering such a routine to handle all Internet protocol routing at the network interface level and the IP module 154 will call such a routine to resolve the route over which outgoing information will be sent. If no such routing routine 212 has been made available by the particular application, the IP module 154 routes outgoing data based on subnet masks provided with each interface of the network module 134 that is registered. On the other hand, there are instances where an application wants to control information or data transfers, in the context of the routing that such information should take, and/or the physical media to be employed, for example. In that regard, security concerns may require a particular route for such an application and the modular base system 124 includes this capability for permitting such controls to be established by the user. When invoking the IP module 154, the length of the invocation might be so long that a configuration file may be necessary. The IP module 154 constructs a network device table based on the network devices 132 passed to it. Data associated with such network devices includes: the network device 132 name, the IP address, the network mask and the device type given with the name. Additionally, the data could include the network device's maximum transfer unit (MTU) related to the amount of data that the network device can handle and header length that relates to the amount of information comprising the header of the particular network device. The IP module 154 is able to call other protocol modules defined as being part of its network layer including the ARP/RARP, IGMP, BGP, EGP and IGP protocol functions when they are registered with the network management module 130. The IP module 154 reads and writes from a wrapper routine and such a routine will act as an insulator from the actual underlying physical read/write constraints. The IP module 154 implements blocking operations, for protocol to Internet protocol communications, using event constructs including events related to pending information receptions and pending information transmissions.

The ARP/RARP (address resolution protocol/reverse address resolution protocol) module 158 provides the ability to decouple Internet protocol from the underlying physical device, for example, a device protocol module 150, such as Ethernet. The ARP/RARP module 158 is based on the standards set out in RFC 826 including the specifications detailed therein. The ARP/RARP module 158 is invoked once at startup of the modular base system 124. This invocation follows the invocation of the IP module 154. The ARP/RARP module 158 is involved with sending IP packets over requested network module interfaces. The ARP/RARP module 158 determines the network interface type from the interface handle that is provided to it. When the ARP/RARP module 158 resolves the destination IP packet into a physical address, the ARP/RARP module 158 queues the IP packet, transmits its request and waits for a reply to it. The ARP/RARP module 158 does not block the IP module 154 from processing while it waits to resolve an address. In addition to being part of the ARP module 158, the ICMP module 166 can be implemented as a separate module. The ICMP module 166 is used to ensure that the modular base system 124 does not break any existing networks to which it is connected. As part of its functions, the ICMP module 166 allows for custom routing utilities, i.e., it is possible to use ICMP requests to identify underlying network topologies and reachability matrices. The gateway modules 170 can include one or more of an EGP module 230, BGP module 232, IGP module 234, IGMP module 238 and a SNMP module 242. These modules are useful in identifying the modular base system 124 as a gateway. Their inclusion in the network modules 134 can provide Internet access to network aware devices connected to the modular base system 124, e.g., additional laptop, PDA equipment which may be accessed from a remote Internet site through links on the modular base system 124.

With reference to the device protocol modules 150, they are presently identified to include an Ethernet protocol module 250, Arcnet module 254, a SLIP module 258, a PPP module 262, a DHCP (dynamic host control protocol module 264, an ATM (asynchronous transfer mode) module 266, a 802 module 268, and a CARP (controller address resolution protocol) module 270. Ethernet and Arcnet protocol modules 250, 254 have well-established protocols, and their implementations as network modules correspond to such protocols. Like other network modules 134, each has a common interface for proper communication with other of the network modules 134. The SLIP module 258 is based on standards set forth in RFC 1055 and protocol specifications detailed therein. The SLIP module 258 has the ability to provide the CSLIP functionality. The SLIP module 258 is able to operate in blocking and non-blocking modes, as well as operate in compressed or non-compressed modes. One form of invocation of the SLIP module 258 involves the use of command line arguments that may be executed by currently available CPMW code. Such a command line argument would include the name under which the SLIP module 258 registers itself. A second command line argument indicates the name of the network device 132 over which the SLIP module 258 will read and write. Another optional command line argument specifies whether or not to use compression for the registered network device 132. The PPP module 262 is based on the standard RFC 1661 and the protocol specifications detailed therein. The PPP module 262 is responsive to dynamic Internet protocol assignment and dial-on-demand PPP operations. As with other network modules 134, the PPP module 266 registers itself with the network management module 130. The PPP module accepts a name over which to read and write and determines if the link is to be compressed. When dynamic IP addresses are provided, the PPP module 262 is given the IP address which it will assign or base assignments on. The DHCP (dynamic host control protocol) module 264 may be accessed and is useful in dynamically assigning IP addresses for interacting with a host and/or gateway. The ATM module 266 can be accessed, instead of the IP module 154, to perform essentially the same functions as the IP module 154, as well as offering different capabilities including, for example, guaranteed bandwidth.

The CARP module 270 is based on protocols for proper communication involving vehicle devices and, like other network modules 134, provides the common interface to permit access and operation associated with communications involving vehicle devices linked to a controller area network (CAN) .

The device driver modules 146 all provide a common interface for the protocol layers that will utilize the devices, such as peripheral devices 120 that they are associated with. Such device driver modules 146 include an Ethernet driver module 280 and the CAN driver module 284. Each of the device driver modules 146 provides the ability to locate/allocate the device API (application program interface) , provides blocking and/or non-blocking interface using its read/write interface, provides deallocation/release of the peripheral device 120 for other implementations, as well as providing certain options for its interface. Each device driver module 146 has the common network module interface, together with providing of values and other appropriate information when registered as network modules 134. Each device driver module 146 is started before invocation of each of the IP module 154, SLIP module 258 and PPP module 262.

Preferably, a domain name server (DNS) module 286 is available to the CAN module 284 to provide domain name availability or services for peripheral devices that communicate through or utilize the CAN module 284. Accordingly, it is feasible that each of such devices can have its own or unique domain name and which identifier can be used for communication purposes outside of the modular base system 124.

With reference particularly to Figs. 3A-3B, further descriptions are provided regarding the registration of network modules 134 with the network management module 130, as well as establishing communication paths that involve the network modules 134 and network resources 138. Each network module 134 is required to register with the network management module 130. The network management module 130 is able to monitor network resources 138 required at each network level, for each protocol of an associated network module 134 and dynamically resolve network module 134 interface procedure calls. In one embodiment for registering with the network management module 130, a call identified as net_register is utilized and defined as: net_register (name, network layer, registration structure) .

Each network module 134 sends the network management module

130 a name to identify itself, particularly related to its protocol. The network management module 130 also requires the network module 134 to specify its network layer or level on which the particular network module 134 expects to operate. The network management module 130 additionally is useful in resolving inconsistencies or conflicts that might arise between or among network modules during the registration process.

Each network module 134 also provides a set of values upon registration with the network management module 130, namely: protocolID - reflects the protocol's assigned number as set forth in the Internet publication

"Assigned Numbers," RFC 1700;

MTU (maximum transfer unit) - represents the largest number of bytes (octets) that the particular network module 134 can send or receive; HeaderLen - indicates the number of bytes (octets) contained in the particular network module's header information.

OpenRoutine, CloseRoutine, SetRoutine, GetRoutine, ReadRoutine and WriteRoutine - routines of the network module 134 being registered that establish the common interface, with each network module 134 being accessible by other network devices using these routines; and Argument (ARG) - represents specific information of the particular network module 134 as part of its registration with the network management module 130, and such information will be provided as the first parameter in any call to OpenRoutine, CloseRoutine, SetRoutine, GetRoutine, ReadRoutine and/or

WriteRoutine.

With respect to the afore-noted routines, a call representation of each is as follows: ope (ARG, identification); read(ARG, buffer, count); write (ARG, buffer, count); set_option (ARG, option code, option value, option value size) ; get_option (ARG, option code, option value space, option value space size) ; and

(ARG) .

Open allows the user of a network module 134 to identify itself and a specific identification will be returned so that the receiver of the specific identification can be uniquely identified and/or associated with necessary information to perform network module functions. Read is used in transferring data from the buffer that is identified up to the count specified. Write transfers data into the buffer identified up to the count specified. Set option allows the network device 132 of the modular base system 124 to set network module specific options as determined by the option code, option value

(typically set or reset) and option value size (for determining data type and data space expected) . Get_option allows a user to verify currently set module specific options, with option settings being determined by the option code provided, returned in the option value space provided and is of the option value space size that is also provided. Close is used to remove the user initiating the close from the active users that the network module 134 is accommodating so that any space held by associated data structures are made available and so that a user is properly removed from conducting network module activities.

Return codes indicate success or failure of each operation. ARG (argument) constitutes a value or other information determined by each network module 134 to help each such network module 134 identify the user and/or necessary values to carry out each operation.

As depicted in Fig. 3, such information or values are stored in a linked list by the network management module 130, together with additional items. In one embodiment, such registration information can be defined by the following linked list structure: guard; name; network layer; registration structure; node_next; and node_prev. The information or values associated with name, network layer and registration structure data have already been described. The guard field is set to a unique value for validity checking. The node_next and node_prev fields are used to store pointers that relate to the elements (e.g. data blocks) that follow and precede, respectively, the registered network module 134.

As also illustrated in Fig. 3A, the network management module 130 is used in storing a structure, by network layer, of maximum HeaderLen for each registered network module.134. As previously described, each of the network modules 134 can be categorized as being part of a particular network layer. For each network layer, each network module 134 associated with that network layer is identified in the structured list and associated or correlated with it is its header information. Such header information is useful when managing NCBs, as will be described later herein during the detailed discussion of the NCB 224. With regard to communication transfers involving the network modules 134 after they are registered, a first network module 134 seeking to communicate with a second network module 134 makes a predetermined call, such as defined by a net_open call, in order to receive a unique identifier associated with a pre-registered second network module 134 being called. The call to net_open results in a call of the registered OpenRoutine of the second network module 134 that was provided to the network management module 130 during its registration. The return from the net_open call will be the return code from the registered OpenRoutine. In one embodiment, the net_open call can be described as: net_open (name, ARG) The name parameter identifies the network module 134 being called. The ARG parameter is specific information that is to be communicated between the two particular network modules 134 and is passed as the second parameter to the registered OpenRoutine of the network module being called.

Once a network module 134 has successfully opened an interface to another network module 134 using the net open call, the calling network module 134 is able to make interface calls for the purposes of transferring data, manipulating options and closing the opened interface . The calling network module 134 uses an identifier returned from the net_open call when making any manipulation calls to the called network module 134. In one embodiment, the messages or calls that are invoked related to communication functions between two network modules 134 can be defined as : net__close (ID); net__write (ID, data, DataLan) ; net_read (ID, DATAP, DATAPLAN) ; net_set_option (ID, option, void optval, optvalsize) ; and net_get_option (ID, option, void optval, optvalsize) . Net_close calls the registered CloseRoutine associated with the ID field. The net_write calls the registered WriteRoutine associated with the ID field. The net_read calls the registered ReadRoutine associated with the ID field. The net_set_option calls the registered SetRoutine associated with the ID field. The net_get_option calls the registered GetRoutine associated with the ID field.

With continued reference to Fig. 3A, the FIFO buffer 216, the CB 220 and the NCB 224 of the network resources 138 will be further described. Referring first to the FIFO buffer 216, it is useful in communications internal to as well as between network layers. The FIFO buffer 216 is accessible using the previously described OpenRoutine, CloseRoutine, SetRoutine, GetRoutine, WriteRoutine and ReadRoutine. Regarding the creation of a FIFO buffer 216, a network module 134 is typically involved and uses a predetermined function having a number of parameters, such as: net crt fifo (n elts, name) The network module 134 making the call and wishing to create the FIFO buffer 216 provides the number of elements that the queue of this buffer is allowed to hold (n_elts) and a resource name for the FIFO buffer 216 (name) that uniquely identifies this particular queue to the network management module 130. The net_crt_fifo invocation creates a FIFO buffer 216 control structure (net_fifo_buf) that can be defined as follows: MylD; FIFOelt Readptr;

FIFOelt Writeptr; NumQd; Bufsize; The field MylD stores the unique ID given upon FIFO buffer 216 registration with the network management module 130 and is also used to destroy or cancel the created FIFO buffer 216. The Readptr field is an element pointer indicating the next element that may be extracted from the FIFO buffer 216. The Writeptr field is an element pointer indicating the last element on the list contained in the FIFO buffer 216 and thereby provides the location of the next element to be added to the particular FIFO buffer 216. The NumQd field represents the number of elements that have been queued in the particular FIFO buffer 216. The Bufsize field indicates the number of elements that the queue of the FIFO buffer 216 can hold, which is provided in the n_elts parameter of the structured call for creating the FIFO buffer 216.

With respect to using the FIFO buffer 216, upon a network module 134 calling net_write, the information given in the buffer argument will be copied into the afore- defined control structure (netFIFOelt) : size; struct FIFOelt next; struct FIFOelt prev; data. The foregoing structure will be dynamically created to be the size of the buffer passed (as indicated by the buffer size argument given in the call) , plus the size of the netFIFOelt structure. The buffer size will be stored in the size field. The buffer data will then be copied into the created netFIFOelt structure beginning at the data field. The structure will then be added to a doubly linked list using the next field to reference the next element in the list and the prev field to reference the previous element in the list. Netfifoelt structures are added to the list in a manner that the first element added is the first element retrieved.

To cancel or otherwise remove the created FIFO buffer 216, the user of the particular FIFO buffer 216 invokes a predetermined call, such as: net_destroy_FIFO (Id FIFO Id)

Upon being invoked, this call will free memory allocated to each element stored in the queue of the particular FIFO buffer 216 being destroyed, as well as unregister itself from the network management module 130 and release any memory associated with the buffer control structure.

Regarding the CB 220, it is useful in communications internal to as well as between network layers having different protocols. Like the FIFO buffer 216, the CB 220 provides the OpenRoutine, CloseRoutine, SetRoutine, GetRoutine, WriteRoutine and ReadRoutine. A user of a CB 220, such as a network module 134, creates the CB 220 before it is used. In one embodiment, a function having parameters that is used to create a CB 220 is defined as: net crt circ (size, name) The caller provides the number of bytes that the CB 220 is allowed to hold (size) and a resource name for the CB 220 (name) that will uniquely identify this buffer to the network management module 130. Invocation of crt_circ creates a CB control structure (circ_buf) that can be defined to include the following parameters: MylD; readptr; writeptr; bufsize; bufstart; The MylD field identifies the particular CB 220 and is the information returned from the net_register call used to register the interface to the particular CB 220. The readptr field indicates the position in the CB 220 from which data bytes are transferred upon issuance of a read request. The readptr field is incremented for each byte read. The writeptr field indicates the position in the CB to which data bytes are transferred upon issuance of a write request. The writeptr field is incremented for each byte written. The bufsize field indicates the size and bytes of the CB 220 and is the same value given as a parameter in the call crt_circ. The bufstart field indicates the first byte in a contiguous block of data of bufsize bytes. The bufstart field represents the start of the particular CB 220.

Options are also available to call in connection with manipulation of the CB 220. Upon a call to set_option, with an option code, for example, of circ_wptr, the writeptr field of the CB 220 referenced in the call will be set to the option value given for the CB size (bufsize) . Upon a call to set_option, with an option code of circ_rdptr, the readptr field of the CB 220 referencing the call will be set to the option value associated with the circular buffer size (bufsize) . The user may use these options for faster circular buffer data access, e.g., to implement a linear hash buffer of elements.

A previously created CB 220 can be removed by the user making a predetermined call such as through use of a net_destroy_circ routine identified as: net_destroy_circ (ID circld) The circld field is the identifier returned to the user from crt_crc or net_open. The functions resulting from the call to destroy_crc releases the memory held by the circ_buf structure associated with the given circld.

It should be appreciated that recovery or other procedures can be invoked when a particular FIFO buffer 216 or CB 220 experiences an overflow or other buffer usage problem. In such a case, conventional and available techniques or procedures are included for access and usage in order to handle any such event or error that occurs.

Referring to the NCB 224, such no copy buffers are intended to reduce the number of copy operations that occur when transferring data between and among network modules 134. The network management module 130 has an established process for registered network modules 134 to allocate a NCB 224 by utilizing a predetermined function or call identified as: net_aloc (ID, size) The ID parameter represents the caller's network identification as returned by a call to net_register . The size parameter indicates the number of bytes the caller would like to allocate. Upon invoking the net_aloc function, a pointer is returned to a contiguous block of memory of the indicated size. Additionally, when calling the function net_aloc, the network management module 130 determines the number of bytes that may prepend the NCB 224 by taking into account previously stored information about the network module 134 that is making the call for the NCB 224, with such information including the number of network modules 134 that may follow or link with the particular network module 134 and their maximum header sizes. The network management module 130 allocates enough space to fulfill the request for the data to be provided with the NCB 224 plus enough space allocation to allow network modules 134 located in lower network layers to store their necessary header information. The buffer reference pointer returned by the net_aloc call is thus an offset into the actual buffer where data is stored to accommodate information that may pre-pend the NCB 224 as it passes through the network layers between and among network modules 134. To track the allocation information, the network management module 130 allocates, in one embodiment, the following control structure having a number of parameters and identified as net_alloc_info : Id allocator; request_size; NCBsize; NCB; alloc info prev; alloc info next. The Id allocator field holds the identification of the network module 134 as was provided in the call to the net__alloc function. This is useful in identifying the creator of the NCB 224 and thus provide information related to the origination of the buffer. The request_size field indicates the size that was requested at the time of the call to the net_alloc function. The NCBsize field represents the actual size of the allocated buffer. The NCB field is a reference to the buffer which was actually allocated (offset zero) . The prev and next fields of the structure allow the network management module 130 to maintain the allocation information in a doubly-linked list, with prev referencing the previous element in the list and next referencing the next element in the list. To release memory allocated based on invocation of the net_aloc function, a predetermined call to a routine for providing such a release is made by a network module 134, which call can be identified as: net_free (ID NCB)

Invocation of the free function traverses the allocation linked list to find an entry containing the reference NCB. The given NCB is matched with a stored NCB by looking at the pointer values. The given NCB pointer value must be greater than or equal to the stored NCB pointer value and less than or equal to the stored NCB pointer value plus the stored NCB size (NCB size) . If a match is found, the stored NCB is freed as well as the entry containing the matched NCB.

Further detail is next provided related to use of a NCB 224 in connection with passing or transferring data between and among network modules 134 including the prepending of header information. Such information is provided in the form of an example. Assume that the socket interface module 142 requests 500 bytes. Upon such a request, 554 bytes are actually allocated. The network management module 130 obtains the header information for the network modules 134 that will follow the socket interface 142 in connection with the passing of the 500 bytes of data. In that regard, the network management module 130 obtains the maximum header information

(HeaderLen) for the TCP module 174 (assume 20 bytes) ; for the IP module 154 (assume 20 bytes) and for the Ethernet protocol module 250 (assume 14 bytes) . The particular socket of the socket interface module 142 receives a reference within the NCB 224 at an offset of 54 bytes so that only the 500 bytes requested may be directly accessed. The socket interface module 142 is used to copy the 500 bytes into the NCB 224 and passes the NCB 224 to the TCP module 174 using the previously acquired interface. The TCP module 174 adjusts the given offset to accommodate its own header, namely from 54 to 34, and enters the TCP module header information. The TCP module 174 then passes the NCB 224 to the IP module 154 via the previously acquired interface between these two modules. The IP module 154 adjusts the given NCB 224 to accommodate its header, from 34 to 14, enters the IP header information and passes the NCB 224 to the Ethernet protocol module 250 through the ARP/RARP module 158, which is essentially a pass-through module that does not prepend any header information. The Ethernet protocol module 250 adjusts the given NCB 224 offset from 14 to zero and fills in the Ethernet header information. The NCB 224 is transmitted including its data to the Ethernet device driver 280. The Ethernet device driver receives a packet of 554 bytes.

Similar to passing of data and prepending header information down through network layers, header information is prepended to data in an NCB 224 during passage of the NCB upwardly through network layers. For example, the Ethernet device driver module 280 requests the 554 bytes and receives an offset of zero (no header information prepends) . The Ethernet device driver module 258 sends the packet of data as part of the NCB 224 to the Ethernet protocol driver 250. The Ethernet protocol driver 250 interprets its header and passes a modified offset from zero to 14, to the IP module 154. The IP module 154 processes its header information, adjusts the offset in the NCB 224 from 34 to 54 and passes the NCB 224 to the particular socket of the socket interface 142.

Certain routines or other utilities useful to the network modules 134 are next described in more detail. Error handling routines 206 and information gathering routines 208 are available for registered network modules 134. Error handling routines 206 can be registered with the network management module 130 and called by the network modules 134 to process errors of the network modules 134. More than one error handling routine 206 can be registered. Each such error handling routine 206 might be called in the order in which it was registered or, alternatively, any such error handling routine 206 could be called or managed in accordance with other suitable rules or protocols. In one embodiment, an error handling routine 194 can be registered by a user calling the following function having the identified parameters: ereg_hndlr (hndlr, ARG) A function pointer (hndlr) is given that represents the entry point to the particular error handling routine to be called for processing errors. The ARG parameter specifies information to be given as the first parameter to the called function or routine identified as hndlr. The error handling routine 206 also takes ID, error and char parameters in that order. The ID parameter identifies the network module 134 which generated the error. Typically, the error handling routine 206 calls get_option to get the protocol identifier and other information thereby identifying the caller. The error parameter identifies the error being reported. The char parameter constitutes the specific data for the generated error. The error handling routine 206 determines if the error is informational

(statistic) or if it indicates a problem in the system.

The return to a dreg_hndlr call provides a network identifier for the particular error handling routine 206.

When a user determines that it wishes to discontinue using a particular error handling routine 206, a predetermined function is invoked, such as that identified by the following: eunreg_hndlr (ID) This called function removes the identified error handling routine 206 from the list of active error handling routines and releases any resources associated with the registration of the removed error handling routine 206.

Each registered network module 134 is able to invoke a predetermined call or function to report errors such as the function identified as: error (ID, errortype, errorstring, fatal) ; The caller supplies the identification (ID) returned from the register call. The parameter errortype indicates the type of error (error code) . The parameter errorstring indicates data associated with the error and may be a printable string. The parameter fatal indicates whether or not the error is detrimental to further operation of the system. For example, if fatal is set to 1 (true) , then the network management module 130 issues a software reset after completing calls to all registered error handling routines 194.

A routine that is optional and might be a useful resource, depending on the particular transfer or application, is identified as a checksum utility or routine 210 since many Internet standard protocols use the same such utility. In one embodiment, this routine and accompanying parameters are identified as: checksum (buf, endwords) ; The checksum routine 210 requires the data over which a check sum is to be calculated (buf) and the number of 16- bit words that the data encompasses (the buffer size in 16- bit quantities) . The checksum routine 206 computes a 16- bit ones complement of the 16-bit ones complement sum of all 16-bit quantities contained in the given buffer and returns its value.

With reference to Figs. 4 and 5, further descriptions of the modular base system 124 are provided in the form of operations and examples involving the network modules 134 and the network resources 138, together with the network management module 130 and associated routines and operating system constructs. In particular, Fig. 4 illustrates a number of selected network modules 134 from different network layers that are involved in a particular application required by the applications module 116. Fig. 5 briefly describes in flow diagram fashion the major steps involved in conducting such operations. In particular, the applications module 116 initially seeks to transfer data to at least one peripheral device 120. In accordance with this objective, the necessary or appropriate network modules 134 and network resources 138 must be registered and operatively opened or connected with and among each other before such a transfer can occur. In that regard, at step 304 of Fig. 5, the Ethernet device driver module 280 registers with the network management module 130. As part of its registration, the Ethernet device driver module 280 registers the identity of its network layer, the size of its header information and its MTU, which indicates the maximum amount of data that can be transferred across its interface at one time. As previously described regarding Fig. 3, common interface routines are also registered and lists are stored related to information or values associated with the Ethernet device driver module 280.

At step 304, the Ethernet protocol driver module 250 acquires an interface for the Ethernet device driver module 280 by use of the appropriately described functions or calls including use of an open call to be able to use an OpenRoutine for establishing the interface connection between these two modules. The Ethernet protocol module 250 is also registered with the network management module 130 and provides the same values, data and/or other information that is required for registration, just as was done when the Ethernet device driver module 280 was registered. Additionally, the Ethernet protocol module 250 registers an eventl 214 with the Ethernet device driver module 280. This event will be utilized in connection with providing an indication by the Ethernet device driver module 280 to the Ethernet protocol module 250 that data is available for transfer.

At step 316, the ARP/RARP module 158 establishes two Ethernet protocol driver interfaces. One of the interfaces is for the IP module 154, which is necessary since Ethernet protocol is a many-to-one protocol. The other of the two interfaces is for the ARP/RARP module 158 itself. The ARP/ RARP module 158 also registers its name with the network management module 130 and, unlike the previously noted network modules 130, has no header information and therefore specifies a zero header size. The ARP/RARP module 158 also registers a callbackl 204 with the Ethernet protocol module 250 for address resolution protocol data only.

In accordance with step 328, the IP module 154 creates a circular buffer (CB) 220 that will be used in storing information related to devices that it is in communication with and this CB 220 is necessary since Internet protocol (IP) is a many-to-many protocol. At step 332, the IP module 154 also requires an interface for each of the devices that it communicates with and, in accordance with this example, this device is the ARP/RARP module 158. Like the other network modules 134 being registered, the IP module 154 registers its name with the network management module 130 and specifies its network layer, header size and MTU, as well as providing other values or information that are required for stored lists. The IP module 154 registers a callback2 204 with the Ethernet protocol module 250 through the ARP/RARP module 158. This callback routine will be used in transferring data directly from the Ethernet protocol module 250 to the IP module 154.

At step 344, the TCP module 174 establishes an interface for the IP module 154 in accordance with previously described steps involving use of the OpenRoutine and the calling of the open function that resulted in obtaining the OpenRoutine for the IP module 154 from the network management module 130. At step 348, the TCP module 174 registers its name with the network management module 130 and, like other network modules 130, specifies its network layer, header size and MTU, together with other required values or information to be included in the appropriately stored lists. A callback3 204 is also registered by the TCP module 174 at step 352 with the IP module 154. This callback3 204 is useful in transferring data from the IP module 154 to the TCP module 174.

At step 356, the socket interface module 142 calls the registered TCP module 174 and its registered OpenRoutine. The socket interface module 142 specifies a passive call, which leads to the creation of a FIFO buffer 216 for another or returned TCP module interface that has a FIFO buffer 216 for use in accepting connections to be handled by the TCP module 174. Registration of TCP module routines

(Read, Write, Get, Set, Close) is also made to enable their use by the socket interface module 142. This returned interface is used for reading and writing functions involving the sockets and the TCP module 174. At step 364, an event2 214 is registered with the TCP module 174 for indicating socket interface communications being received by it.

With these network modules 134, network resources 138, callback routines 204 and event constructs 214 registered or otherwise established, an example related to transfer of data bytes is next described. Beginning at step 368 of Fig. 6, the applications module 116 seeks to transfer data bytes and starts this process by writing the data bytes over the socket interface module 142. At step 372 of Fig. 7, in connection with use of a network resource 138 to transfer the data bytes, the socket interface module 142 requests a NCB 224 with its size dependent on header sizes for each network layer that follows it. With the requested NCB 224 available, the socket interface module 142 copies the data bytes into the NCB 224 and passes the NCB 224 to the TCP module 174 at step 376. The TCP module 174, at step 380, adjusts the offset pointer associated with the NCB 224 based on the TCP module 174 header and also enters its header information into the proper storage locations or area of the NCB 224.

Referring to Fig. 7, the TCP module 174 then writes or passes the NCB 224 to the IP module 154 at step 384 using the WriteRoutine of the IP module 154. In accordance with step 388, the IP module 154 adjusts the offset pointer associated with the NCB 224 based on the size of its header and enters the IP module header information. After doing this, at step 392, the IP module 154 passes the NCB 224 through the ARP/RARP module 158. After passing through the ARP/RARP module 158, the NCB 224 is received by the Ethernet protocol module 250 at step 396. The Ethernet protocol module 250 adjusts the offset pointer for the NCB 224 based on its header information. At step 400, the Ethernet protocol module 250 then transmits the data bytes with the header information of all prior network modules just described as part of the NCB 224. At step 404, the Ethernet device driver module 280 receives this NCB 224 having the data bytes plus the header information of the higher network layers. At step 408, the data originating from the applications module 116 can be provided to one or more of the peripheral devices 120.

With reference to Fig. 7 and then Fig. 8, further steps illustrating the operation and interactivity among network modules 134 and network resources 138 is further described in the context of a data transfer from a peripheral device 120 through lower network layers to higher network layers. At step 412, data is available from a peripheral device 120 that is to be sent to the applications module 116. At step 416 of Fig. 8, this data is received initially by the Ethernet device driver module 280. The eventl 208 is set, at step 420, by the Ethernet device driver module 214 indicating that it has data available for transfer. Subsequently, at step 424, the Ethernet device driver module 280 sends the data bytes to the Ethernet protocol module 250 at step 424. Comparable to the description related to the transfer of data from the applications module 116, each network module 134 that is involved with the transfer of the data bytes adds its header to the NCB 224 and adjusts the offset pointer for access by the next network module 134 that will receive the passed NCB 224. In accordance with this procedure, at step 428, the Ethernet protocol module 250 adjusts the offset pointer for the NCB 224 based on its header. Further, based on information that it receives, the NCB 224 is passed to the IP module 154 using callback2 204 and bypasses the ARP/RARP module 158. For a different destination, the Ethernet protocol module 250 accesses the callbackl 204 of the ARP/RARP module 158, which is provided to it in the packet of data being transferred. Once a resolution of where the data is to be transferred is complete, the ARP/RARP module 158 then sends the buffered data to that location. When the Ethernet protocol module 250 sends the data to the IP module 154, it adjusts the offset pointer of the NCB 224 based on its header at step 432. With regard to the transfer of the NCB 224, the IP module 154 invokes the callback3 204 routine that was registered previously by the TCP module 174, in accordance with step 436. The callback3 facilitates the transfer of the data between these two network modules. Upon receipt of the transfer data, at step 440, the TCP module 174 adjusts the offset pointer of the NCB 224 based on its header information. At step 444, the TCP module 174 sets the event2 214 that was registered by the socket interface module 142 indicating reception of the data by the TCP module 174. At step 448, the socket interface module 142 receives the data that was transferred by the NCB 224 from the TCP module 174. At step 452, the applications module 116 reads the data received through the socket interface module 142 from the TCP module 174 for use by one of the applications associated with the applications module 116 at step 452.

In connection with an occurrence of an error, certain procedures are conducted using other network devices that have been previously described. These network devices are also illustrated in Fig. 4. Under circumstances when an error occurs in the TCP module 174, for example, related to data corruption, the TCP module 174 calls an error function available in the modular base system 124 at step 456. The invoked error function, at step 460, calls a registered error handling routine 206 that has been previously registered to respond to and be responsible for handling such an error in this particular situation. The error handling routine 206, at step 464, selects a different communications channel based on the determination that the presently used communications channel is unacceptable. In conjunction with arriving at a new communications channel, the IP module 154, at step 468, calls a registered routing routine 212. The routing routine 212 has also been previously designated for access when such an error is reported. Continuing the discussion with reference to Fig. 9, at step 472, this routing routine 212 provides a new selected communications channel at step 472. Included as another option is use of the channel scheduling module 188, at step 476, when it is determined that the new communications channel is not currently ready to make the information or data transfer. At step 480, the channel scheduling module 188 buffers the data that is to be transmitted until the new communications channel is ready. In that regard, the channel controller/monitor module 186 is used in monitoring and determining when the new communications channel is ready, in accordance with step 484. With the new communications channel being ready for the data transfer, the channel scheduling module 186 permits the data to be transmitted at step 488. Based on the release of the data using the channel scheduling module 188, the IP module 154, at step 492, transmits the data over the new communications channel. Apparatus and methodology for providing such related error handling and routing functions is described in substantially greater detail in a pending and related U.S. Patent Application identified by Serial No. 08/778,897 filed January 3, 1997 and entitled "Communications Channel Selection". This pending application is hereby incorporated by reference, particularly including pages 11-34, as well as Figs. 1-5B, and even more particularly, pages 18-34 including the referenced drawing figures. Such disclosures in this related application have particular applicability to the present application in conjunction with its description of an embodiment for selecting an acceptable communications channel. In addition to the foregoing functions and operations for communication transfers involving the modular base system 124, further network modules can be designed and employed. Included among these might be a network module 134 used to manage priority of communication transfers and provide preemptive control in connection with communication transfers depending upon the presence of one or more predetermined factors. The foregoing discussion of the invention has been presented for purposes of illustration and description. Further, the description is not to limit the invention to the form disclosed herein. Consequently, variations and modifications commensurate with the above teachings within the skill and knowledge of the relevant art, are within the scope of the present invention. The embodiments discussed herein above are further intended to explain the best mode known of the invention, and to enable others skilled in the art to utilize the invention in such, or another embodiments and with the various modifications required by their application or uses of the invention. It is intended that the appended claims be construed to include alternative embodiments to the extent permitted by the prior art.

Claims

What is claimed is:

1. An apparatus for communicating using a plurality of modules, comprising: a plurality of network devices including a number of network modules and a number of network resources, with each of said network modules having a common interface; and a network management module communicating with each of said network modules for registering each of said network modules and for assisting said network modules in establishing said network resources that are useful in communication transfers involving said network modules.

2. An apparatus, as claimed in Claim 1, wherein: at least some of said network modules are defined as being included in different network layers and in which said some network modules in said different network layers communicate with each other using said common interfaces said network modules.

3. An apparatus, as claimed in Claim 1, wherein: said network modules include a device driver module, a device protocol module, an Internet protocol (IP) module, a transmission control protocol (TCP) module that is separate from said IP module and a socket interface module.

4. An apparatus, as claimed in Claim 3, wherein: said network modules include an address resolution protocol (ARP) module that is used in decoupling said IP module from one or more network modules that underlie said IP module in a different network layer.

5. An apparatus, as claimed in Claim 3, wherein: said device protocol modules include one of an Ethernet module, a SLIP module and a PPP module.

6. An apparatus, as claimed in Claim 3, wherein: said network modules include an ICMP module, an IGP module and an EGP module, each of which is defined to be on the same network layer as said IP module.

7. An apparatus, as claimed in Claim 1, wherein: said network resources include at least one of the following: a first in first out (FIFO) buffer, a circular buffer (CB) and a no copy buffer (NCB) .

8. An apparatus, as claimed in Claim 7, wherein: said FIFO buffer is used in queuing requests for response by one of said network modules in an order established by said FIFO buffer.

9. An apparatus, as claimed in Claim 7, wherein: said CB is used in storing information related to routing of data.

10. An apparatus, as claimed in Claim 7, wherein: said NCB is used in communicating information between at least two of said network modules defined as part of two different network layers.

11. An apparatus, as claimed in Claim 1, wherein: said network modules have a number of routines associated therewith that are registered with said network management module and are used in communicating using said common interfaces of said network modules, with said routines including open, close, read, write, set options and get options.

12. An apparatus, as claimed in Claim 1, wherein: said network devices include a plurality of the following: error handling routine, information gathering routine, callback routine, event, channel scheduling module and channel routing module .

13. An apparatus, as claimed in Claim 1, wherein: said network management module is used in providing a list of parameter information for each of said network modules upon registration thereof and with said parameter information including a plurality of the following: a protocol assigned number, a maximum transfer unit number related to network module transfer capability, a number related to header information, module interface routines and module specific information in an argument field.

14. An apparatus, as claimed in Claim 1, wherein: said network management module is used to store a list, by network layer, of header information of each of said registered network modules.

15. A method for communicating using selected ones of a plurality of network modules and a network management module, comprising: establishing a network management module; providing a plurality of network modules including first and second network modules; registering each of said network modules with said network management module; and communicating information using selected network modules including between said first and second network modules utilizing a common interface associated with each of said first and second network modules.

16. A method, as claimed in Claim 15, wherein: said establishing step includes making available communication links between each of said network modules and said network management module and using communication messages having predetermined parameters as part of said registering step.

17. A method, as claimed in Claim 15, wherein: said providing step includes maintaining communication separateness among said plurality of network modules which requires that each of said network modules be able to communicate with others of said network modules using said common interfaces.

18. A method, as claimed in Claim 15, wherein: said registering step includes supplying information by said first network module to said network management module, with said information including a plurality of the following: a protocol assigned identification, header data, an information transfer capability related number and routines available for use with said first network module.

19. A method, as claimed in Claim 18, wherein: said registering step includes replying by said network management module to said supplying step including sending a name to said first network management module that is used by said first network management module in communications with said network management module.

20. A method, as claimed in Claim 15, wherein: said registering step includes generating and storing a list of parameter information acquired from said first network module by said network management module.

21. A method, as claimed in Claim 15, wherein: said registering step includes preparing and storing a list related to header information, by network layer, for each of said first and second network modules.

22. A method, as claimed in Claim 15, further including: creating at least a first network resource by said first network module with involvement of said network management module and with said first network resource including one of: a FIFO buffer, a circular buffer (CB) and a no copy buffer (NCB) .

23. A method, as claimed in Claim 22, wherein: said creating step includes sending a call structure to said network management module by said first network module that includes parameter information comprising a name for said FIFO buffer and a number of elements that said FIFO buffer is able to queue.

24. A method, as claimed in Claim 23, wherein: said creating step includes developing a stored structure list related to said parameter information received from said first network module associated with said FIFO buffer.

25. A method, as claimed in Claim 22, wherein: said creating step includes transmitting a name for said CB and a number of bytes that said CB is allowed to hold as part of said parameter information.

26. A method, as claimed in Claim 22, wherein: said creating step includes allocating said NCB by sending an allocate function to said network management module by said first network module and in which said allocate function has a number of parameters including an identification parameter that represents the identification of said first network module and a size parameter that relates to a number of buffer locations requested for allocation by said first network module.

27. A method, as claimed in Claim 15, wherein: said communicating step includes said first network module opening an interface to said second network module and then using at least one of the following routines in connection with said communicating step: write, read, set options and get options.

28. A method, as claimed in Claim 27, wherein: said communicating step includes closing said interface after said interface has been opened with said second network module by said first network module.

29. A method, as claimed in Claim 15, wherein: said communicating step includes calling an error handling routine by said first network module using said network management module and in which said calling step includes identifying said first network module as generating an error and including a parameter that identifies the error being reported.

30. A method, as claimed in Claim 15, wherein: said communicating step includes making a call to a callback routine for use in receiving data and in which said making step includes calling a set option routine of said second network module by said first network module.

31. A method, as claimed in Claim 15, wherein: said communicating step includes initiating a call to an event construct and in which said initiating step includes setting an event by said second network module to notify a user of an occurrence causing said setting.

32. A method, as claimed in Claim 15, wherein: said communicating step includes communicating information using a first in first out (FIFO) buffer by invoking said FIFO buffer that involves sending a first connect request thereto, queuing said first connect request, indicating receipt of said first connect request, sending a second connect request, queuing said second connect request, indicating receipt of said second connect request and retrieving said first connect request from said FIFO buffer before said second connect request.

33. A method, as claimed in Claim 15, wherein: said communicating step includes utilizing a circular buffer (CB) by first invoking said CB when seeking first route information from a predetermined location of said CB, reading from said CB until said first route information is found, next invoking said CB seeking second route information different from said first route information and reading from a location in said CB subsequent to said first route information.

34. A method, as claimed in Claim 15, wherein: said communicating step includes utilizing a no copy buffer (NCB) by allocating said NCB including requesting a total number of storage locations, copying data into said NCB and with said data occupying less than said total number of storage locations, passing said NCB from said first network module to said second network module and adjusting a pointer from a first position to a second position, with said second position related to header information associated with said second network module.