EP1296238A2 - Communication unifiée entre des processus - Google Patents

Communication unifiée entre des processus Download PDF

Info

Publication number
EP1296238A2
EP1296238A2 EP02009766A EP02009766A EP1296238A2 EP 1296238 A2 EP1296238 A2 EP 1296238A2 EP 02009766 A EP02009766 A EP 02009766A EP 02009766 A EP02009766 A EP 02009766A EP 1296238 A2 EP1296238 A2 EP 1296238A2
Authority
EP
European Patent Office
Prior art keywords
uipc
message
shelf
messages
card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02009766A
Other languages
German (de)
English (en)
Other versions
EP1296238A3 (fr
Inventor
Yeong-Hyun Yun
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Priority to EP02019789A priority Critical patent/EP1296239A3/fr
Publication of EP1296238A2 publication Critical patent/EP1296238A2/fr
Publication of EP1296238A3 publication Critical patent/EP1296238A3/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Definitions

  • the present invention relates to a unified interprocess communication system, and more particularly to a unified interprocess communication system and method that can be utilized for communication regardless of the hardware and the software used.
  • a communication system can be provided with various types of communication equipment and module, such as asynchronous transfer mode (ATM), synchronous digital hierarchy (SDH), and Internet protocol (IP), for example.
  • ATM asynchronous transfer mode
  • SDH synchronous digital hierarchy
  • IP Internet protocol
  • each system uses an interprocess communication (IPC) method which is different from the other system.
  • IPC interprocess communication
  • the IPC is tightly coupled to and depends on the respective hardware device of each system.
  • an asynchronous transfer mode system uses an IPC method which is different than the IPC method made by a synchronous digital hierarchy system.
  • an interprocess communication method able to improve the portability of the IPC by introducing a device independent access layer (DIA) into the system and by loosely coupling the IPC to each hardware device.
  • DIA device independent access layer
  • a communication apparatus for transmitting message data from a source to a destination regardless of what operating system is being used in the communication apparatus.
  • the present invention provides a high amount of portability and flexibility.
  • a communication method for transferring message data from a source to a destination regardless of what hardware equipment is being used in the communication apparatus is provided.
  • a communication apparatus for transmitting message data from a source to a destination regardless of what communication methods (for example asynchronous transfer mode, Internet protocol, synchronous digital hierarchy, and others) are used by the apparatus.
  • communication methods for example asynchronous transfer mode, Internet protocol, synchronous digital hierarchy, and others
  • the present invention provides a communication method for conveying message data from a source to a destination, the method comprising: transmitting message data independently of an operating system of a communication apparatus, said transmitting being performed at least in part by an operating system independent access layer; and transferring message data independently of hardware of the apparatus, said transferring being performed at least in part by a device independent access layer.
  • the present invention further provides a communication apparatus for transferring message data from a source to a destination, the apparatus comprising: an operating system portion of the apparatus processing internal communications within said apparatus independently of an operating system of said apparatus; and a hardware portion of the apparatus processing external communications to and from said apparatus independently of hardware devices in said apparatus.
  • the present invention further provides a computer storage medium having stored thereon a set of instructions implementing a method for conveying message data from a source to a destination, said set of instructions comprising one or more instructions for: transmitting message data independently of an operating system of a communication apparatus, said transmitting being performed at least in part by an operating system independent access layer; and transferring message data independently of hardware of the apparatus, said transferring being performed at least in part by a device independent access layer.
  • Interprocess communication refers to an exchange of data between one process and another, either within the same computer or over a network.
  • IPC implies a protocol that guarantees a response to a request. IPC can be performed automatically by programs.
  • Fig. 1 shows logically-arranged functional blocks of software, in accordance with the principles of the present invention.
  • Fig. 1 shows Enhanced Services 110, Connection Management 112, Common Agent 114, Common OAM (operation, administration, and maintenance) 116, Unified Inter Process Communication (UIPC) 118, Device Independent Access (DIA) Layer 120, Device Drivers 122, Real Time Operating System 124, Hardware 126, Operating System Independent Access (OIA) Layer 128, Asynchronous Transfer Mode (ATM) 130, Synchronous Digital Hierarchy (SDH) and plesiochronous digital hierarchy (PDH) 132, Voice over Packet (VoP) 134, Integrated Digital Loop Carrier (IDLC) 136, narrow band (NB) Subscriber 138, broad band (BB) Subscriber 140, and Internet Protocol (IP) 142.
  • UIPC Unified Inter Process Communication
  • DIA Device Independent Access
  • DIA Device Independent Access
  • OIA Operating System Independent Access
  • ATM Asynchronous Transfer Mode
  • SDH Synchronous Digital Hierarchy
  • Fig 1 shows some items arranged in a horizontal direction, and shows other items arranged in a vertical direction.
  • the horizontal direction shall be discussed first.
  • Common items of the equipment such as enhanced services, connection management, common agent, common OAM (operation, administration, and maintenance), unified interprocess communication (UIPC), and real time operating system (RTOS), and others, are shown to be arranged in the horizontal direction.
  • UIPC operation, administration, and maintenance
  • RTOS real time operating system
  • ATM asynchronous transfer mode
  • SDH synchronous digital hierarchy
  • PDH plesiochronous digital hierarchy
  • VoP voice over packet
  • IDLC integrated digital loop carrier
  • NB narrow band
  • BB broad band subscriber
  • IP Internet protocol
  • the present invention is related to the unified interprocess communication (UIPC) which communicates with both internal portions of the unit of the system and external communication system.
  • UIPC unified interprocess communication
  • the internal communication of the system is processed in operating system portions of the UIPC, and the external communication of the system is processed in the portions including the hardware portion of the UIPC.
  • An operating system independent access layer processes communication functions regardless of the type of the operating system.
  • a device independent access layer (DIA) is included in the present invention.
  • the UIPC includes application program interface (API) and protocol stack which is described below.
  • Fig. 2 is a network between a system controller and each shelf for message exchanges, in accordance with the principles of the present invention.
  • Fig. 2 shows a supported network topology, including Element Management System 210, System Controller 212 with card 213, Shelf 2 (214) with card 215, Smart Device 216, Shelf 3 (218) with card 219, and Shelf 4 (220) with card 221.
  • shelf 4 (220) in order for shelf 4 (220) to communicate with the system controller 212, although the communication between shelf 4 (220) and the system controller 212 physically passes through shelf 3 (218), there exists a conceptional direct path between shelf 4 (220) and the system controller 212 constructed according to the principles of the present invention.
  • the flexibility of the present invention is shown when the present invention is used in the inter communication between shelves regardless of the type of bus topology.
  • the present invention can be used in the inter communication between shelves in a shared bus type of topology (Fig. 3) and in a star bus type of topology (Fig. 4).
  • Fig. 3 shows a shared bus topology constructed in accordance with the principles of the present invention.
  • Fig. 4 shows a star bus topology for intershelf messages, in accordance with the principles of the present invention.
  • Fig. 5 is a client application sending message to a service location, in accordance with the principles of the present invention.
  • Application IDs there are shown application IDs of software used to delete and add the software depending on a system user.
  • UIPC Network Address the network address is shown to be used to get a message to processors or entities that can route messages.
  • UIPC Unified Interprocess Communication
  • the term “API” refers to Application Program Interface
  • the term “EMS” refers to Element Management System
  • the term “hop” refers to one path in the transmission of a message over consecutive paths
  • the term “link” refers to the connection between two physical endpoints
  • the term “NE” refers to Network Element
  • the term “network element” refers to a unit that is separately managed by the element management system (a network element may consist of one or more local or geographically distributed shelves)
  • the term “node” refers to any element of the UIPC communication network that is separately addressable
  • the term “smart endpoint” refers to a device attached to a card that can receive messages (an example of such a device is a DSL modem).
  • UIPC Unified Interprocess Communication
  • OIA Operating System Independent Adaption layer
  • DIA Device Independent Adaptation layer
  • DSL Digital Subscriber Line
  • IADs Integrated Access Devices
  • RTOS Real Time Operating System
  • TCP/IP Transport Control Protocol over Internet Protocol
  • the UIPC component of the present invention is intended to be used for all intraprocessor and interprocessor communications between applications.
  • This section includes a description of the network element topologies supported by the present invention, a basic description of the addressing used by the present invention, and a description of application models supported by the UIPC of the present invention.
  • the UIPC provides bi-directional messaging between tasks anywhere within a network element.
  • the UIPC allows applications to send messages asynchronously.
  • the application program interface (API) will return immediately without blocking.
  • the UIPC allows applications to send messages and synchronously wait for a response with a timeout.
  • the UIPC abstracts the underlying physical transport mechanism. An application needing to communicate with a service is required to know the location of that service. Service applications are described in the section hereinbelow entitled Application Types: Services.
  • the UIPC provides a mechanism whereby messages can be broadcast.
  • Low-level UIPC protocols are able to be changed without changing upper layer protocols.
  • Upper-level UIPC protocols are able to be changed without changing lower layer protocols.
  • the UIPC detects transmission errors and retries errored packets on a link-by-link basis (this implies that the link-layer of the protocol, which handles each link, is required to cause that link to be reliable).
  • the same UIPC application program interface (API) is used for intraprocessor and interprocessor communication.
  • the UIPC performs fragmentation and reassembly of large messages.
  • the UIPC allows end-to-end connection-oriented and connectionless communication.
  • the UIPC provides a mechanism to enable debug output.
  • UIPC Protocol parameters are settable at run-time.
  • the UIPC provides a mechanism to set the maximum transmission unit for each link.
  • the UIPC accommodates hops with varying maximum transmission units.
  • the UIPC supports message priority for real-time critical messages.
  • the UIPC is operating system independent.
  • the UIPC allows messages to be passed transparently from a controller to devices attached to cards (these devices may or may not speak the UIPC protocol).
  • the UIPC allows messages to be routed from any shelf to any other shelf within a network element.
  • the UIPC provides an application program interface (API) for the reporting of protocol errors and statistics.
  • API application program interface
  • the characteristics of real-time system design are taken into consideration for the present invention.
  • the relevant characteristics of real-time system design are as follows.
  • processor or communications bandwidth may be limited. This implies the need for efficiency. Processing of messages should be minimal. Protocol overhead should be minimized. There is a tradeoff between functionality and efficiency. A protocol stack like TCP/IP is feature rich, but carries a lot of overhead to implement these features. A protocol tailored to a real-time system is likely to minimize the protocol overhead for the sake of efficiency and be optimized for the most common type of messaging. This means features may be limited. The few applications that need additional features may have to participate in supplying any additional functionality rather than depending on the protocol stack to supply the needed features.
  • RTOSs real time operating systems
  • ISRs interrupt service routines
  • RTOSs real time operating systems
  • Some real time operating systems (RTOSs) may provide a protected memory model that limits the memory that any task can access. Communication between tasks in such a model relies on message passing or the use of shared memory.
  • the memory model does not affect the application program interface (API) or protocol definitions presented in this specification. However, it does affect the implementation of these components. Where implementation suggestions are made, this specification will assume the more common flat memory model.
  • Network elements represent separately managed pieces of equipment.
  • a network element may consist of one or more local or geographically distributed shelves.
  • the manner in which a network element is distributed is called the network element topology.
  • the topology that the UIPC of the present invention supports is a tree structure. There may be a main system controller shelf connected to multiple other shelves.
  • Any shelves that are subtended off of other shelves may or may not have a direct hardware connected communication path to the system controller.
  • Software routing functionality is provided for communication between any shelves. It is independent of network topology. There are twokinds of routing mechanisms; one is static routing and the other is dynamic routing.
  • each shelf has cards. Cards may have smart devices attached to them that may or may not communicate via the UIPC protocol. These cards and devices can be viewed as branches or leaves in the tree structure.
  • Fig. 2 is a network between a system controller and each shelf for message exchanges, in accordance with the principles of the present invention.
  • Fig. 2 shows a supported network topology, including Element Management System 210, System Controller 212 with card 213, Shelf 2 (214) with card 215, Smart Device 216, Shelf 3 (218) with card 219, and Shelf 4 (220) with card 221.
  • Fig. 2 shows the network topology for which the UIPC of the present invention is designed.
  • the UIPC of the present invention supports message exchanges between tasks on individual cards, between tasks on different cards on the same shelf, between tasks on any shelf, and also between tasks on any shelf and attached smart devices (for example, digital subscriber line modems and integrated access devices).
  • IP Internet protocol
  • the element management system 210 can also communicate via UIPC. Messages can be routed between the element management system 210 and any card on any shelf.
  • An element management system (EMS) 210 can look just like any other shelf as far as the UIPC is concerned.
  • the above-described network topology defines the system of the present invention from an external point of view. Now a bus topology shall be described.
  • the bus topology describes a shelf of the present invention from an internal point of view.
  • the design of the bus topology affects how messages flow through and between cards on a shelf.
  • Bus topologies are either a shared bus type (Fig. 3) or a star bus type (Fig. 4).
  • each card In the shared bus type topology, it may be possible for any card to communicate with any other card. However, some shared bus designs only allow cards to talk to a single master. In a star bus type topology, each card connects to a central hub.
  • Fig. 3 shows a shared bus topology constructed in accordance with the principles of the present invention.
  • Fig. 3 depicts shelf 310 having card 1 (312), card 2 (314), card 3 (316), card 4 (318), and card 5 (320).
  • the shelf 310 includes a card 1 (312) that has an external connection to another shelf (other than shelf 310). Messages to and from that other shelf are routed by card 1 (312) as is shown in a message that is being transmitted by card 4 (318).
  • Fig. 3 also shows two possible choices for routing messages between cards.
  • messages can be sent directly between cards if those cards know each other's address. This is shown between cards 4 (318) and 5 (320). It is the most efficient means of getting a message between cards.
  • the implementation may choose to route all intercard messages through a central router 312 as shown in the message transmitted from card 2 (314) to card 3 (316). This method would also be used for shared buses that require all messages to go through a master.
  • the UIPC described later includes a routing mechanism for each card and for the shelf that can accommodate both direct card-to-card and centralized routing. It only depends on how each card's routing table is populated.
  • Fig. 4 shows a star bus topology for intershelf messages, in accordance with the principles of the present invention.
  • Fig. 4 depicts shelf 410 having card 1 (412), card 2 (414), card 3 (416), card 4 (418), and card 5 (420).
  • all messages pass through a central router 412.
  • an application is implemented as a task. All may need to use the UIPC. Some applications do not generally interact with other applications. These are called stand-alone applications. Other applications provide services that are available to other applications. These are called services. Any application that interacts with a service is called a client. Some client applications may also be services themselves. In addition to application types, it is likely that some sort of parent/child relationship exists for each task. Even a stand-alone task will have some task that created it (that is, its parent). Parents may need to communicate with their children for maintenance purposes. For example, a parent task may want to ping its child to make sure that it is functioning properly. Described below are three application types (services, clients, and stand-alone), and also sample client/server message flows between applications.
  • the first application type is a service.
  • a service is implemented to perform particular tasks such as controlling access to common resources for other applications (clients). To a client it does not matter how or on which card, and possibly which shelf the service is implemented.
  • the use of services as an abstraction allows client tasks to use services regardless of where that service is located. This design is resilient to change since it allows the division of labor among services, cards, or shelves to change without affecting client applications. Only in some cases would an application need to talk to a specific card on another node.
  • Services register themselves with the UIPC using a well-known application ID.
  • An application ID is analogous to a transmission control protocol (TCP) port number that is used when opening a socket connection to a server.
  • TCP transmission control protocol
  • the client must also specify a network address if it needs to talk to a service on a specific unit of hardware such as a shelf or a particular card on a shelf.
  • Examples of well known services might be an OAM (operation, administration, and maintenance) task that handles OAM-related requests, or an alarm manager task that is responsible for receiving alarms.
  • the second application type is a client.
  • Clients are any applications that talk to services.
  • a service that talks to another service is considered to be a client of that other service.
  • Clients that are not also services do not have a well-known application ID.
  • the UIPC will assign an application ID to a client's message queue so that responses can be routed to the client.
  • the third application type is a stand-alone.
  • Stand-alone applications are those that do not talk to other applications. Like clients, stand-alone applications do not have well known application IDs.
  • UIPC contains a routing mechanism to determine where messages should be sent.
  • Each card in the system has a routing function.
  • Each shelf also has a routing function that distributes messages between cards or shelves.
  • Fig. 5 To demonstrate the most complex routing that the UIPC supports, refer now to Fig. 5.
  • Fig. 5 is a client application sending message to a service location, in accordance with the principles of the present invention.
  • Fig. 5 depicts system controller shelf 510 and a shelf 516.
  • the system controller shelf 510 has shelf controller 512 and a card 516.
  • the shelf 516 has shelf controller 522 and a card 526.
  • the card 526 has a client application 530 which can be any task 530.
  • the card 526 has UIPC 528.
  • the shelf controller 522 has UIPC 524.
  • the card 516 has Service X 520 and UIPC 518.
  • the shelf controller 512 has UIPC 514.
  • Fig. 5 depicts a client application 530 sending a message to Service X 520.
  • the client application 530 is represented by any task 530.
  • Service X 520 is implemented on the system controller shelf 510, and the client is implemented on some other shelf 516.
  • the client requests the UIPC 528 to send a message to Service X 520 with network address of the system controler 510.
  • the UIPC 528 on the client's card 526 will forward the message to the shelf router.
  • the shelf router looks up the destination network address. If it is not same as my network address, it will route the message to the system controller 510.
  • the shelf router on the system controller 510 looks up the destination network address and determines that it is implemented on a card 516 in the shelf 510.
  • the message is sent to that card 516.
  • the UIPC 518 on that card 516 then routes the message to the Service X task 520.
  • the maximum number of application IDs available within a card is UIPC_MAX_APP_ID.
  • the maximum number of application IDs available within a card is as allowed by operating system independent access layer (OIA), which corresponds to the maximum number of interprocess communication (IPC) queues that are allowed.
  • OIA operating system independent access layer
  • Well-known application IDs are chosen by the application from a range of application IDs bounded by UIPC_MAX_WELL_KNOWN_APP, which is the first half of the values of UIPC_MAX_APP_ID. It is like well-known port numbers used with transmission control protocol (TCP). Application in this context is defined as anything outside of UIPC. This includes the common operation, administration, and maintenance (OAM) components as well as other applications.
  • OAM operation, administration, and maintenance
  • application IDs are alloted from the other upper half of the values of UIPC_MAX_APP_ID. This range is UIPC_DYN_APP_ID_START (UIPC_MAX_WELL_KNOWN_APP + 1) to UIPC_MAX_APP_ID.
  • UIPC_DYN_APP_ID_START UIPC_MAX_WELL_KNOWN_APP + 1
  • UIPC_MAX_APP_ID are assigned when the task wants to either send or receive messages, and are freed once the task has finished with either sending or receiving messages. When these application IDs are freed, they can be reused.
  • a network address is used to get a message to processors or entities that can route messages.
  • each card, shelf, rack, or smart endpoint has a unique network address.
  • Shelves may also be organized into racks that may also have a unique network address.
  • Application IDs are also contained within messages to tell the router which application should receive the message. Put more simply, network addresses get a message to a card, and application IDs get messages to tasks on a card.
  • a network address must be capable of referring to a rack, shelf, card, or smart endpoint attached to a card.
  • a 32-bit address is defined that is divided into four classes of address, A, B, C, and D. This is similar to Internet protocol (IP) addressing which has 4 classes. Each class consists of 8 bits. Class A represents a rack. Class B represents the address of a shelf in a network element. Class C addresses represent cards. Class D addresses represent smart endpoints. This scheme will allow 256 separate devices on each network or subnetwork. The use of classes of addresses allows routers to mask off fields that they don't care about. This simplifies the routing tables. For example, a message might be destined for a particular device attached to a card.
  • the shelf router can ignore the class D portion of the address since all it needs to know is how to get the message to the card. It does not need any entries in its routing table for devices attached to cards. Likewise, the router on the card can ignore the class A and B portion of the address since all it needs to know is how to get the message to the device.
  • Special address values are also defined to allow for circumstances where specific addresses are not known or shouldn't be used. For example, an application on one card may need to communicate with a service that it knows is located on the shelf, but does not know where that service is implemented. Special addresses can also be used where routers are dynamically assigned addresses.
  • a network layer control message to an unassigned router (for example, a card) may contain a special kind of address and carry information that allows the unassigned router to take on a new address. Any protocol layer could also use special addresses when communicating protocol control messages. Broadcast of messages is also supported through special addresses.
  • Routers should process them starting at the class A address all the way down to the class D address to determine how to route a message.
  • the first special value that shall be described is the Any Place value.
  • the Any Place value is 0xFF.
  • the message is directed towards a service that may be on any card (class C portion is this value) or any shelf (class B portion is this value).
  • class C portion is this value
  • class B portion is this value
  • the message is directed towards a service that may be on any card
  • the class B portion of the address has the value 0xFF then the message is directed towards a service that may be on any shelf.
  • a router sees this address as a class value, it should pass the message to the transport layer.
  • the transport layer will determine if a service has registered to receive messages with the application ID in the message.
  • the second special value that shall be described is the This Place value.
  • the This Place value is 0xFE. If a class of an address has the This Place value, it indicates that the message is terminated on the router receiving the message or on a lower class address if the lower class address(es) do not contain the Ignore (0xFD) value.
  • the third special value that shall be described is the Ignore value.
  • the Ignore value is 0xFD. If a class has the Ignore value, the address should be terminated on the highest-class router that does not have an 0xFD value.
  • the Ignore value is used when directing messages to specific shelves or cards.
  • the Ignore value is used in router addresses for class B and C routers. A class B router would have an address like 0xXXXXFDFD and a class C router would have an address like 0xXXXXXXFD. Note also that the card on which the shelf router is located could also have its own address, just like any other card.
  • the fourth special value that shall be described is the Broadcast value.
  • the Broadcast value is 0xFC.
  • a router receiving an address that contains the Broadcast value should broadcast the message to all addresses in its routing table that match the class where 0xFC appears. For example, a shelf receiving a message with 0xXXXXFCFD would send messages to each of the cards. A value of 0xXXXXFCFC would cause each card to send the message and forward it to all class D devices.
  • the fifth special value that shall be described is the System Controller value.
  • the System Controller value is 0xFB.
  • the System Controller value applies only to the class B address.
  • the System Controller value is used if a message is sent specifically to the system controller shelf.
  • Application sends a message to a service somewhere on this shelf: 0xFEFEFFFD.
  • Application sends a message to a service on this card: 0xFEFEFEFD.
  • Application sends a message to a service that may be on any card of any shelf: 0xFFFFFFFD.
  • Application broadcasts a message to all cards in the system: 0xFCFCFCFD
  • the UIPC of the present invention is divided into two major sections, the application program interface (API) and the protocol stack.
  • the application program interface provides applications with a convenient means to send messages without having to know the details of the protocol or how the protocol is implemented. For the sake of clarity, suggested implementations are presented for an operating system that supports a flat memory model.
  • the UIPC of the present invention is intended to provide intertask communication both on and off processor across cards on the same shelf or across shelves.
  • the UIPC of the present invention is responsible for getting messages to their destinations. However, the content of the messages is the responsibility of the application. Therefore, the UIPC does not provide a mechanism to represent user data in a machine-independent format. This would be the responsibility of a presentation layer. Since the UIPC is intended to be used as a real-time protocol, the overhead associated with a presentation layer is not included.
  • the design of the UIPC component separates the application program interface from the protocol processing. This is done to allow efficient intraprocessor communication that does not require a protocol stack while allowing for interprocessor communication which does require a protocol stack.
  • the UIPC application program interface exists as a library that is called from the context of an application task. An application invokes the UIPC application program interface to send and receive messages.
  • the UIPC application program interface may communicate with the UIPC Protocol Task (also known as "UIPC task") for interprocessor messaging. It does so by sending messages to the UIPC Protocol Task's queue.
  • the application program interface is a shared library that can be used by any task.
  • the application program interface provides the interface to all external functionality provided by the UIPC.
  • the application program interface handles intraprocessor operations without going through the UIPC task. It does this by examining endpoint handles that are passed in to see if they represent on or off processor endpoints. If it is on processor, a message is sent by invoking the operating system independent access layer (OIA) messaging application program interfaces directly to a message queue pointed to by the endpoint. If it is off processor, it sends a message to the UIPC protocol task's message queue.
  • OIA operating system independent access layer
  • Uipc_InitCardContext() is called to initialize the UIPC of the present invention.
  • the Global table contains the information about all the tasks in a particular card. Each entry in the Global table is a task control block (TCB). Each task control block will have task specific information.
  • TBC task control block
  • the first field of the task control block is the Task ID.
  • the second field in the task control block is the Application ID. This will be the Application ID of the Main Queue of the Task.
  • Each task will have a dynamic message handler table, static message handler table, and dynamic message class table.
  • Uipc_RegisterOneTimeApi() an entry will be made in the dynamic message handler table of the task.
  • the entries in this dynamic message handler table will not be permanent. The entry will be deleted as soon as the response of the one time application program interface has arrived.
  • the dynamic message handler table will be implemented using balanced binary trees.
  • Uipc_RegisterMsgHandler() an entry will be made in the static message handler table.
  • the static message handler table is dedicated for observer application program interfaces. Unlike the dynamic message handler table, the entries in the static message handler table will be permanent.
  • the static message handler table will be implemented using arrays.
  • a message class will be returned to the task, and in the dynamic message class table the necessary updating will be done such that the particular message class is busy.
  • the UIPC will make necessary modification in the dynamic message class table so that the particular message class can be used in future.
  • the dynamic message class table will also be implemented as an array.
  • the Global table contains pointers to all the above-mentioned tables. In addition to this, the Global table also contains pointer to the Idle Message Handler function of the task.
  • the Global table will also contain wait time that has to be used within Uipc_RcvLoop() for each tasks. Each time within the Uipc_RcvLoop() application program interface, the global table will be queried for the wait time. Since the global table will be accessed by all the tasks, a semaphore will protect the global table. This semaphore will be created during Uipc_InitCardContext().
  • Each task has to implement this dynamic message handler table.
  • This table is dedicated to one time application program interfaces (APIs).
  • APIs application program interfaces
  • the dynamic message handler table has three fields in it. The first field is the message class, the second field is the callback function pointer, and the third field is the timer handle.
  • Uipc_RegisterOneTimeApi() an entry will be made in the dynamic message handler table of the task.
  • the table will be looked up with the message class to find the corresponding callback function. After invoking the callback function, the entry will be deleted from the dynamic message handler table of the task.
  • the entries in the dynamic message handler table will not be permanent.
  • the UIPC private application program interface Uipc_DeleteMsgHndlrTableEntry() will be invoked for deleting an entry from the dynamic message handler table.
  • the entry will be deleted as soon as the response of the one time application program interface has arrived. Even if a timeout condition occurs (if the response does not reach within a specified time), the entry in the dynamic message handler table will be deleted.
  • the above layer will be informed about the message arrival or timeout through the UIPC Control Data.
  • the dynamic message handler table will be implemented using balanced binary trees.
  • Each task has to implement a static message handler table.
  • the static message handler table is dedicated for observer application program interfaces. Whenever a message arrives with the message direction, as UIPC_MSG_REP or UIPC_MSG_REQ, the table will be looked up with the message class to find the corresponding callback function. The callback function will be invoked if the entry is found. Unlike the dynamic message handler table, the entries in the static message handler table will be permanent. The static message handler table will be implemented using arrays. There is no need for semaphore to protect this table, as each table will have its own static message handler table.
  • Each task has to implement a dynamic message class table.
  • Uipc_GenerateTempMsgClass() a free message class within the dynamic message class range (UIPC_DYN_MSG_CLASS_START to UIPC_MAX_NO_DYN_MSG_CLASS) will be given to the task. If no free message class is available, the unavailability will be reported to the application program interface user. After allocating a free message class the table will be updated such that the particular message class is made busy.
  • Uipc_FreeTempMsgClass() the message class will be freed so that the particular message class can be used in future. There is no need for semaphore to protect this table, as each table will have its own dynamic message class table.
  • the UIPC application program interface may communicate with the UIPC Protocol Task (also known as "UIPC task") for interprocessor messaging. It does so by sending messages to the UIPC Protocol Task's queue.
  • a UIPC Routing Library is also shown.
  • the UIPC Routing Library allows either the UIPC application program interface or UIPC Protocol Task to determine how to route messages. This is based on the application ID and network address. For intraprocessor communication, it would be inefficient for all messages to pass through the UIPC Protocol Task. Therefore, the UIPC application program interface first invokes the routing library to see if a message can be sent directly to a task's queue on the same processor. If not, the UIPC application program interface will forward the message to the UIPC Protocol Task. The UIPC Protocol Task will pass the messages through the protocol stack. At the network layer of the stack, the routing application program interface will again be invoked to determine on which physical link the message should be sent.
  • the UIPC Task may consist of subtasks. This is dependent on the implementation of the protocol stack layers. However, from the point of view of the UIPC application program interface, it only needs to know about and communicate with a single UIPC Protocol Task. What happens after the UIPC application program interface passes a message to the UIPC Task is hidden.
  • Routing is the responsibility of both the transport and network layers of the protocol.
  • the network layer determines which physical link a message should be sent to.
  • the network layer makes that determination based on the network address.
  • the transport layer determines which application a message should be sent to.
  • the transport layer makes that determination based on both the application ID and network address. It depends on the implementation how these routing tables are implemented.
  • the routing tables for network and transport layers may be kept separate so as to decouple the two layers. However, from the point of view of functions external to the Protocol Task (for example, the UIPC application program interface), certain routing functions are required regardless of how the stack is implemented. Therefore the Routing Library is shown as a separate entity. In reality, it may simply provide a thin application program interface on top of functions exposed by the network and transport layers.
  • Open systems interconnect (OSI) stack model is used to define the layers of functionality that exist in a communications protocol.
  • Open systems interconnect (OSI) is a model of network architecture and a suite of protocols to implement it.
  • the suite of protocols can be referred to as a protocol stack.
  • the OSI architecture is split between seven layers, from lowest to highest: (i) physical layer, (ii) data link layer, (iii) network layer, (iv) transport layer, (v) session layer, (vi) presentation layer, and (vii) application layer.
  • the UIPC stack model of the present invention follows the open systems interconnect (OSI) definition, but does not necessarily include all seven layers specified by open systems interconnect (OSI).
  • OSI open systems interconnect
  • the UIPC protocol is tailored towards a real-time system and does not require the functions of all of the open systems interconnect (OSI) layers.
  • the header for each layer should contain a protocol discriminator.
  • the discriminator indicates which protocol or combination of protocols is being carried in the message. It is typically two or three bits inside the header. This allows different protocols to be implemented in the future without changing the other protocols. For example, an incoming message being processed by the network layer would have a protocol discriminator in the network layer header that indicated which protocol module should be the next to process the message. If the UIPC were to support transport layer protocols such as transmission control protocol (TCP) or user datagram protocol (UDP), the protocol discriminator would tell the network layer whether to pass on the message to the transmission control protocol or the user datagram protocol module.
  • TCP transmission control protocol
  • UDP user datagram protocol
  • User datagram protocol refers to Internet standard network layer, transport layer, and session layer protocols which provide datagram services. User datagram protocol is a connectionless protocol which, like TCP, is layered on top of Internet protocol (IP).
  • LAPD link layer protocol that depends on a physical high level data link control (HDLC) layer.
  • HDLC physical high level data link control
  • Each layer shall preserve message priority.
  • High priority messages or segments in the case of long messages that need to be segmented
  • Each layer should provide flags to allow the protocol at that layer to be extended in the future.
  • An example of how this might be used is for the network layer to reserve a special flag value to allow extended addressing.
  • Each layer may define special control messages that are exchanged between the same layers at endpoints. These control messages may allow either side to negotiate protocol parameters or perform flow control.
  • Each section also includes a list of primitives that the layer should provide.
  • the primitives are intended to show the external interface provided to other software (that is, the next protocol layer up). They do not describe the actual messages that are passed between two endpoints. The definition of such messages and any associated state machines are not described here. They are to be defined when the detailed design is performed.
  • the primitives are named using International Telecommunications Union (ITU) terminology and are categorized as Request, Response, Indication, and Confirm.
  • ITU International Telecommunications Union
  • Indication This is a notification that an event has occurred. It is intended that the next layer up or the code that created a later receives these indications. Most indications are a result of the far end initiating some action via a request.
  • Each primitive has primitive-specific data associated with it.
  • the mechanism for passing primitives between layers is not specified here as it is part of the detailed design of the layers.
  • a maximum transmission unit defines the maximum message size. Any messages that are under this size are transmitted as a single message. Thus high priority time-critical messages can be processed in no longer than the time it takes to transmit two messages of maximum transmission unit length (one time period for the message being transmitted, and one more time period for the high priority message to be transmitted). To guarantee that this is the case, there is a 1-to-1 correspondence between a network layer message, a link layer message, and a physical layer (for example, high level data link control) frame. Tying messages together at these levels is needed to help guarantee real-time performance.
  • Determining the maximum transmission unit is part of the application design. As such, it is not defined as part of the UIPC. However, the UIPC does define an internal application program interface (API) that is visible only to the UIPC component to set the maximum transmission unit. The maximum transmission unit is determined by the application performance requirements, the number of hops a message is expected to take, and the speed of the communication links being used.
  • API application program interface
  • the network layer has a message segmentation function. This should be utilized to segment larger MTUs into smaller MTUs. If the network layer were not to do this at each node, the alternative would be to establish an end-to-end connection and negotiate, through all the nodes, what the maximum MTU should be. However, this method incurs overhead and will not work for connectionless messages.
  • the link layer is responsible for establishing data links between endpoints and ensuring error-free transmission of data between those endpoints. See the aforementioned document "Open Systems Interconnection, Data Link Service Definition, ITU-T X.212.” Depending on the network topology, there may be multiple channels on which the link layer must communicate or messages may be broadcast on a single shared bus. The link layer ensures point-to-point delivery of messages, and can request retransmission of lost or out-of-sequence messages.
  • Link access procedure on the D channel (LAPD) is a good choice for this layer in systems with point-to-point links or a star communication bus architecture.
  • Link access procedure on the D channel (LAPD) uses high level data link control to frame messages, perform error detection, and address physical endpoints.
  • High level data link control alone can be considered a link layer protocol. However, it does not guarantee message delivery via retries. It only guarantees messages are error free. Note that link access procedure on the D channel (LAPD) does not include a mechanism for message priority. It would therefore need to be modified to prioritize messages.
  • LAPD link access procedure on the D channel
  • the link layer has the following responsibilities: (i) If the link layer is stateful, it may need to provide queuing of outgoing messages. (ii) If any flow control is needed, it is the responsibility of the link layer. This simplifies the implementation of the upper layer protocols. (iii) Ensure that data is error-free. (iv) If connection-oriented links are desired, establish and maintain links. The term "connection-oriented" in the preceding sentence should not be confused with end-to-end connection-oriented service which is provided by the transport layer. (v) If the physical link is not reliable, retry errored messages.
  • Table 1 For connection-oriented data links, Table 1 contains the minimally required primitives. Note that the primitives are broken down into categories according to whether a link is established or not.
  • Table 2 contains primitives for connectionless service. These tables were derived from the aforementioned document "Open Systems Interconnection, Data Link Service Definition, ITU-T X.212.” Following the tables are definitions for the parameters that accompany the primitives.
  • Linkestabli shment DL-CONNECT request (Initiate a connection with the far end or a physical channel) (channel ID, near end address, far end address, MTU size)
  • DL-CONNECT indication (Received when far-end has initiated a connection to you)
  • DL-CONNECT response (Invoked by the receiver of a DL-CONNECT indication to accept the connection) (channel ID, near end address, far end address)
  • DL-CONNECT confirm Tells the side that initiated the connection that the far end has accepted the connection) (channel ID, near end address, far end address)
  • Normal datatransfe r DL-DATA request (Sender uses this to send data) (channel ID, far end address, protocol descriptor, user-data, priority) DL-DATA indication (Receiver gets this when data is received) (channel ID, far end address, protocol descriptor
  • DL-DISCONNECT indication (Received when the far end has disconnected) (channel ID, far end address , Originator, reason) Summary of data-link-connectionless-mode primitives and parameters Service Primitive Parameters Normal datatransfe r DL-DATA request (Sender uses this to send data) (channel ID, far end address, protocol descriptor, user-data, priority) DL-DATA indication (Receiver gets this when data is received) (channel ID, far end address, protocol descriptor, user-data, priority)
  • channel ID refers to an identifier to tell the data link layer which physical channel is being used.
  • user data refers to the data that is transmitted. It is transparent to the data link layer.
  • far end address refers to the address of the other end of the link. This is optional and is used only if multiple data links are established on the same physical channel. For multipoint bus architectures, there should be a special address that is available for broadcast.
  • near end address refers to the address to use in the message for any responses the far-end may send.
  • MTU size refers to the maximum transmission unit size. This indicates the largest DLS user data packet that can be transmitted across the link.
  • near end address refers to the address assigned to the near end for the data link. This is optional and is used only if multiple data links are established on the same physical channel.
  • the term “Originator” refers to indicates if the action was originated by the user of the data link layer or the data link layer itself.
  • the term “priority” refers to indicates the priority of the DLS user data.
  • the term “protocol descriptor” refers to an identifier for what higher level protocol is carried in the user data.
  • Reason refers to a reason code for an action. This is implementation specific.
  • the network layer is responsible for getting messages between processors.
  • the network layer has the following characteristics.
  • the network layer routes messages based on network address.
  • the network layer examines the network address to determine whether a message is destined for the processor on which it was received or if the message needs to be forwarded across another interface to get to its final destination.
  • the network layer supports message segmentation/reassembly. Because different links may have different sized maximum transmission units (MTUs), combined with the fact that the network layer may route messages without passing them to the transport layer, the network layer also handles conversion between MTU sizes. This means message segmentation and reassembly is supported at this layer.
  • MTUs maximum transmission units
  • the network layer corresponds to stateless operation. Because the network layer does not provide reliable point-to-point or end-to-end message transmission, it is stateless. Once a message is sent, it is forgotten. Point-to-point reliability is the responsibility of the data link layer. End-to-end reliability, if necessary, is the responsibility of the transport layer.
  • the network layer must also support routing messages to devices attached to cards. It is possible that some of these devices communicate via UIPC. In this case, they would have class D addresses and messages would be routed to them just like they would be to any other address. If they do not speak UIPC, the network layer must implement a means whereby, the devices can have virtual addresses. In this case a proxy application would run on a card and register to receive messages for particular class D addresses. The proxy application would be responsible for receiving these messages and forwarding them to the devices. Additionally, these messages do not need to use the transport layer protocol since they are not destined for applications.
  • the primitives only loosely correspond to the International Telecommunications Union (ITU) definitions. See the aforementioned document "Open Systems Interconnection, Network Service Definition, ITU-T X.213.” This is because the International Telecommunications Union (ITU) uses a more complicated model than is needed for the UIPC. It models the network layer as a connection between two endpoints. A connection-oriented network layer over-complicates the network layer since the link layer already provides for this. The network layer of the UIPC is modeled more as a packet-based protocol like Internet protocol (IP) where connections are not needed. Additionally, the International Telecommunications Union (ITU) does not define any mechanism whereby network addresses are assigned. It assumes that this information is somehow available to the network layer. Therefore the UIPC defines additional address-related primitives so that the network layer has an interface to perform address assignment functions.
  • IP Internet protocol
  • the external interface to the network layer is shown in the primitives of Table 3. Summary of network layer primitives and parameters Service Primitive Parameters Normal datatransfer N-DATA request (Sender uses this to send data) (far end network address, protocol descriptor, user-data, priority) N-DATA indication (Receiver gets this when data is received) (far end network address, protocol descriptor, user-data, priority)
  • far end network address refers to address of the node to which an operation is directed.
  • priority refers to the priority of the user data.
  • protocol descriptor refers to an identifier for what higher level protocol is carried in the user data.
  • user data refers to the data that is transmitted. The user data is transparent to the network layer.
  • the primitives only loosely correspond to the International Telecommunications Union (ITU) definitions. See the aforementioned document "Open Systems Interconnection, Network Service Definition, ITU-T X.213.” This is because the International Telecommunications Union (ITU) uses a more complicated model than is needed for the UIPC. It models the network layer as a connection between two endpoints. A connection-oriented network layer over-complicates the network layer since the link layer already provides for this. The network layer of the UIPC is modeled more as a packet-based protocol like IP where connections are not needed. Additionally, the International Telecommunications Union (ITU) does not define any mechanism whereby network addresses are assigned. It assumes that this information is somehow available to the network layer. Therefore the UIPC defines additional address-related primitives so that the network layer has an interface to perform address assignment functions.
  • ITU International Telecommunications Union
  • the following information should be part of the network layer message header: Destination address, Source address, Network message type (may be some sort of network layer control or a user data message), Segmentation information (for messages that are segmented), Control (used for network layer control messages and to indicate type of message).
  • the transport layer is responsible for end-to-end communication between applications. It has the following characteristics:
  • the transport layer introduces the concept of an application ID. Applications may register themselves to receive messages destined for a particular application ID. This supports client/server applications. This layer will determine that the message should be routed to a task on this processor.
  • the data in the buffer will be received on the far end in a single read operation.
  • the buffer can be viewed as a message. This is in contrast to a streams-based approach where a read operation simply receives the bytes that happen to be available regardless of whether they were transmitted in a single or multiple write operations.
  • connectionless messaging Provides connectionless messaging.
  • the application and lower layers are relied on to assure reliable end-to-end transmission.
  • the connectionless messaging does not track whether the far end actually received a message and that the message is valid.
  • the lower layers already assure that messages are valid via CRC checks and that messages get retransmitted on a link-by-link basis.
  • connectionless operation can be used. Note however, that the transport layer does have a mechanism to reject partial messages where segments of a long message may have been dropped. Since this is easier to implement than connection-oriented messaging, it is suggested that this be implemented first.
  • connection-oriented messaging In this case, an end-to-end connection is established and maintained for the application. This would be similar in function to a transmission control protocol (TCP) socket.
  • TCP transmission control protocol
  • the low-level design to support both connectionless and connection-oriented messaging might include the use of two separate transport layer modules or a single module that implements both types of messaging.
  • the transport layer assembles messages based on the source address.
  • the transport layer In order to route messages to particular applications, the transport layer is responsible for building a routing table of application ID to real message queue ID mappings. Access to the routing table needs to be exposed via an internal application program interface (API) that is visible only to the UIPC component. This is needed so that an efficient query can be made by the UIPC application program interface functions to determine if a message should be routed on or off the processor.
  • API application program interface
  • connection establishment and release primitives apply only to connection-oriented mode.
  • T-CONNECT indication (Received when far-end has initiated a connection to an application) (far-end network address, far-end application ID, near end application ID)
  • T-CONNECT response (Invoked by recipient of T-CONNECT indication to accept the connection)
  • T-CONNECT confirm (Tells the side that initiated the connection that the connection is now made)
  • Normal datatransfe r T-DATA request (Sender uses this to send data)
  • T-DATA indication (Receiver gets this when data is received) (far-end network address, far-end application ID, near end application ID, protocol descriptor, user-data, priority)
  • Connection release (connectio n
  • application ID refers to an identifier for the application. This is used to distinguish individual services provided by a processor that may have a given network address. Applications may have well-known IDs whereby other applications can address them. An application ID is portable across processor boundaries. The application ID and network address together combine to make a unique address for an application.
  • far end network address refers to the address of the node to which an operation is directed.
  • near end network address refers to the address assigned to the near end.
  • Olinator indicates if the action was originated by the user of the transport layer or the transport layer itself.
  • priority indicates the priority of the user data.
  • protocol descriptor refers to an identifier for what higher level protocol is carried in the user data.
  • queue handle refers to the handle to the queue that is to receive messages directed towards a particular application ID.
  • a queue handle points to information regarding the application ID of the owner of the queue.
  • user data refers to the data that is transmitted. It is transparent to the transport layer.
  • the transport layer has primitives that do not correspond to the anything in the International Telecommunications Union (ITU) definitions. See the aforementioned document "Open Systems Interconnection, Transport Service Definition, ITU-T X.214.” This is because the International Telecommunications Union (ITU) does not have primitives for setting transport service access points (TSAPs). Transport service access points roughly correspond to application IDs.
  • the International Telecommunications Union (ITU) assumes that transport service access points are registered by some other means and the information is available to the transport layer. Instead, the UIPC transport layer has additional primitives to register the application IDs and build routing tables based on them.
  • Originating application ID Originating application ID
  • Terminating application ID Control (used for transport layer control messages and to indicate type of message).
  • the UIPC of the present invention does not include an application layer protocol.
  • Fig. 6 is a test methodology to verify the component functionality, in accordance with the principles of the present invention.
  • Fig. 6 shows black box testing.
  • Fig. 6 shows a possible configuration for testing, in accordance with the principles of the present invention. It relies on the operating system independent access layer (OIA) to abstract the operating system calls so that the test system can run on a workstation's operating system.
  • OIA operating system independent access layer
  • Task 1 (614), task 2 (616), and task 3 (618) represent applications that can drive the UIPC application program interfaces (APIs) 628 and 630.
  • the UIPC task 620 runs inside process 1.
  • the UIPC task 622 runs inside process 2.
  • the UIPC application program interfaces run on top of the operating system independent access (OIA) layers 632, 634 and are available to the tasks.
  • UIPC uses operating system independent access (OIA) layer for message queue functions.
  • OIA operating system independent access
  • DIA device independent access
  • These simulators might just use something like sockets. They might also allow error injection to verify the protocol handles errors. Since this is a test of the UIPC component and not device independent access (DIA) layer, the only thing the simulators need to be able to do is get messages between the two processes.
  • the Fig. 6 may be extended to include other processes to simulate different class routers.
  • tasks 1-3 can be programmed to run sequences of UIPC application program interfaces (APIs) and verify the results automatically. Other options include using scripts or allowing a user interface to execute commands. Regardless of how they drive the UIPC, it is done from a black box perspective. The tasks look to UIPC like any other tasks.
  • APIs application program interfaces
EP02009766A 2001-09-04 2002-04-30 Communication unifiée entre des processus Withdrawn EP1296238A3 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02019789A EP1296239A3 (fr) 2001-09-04 2002-09-04 Méthode et appareil pour la communication entre des processus

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US31630101P 2001-09-04 2001-09-04
US316301P 2001-09-04
US35187 2002-01-04
US10/035,187 US20030115358A1 (en) 2001-09-04 2002-01-04 Unified interprocess communication

Publications (2)

Publication Number Publication Date
EP1296238A2 true EP1296238A2 (fr) 2003-03-26
EP1296238A3 EP1296238A3 (fr) 2004-04-14

Family

ID=26711855

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02009766A Withdrawn EP1296238A3 (fr) 2001-09-04 2002-04-30 Communication unifiée entre des processus

Country Status (5)

Country Link
US (1) US20030115358A1 (fr)
EP (1) EP1296238A3 (fr)
JP (1) JP2003177930A (fr)
CN (1) CN1404264A (fr)
CA (1) CA2381016A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101202733B (zh) * 2006-12-12 2012-02-08 上海未来宽带技术及应用工程研究中心有限公司 基于事件分发的通信系统
EP2287739A3 (fr) * 2009-08-10 2012-05-30 Samsung Electronics Co., Ltd. Appareil et procédé de communication de données entre applications Internet

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7447735B2 (en) * 2003-07-01 2008-11-04 Motorola, Inc. Interprocessor communication protocol
US20050010925A1 (en) * 2003-07-10 2005-01-13 Charbel Khawand Interprocessor communication protocol with smart streaming port
US8065161B2 (en) 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
US9123077B2 (en) 2003-10-07 2015-09-01 Hospira, Inc. Medication management system
US7305446B2 (en) * 2003-11-03 2007-12-04 International Business Machines Corporation Method and system for processing ingress messages for a state based application associated with a network processor
JP4608416B2 (ja) * 2005-11-11 2011-01-12 株式会社日立ハイテクノロジーズ 制御装置および通信方法
US7751346B2 (en) * 2005-12-01 2010-07-06 Electronics And Telecommunications Research Institute Apparatus for searching TCP and UDP sockets
CN100392599C (zh) * 2006-01-10 2008-06-04 杭州东信灵通电子实业公司 通用进程间通信实现方法
CN100471180C (zh) * 2006-02-09 2009-03-18 华为技术有限公司 一种消息传递的方法、装置和系统
JP2010507176A (ja) 2006-10-16 2010-03-04 ホスピラ・インコーポレイテツド 複数のデバイス管理システムからの動態情報および構成情報を比較および利用するためのシステムおよび方法
US20090207167A1 (en) * 2008-02-18 2009-08-20 International Business Machines Corporation Method and System for Remote Three-Dimensional Stereo Image Display
JP5381242B2 (ja) * 2009-03-31 2014-01-08 富士通株式会社 マルチプロセッサシステム及び制御プログラム
US8271106B2 (en) 2009-04-17 2012-09-18 Hospira, Inc. System and method for configuring a rule set for medical event management and responses
US8750126B2 (en) * 2009-10-16 2014-06-10 Tekelec, Inc. Methods, systems, and computer readable media for multi-interface monitoring and correlation of diameter signaling information
US8958306B2 (en) * 2009-10-16 2015-02-17 Tekelec, Inc. Methods, systems, and computer readable media for providing diameter signaling router with integrated monitoring functionality
KR101640767B1 (ko) * 2010-02-09 2016-07-29 삼성전자주식회사 이종 수행 환경을 위한 네트워크 기반의 실시간 가상 현실 입출력 시스템 및 가상 현실 입출력 방법
IN2012CN07527A (fr) 2010-02-12 2015-08-07 Tekelec Inc
US8578050B2 (en) * 2010-02-12 2013-11-05 Tekelec, Inc. Methods, systems, and computer readable media for providing peer routing at a diameter node
JP5732550B2 (ja) 2011-03-03 2015-06-10 テケレック・インコーポレイテッドＴｅｋｅｌｅｃ， Ｉｎｃ． ダイアメータシグナリングメッセージを強化するための方法、システム、およびコンピュータ可読媒体
CN109614244B (zh) 2011-09-12 2023-10-13 英特尔公司 应用和web服务之间元数据驱动的合作
WO2013059615A1 (fr) 2011-10-21 2013-04-25 Hospira, Inc. Système de mise à jour de dispositif médical
CN104350711B (zh) 2012-06-11 2018-11-06 泰科来股份有限公司 用于在diameter信令路由器处路由diameter消息的方法、系统及装置
EP2964079B1 (fr) 2013-03-06 2022-02-16 ICU Medical, Inc. Procédé de communication de dispositif médical
US9973596B2 (en) * 2013-06-19 2018-05-15 Cisco Technology, Inc. Dynamically adjusting frame MTU to support low-latency communication
JP6192388B2 (ja) * 2013-07-04 2017-09-06 三菱電機株式会社 光伝送システム
CN103414582B (zh) * 2013-07-26 2016-09-28 北京星网锐捷网络技术有限公司 主备用进程间的同步方法、装置及网络设备
CA2922425C (fr) 2013-08-30 2023-05-16 Hospira, Inc. Systeme et procede de surveillance et de gestion d'un regime de perfusion a distance
US9662436B2 (en) 2013-09-20 2017-05-30 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
EP3071253B1 (fr) 2013-11-19 2019-05-22 ICU Medical, Inc. Système et procédé d'automatisation de pompe à perfusion
WO2015168427A1 (fr) 2014-04-30 2015-11-05 Hospira, Inc. Système de soins de patient ayant un transfert d'alarme conditionnel
US9724470B2 (en) 2014-06-16 2017-08-08 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US9539383B2 (en) 2014-09-15 2017-01-10 Hospira, Inc. System and method that matches delayed infusion auto-programs with manually entered infusion programs and analyzes differences therein
US9729454B2 (en) 2015-01-21 2017-08-08 Oracle International Corporation Methods, systems, and computer readable media for balancing diameter message traffic received over long-lived diameter connections
ES2845725T3 (es) 2015-05-26 2021-07-27 Icu Medical Inc Sistema y método de bomba de infusión con capacidad de fuente de editor de múltiples bibliotecas de fármacos
US10027577B2 (en) 2015-07-29 2018-07-17 Oracle International Corporation Methods, systems, and computer readable media for peer aware load distribution
TWI609272B (zh) * 2016-06-24 2017-12-21 阿貝爾環球國際有限公司 終端裝置及其終端作業系統與雲端裝置及其雲端作業系統
EP3484541A4 (fr) 2016-07-14 2020-03-25 ICU Medical, Inc. Sélection de trajet multi-communication et système de sécurité pour dispositif médical
CN109086144B (zh) 2017-06-14 2022-04-05 阿里巴巴集团控股有限公司 一种进程之间的通信方法和装置
WO2020018389A1 (fr) 2018-07-17 2020-01-23 Icu Medical, Inc. Systèmes et procédés pour faciliter la messagerie clinique dans un environnement de réseau
US10861592B2 (en) 2018-07-17 2020-12-08 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
US10741280B2 (en) 2018-07-17 2020-08-11 Icu Medical, Inc. Tagging pump messages with identifiers that facilitate restructuring
EP3824386B1 (fr) 2018-07-17 2024-02-21 ICU Medical, Inc. Mise à jour de bibliothèques de médicaments et de logiciel opérationnel de pompes à perfusion dans un environnement en réseau
EP3827337A4 (fr) 2018-07-26 2022-04-13 ICU Medical, Inc. Système de gestion de bibliothèque de médicaments
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
US10999202B2 (en) 2018-11-30 2021-05-04 Oracle International Corporation Methods, systems, and computer readable media for distributing Sigtran connections among signal transfer point (STP) message processors
CN112000386A (zh) * 2019-05-08 2020-11-27 北京奇虎科技有限公司 一种应用的实现方法和装置
US11576072B2 (en) 2020-09-21 2023-02-07 Oracle International Corporation Methods, systems, and computer-readable media for distributing S1 connections to mobility management entities (MMEs) and N2 connections to access and mobility management functions (AMFs)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0767563A2 (fr) * 1995-10-06 1997-04-09 Sun Microsystems, Inc. Méthode et appareil pour l'opération en multiprotocole dans un système client-serveur
US5682534A (en) * 1995-09-12 1997-10-28 International Business Machines Corporation Transparent local RPC optimization

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0501610B1 (fr) * 1991-02-25 1999-03-17 Hewlett-Packard Company Système d'ordinateur distribué orienté objet
JPH08212180A (ja) * 1995-02-08 1996-08-20 Oki Electric Ind Co Ltd プロセス間通信処理装置
US6718550B1 (en) * 1996-06-26 2004-04-06 Sun Microsystems, Inc. Method and apparatus for improving the performance of object invocation
JP2000067018A (ja) * 1998-08-19 2000-03-03 Nippon Telegr & Teleph Corp <Ntt> 高速オブジェクト間通信装置
JP2000151739A (ja) * 1998-11-17 2000-05-30 Digital Vision Laboratories:Kk 情報処理装置、分散処理装置およびネットワークシステム
JP2000242587A (ja) * 1999-02-24 2000-09-08 Pfu Ltd オブジェクト処理装置及びそのプログラム記憶媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5682534A (en) * 1995-09-12 1997-10-28 International Business Machines Corporation Transparent local RPC optimization
EP0767563A2 (fr) * 1995-10-06 1997-04-09 Sun Microsystems, Inc. Méthode et appareil pour l'opération en multiprotocole dans un système client-serveur

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"RPC: REMOTE PROCEDURE CALL PROTOCOL SPECIFICATION" INTERNET SPECIFICATION RFC, XX, XX, April 1988 (1988-04), pages 1-24, XP002915168 *
ANDREW D BIRRELL ET AL: "Implementing remote procedure calls" ACM TRANSACTIONS ON COMPUTER SYSTEMS, NEW YORK, NY, US, vol. 1, no. 2, 1 February 1984 (1984-02-01), pages 39-59, XP002074181 ISSN: 0734-2071 *
SCHILL A: "AKTUELLE STANDARDS UND NEUE TECHNOLOGIEN IN HETEROGENEN WORKSTATION-NETZEN DISTRIBUTED APPLICATION SUPPORT IN HETEROGENEOUS NETWORKS: STANDARDS AND TECHNOLOGICAL DEPLOYMENTS" IT + TI INFORMATIONSTECHNIK UND TECHNISCHE INFORMATIK, OLDENBOURG VERLAG. MUNCHEN, DE, vol. 37, no. 1, 1 February 1995 (1995-02-01), pages 38-45, XP000500774 ISSN: 0944-2774 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101202733B (zh) * 2006-12-12 2012-02-08 上海未来宽带技术及应用工程研究中心有限公司 基于事件分发的通信系统
EP2287739A3 (fr) * 2009-08-10 2012-05-30 Samsung Electronics Co., Ltd. Appareil et procédé de communication de données entre applications Internet
US9690636B2 (en) 2009-08-10 2017-06-27 Samsung Electronics Co., Ltd. Apparatus and method of data communication between web applications

Also Published As

Publication number Publication date
EP1296238A3 (fr) 2004-04-14
CN1404264A (zh) 2003-03-19
JP2003177930A (ja) 2003-06-27
CA2381016A1 (fr) 2003-03-04
US20030115358A1 (en) 2003-06-19

Similar Documents

Publication Publication Date Title
EP1296238A2 (fr) Communication unifiée entre des processus
EP0807358B1 (fr) Commutateur de telecommunications possedant une interface universelle de programme d&#39;application pour traitement standardise d&#39;appel interactif
US7839848B2 (en) Method, device and system for message transmission
US7447728B1 (en) Method and apparatus supporting network communications
EP0889624B1 (fr) Jonction de réseaux compatibles Ethernet
US4893307A (en) Method and apparatus for linking SNA terminals to an SNA host over a packet switched communications network
EP0604523B1 (fr) Emulateur de transmission pour reseau local
US5021949A (en) Method and apparatus for linking an SNA host to a remote SNA host over a packet switched communications network
EP0676878A1 (fr) Procédé efficient de routage point à point et point à multipoint pour des noeuds commutateurs de paquets dans un réseau de transmission de données à haute vitesse
US7263701B2 (en) Interprocess communication method and apparatus
Wecker DNA: the digital network architecture
KR20060039433A (ko) 스마트 스트리밍 포트를 가진 프로세서간 통신 프로토콜
US6909717B1 (en) Real time ethernet protocol
US6920143B1 (en) Computer telephony system using multiple hardware platforms to provide telephony services
CN1326066C (zh) 过程间通信方法及其设备
KR100442688B1 (ko) 프로세스간 통신방법 및 장치
KR20060041301A (ko) 보장된 서비스 품질 및 선택적인 브로드캐스팅을 제공하는프로세서간 통신 프로토콜
EP1296239A2 (fr) Méthode et appareil pour la communication entre des processus
CA2401462A1 (fr) Methode et appareil de communication interprocessus
JPH0666813B2 (ja) データ通信システム及び通信路確立方法

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020430

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

PUAL Search report despatched

Free format text: ORIGINAL CODE: 0009013

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIC1 Information provided on ipc code assigned before grant

Ipc: 7H 04L 29/06 B

Ipc: 7G 06F 9/46 A

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20040407