统一进程间通信的制作方法

专利名称：：统一进程间通信的制作方法
技术领域：
：本发明涉及统一进程间通信，尤其涉及可以与所使用的硬件和软件无关地用于通信的统一进程间通信系统和方法。
背景技术：
：通信系统可以配备各种类型的通信设备和模块，譬如，异步传输模式(ATM)、同步数字分层结构(SDH)和因特网协议(IP)等。在这样的通信系统中，每种系统使用了与其它系统不同的进程间通信(IPC)方法。IPC与每种系统的各个硬件设备紧密地结合在一起，并且依赖于每种系统的各个硬件设备。例如，异步传输模式系统使用了与同步数字分层结构系统所使用的IPC方法不同的IPC方法。这样的通信系统的通信方法随着系统的各个设备和装置的不同而彼此不同。由于缺乏可再用性和可移植性，这样的系统在把IPC应用于系统的过程中会导致不希望有的成本和额外开销，因此，是有缺点的。
发明内容为了解决现有技术的这些和其它问题，本发明的一个目的是提供一种可以与通信方法无关地应用在任何设备中的改进的进程间电信系统。本发明的另一个目的是提供一种通过把设备无关访问层(DIA)引入系统中和通过把IPC与每个硬件设备松散地结合在一起，能够改善IPC的可移植性的进程间通信方法。本发明的另一个目的是提供一种与用在通信设备中的操作系统无关地把消息数据从源发送到目的地的通信设备。本发明提供高度可移植性和灵活性。本发明的另一个目的是提供一种与用在通信设备中的硬件设备无关地把消息数据从源发送到目的地的通信方法。本发明的另一个目的是提供一种与设备所使用的通信方法(例如，异步传输模式、因特网协议、同步数字分层结构等)无关地把消息数据从源发送到目的地的通信设备。为了达到根据本发明原理的这些和其它目的，正如具体化的和概括描述的那样，本发明提供了把消息数据从源传送到目的地的方法，该方法包括与通信设备的操作系统无关地发送消息数据，所述发送至少部分通过操作系统无关访问层进行；和与设备的硬件无关地传输消息数据，所述传输至少部分通过设备无关访问层进行。为了达到根据本发明原理的这些和其它目的，正如具体化的和概括描述的那样，本发明提供了把消息数据从源传送到目的地的设备，该设备包括设备的操作系统部分，用于与所述设备的操作系统无关地处理所述设备内的内部通信；和设备的硬件部分，用于与所述设备中的硬件设备无关地处理与所述设备的外部通信。为了达到根据本发明原理的这些和其它目的，正如具体化的和概括描述的那样，本发明提供了在上面存储着一组指令的计算机存储介质，该组指令用于实现把消息数据从源传送到目的地的方法，该组指令包括用于执行下列步骤的一条或多条指令与通信设备的操作系统无关地发送消息数据，所述发送至少部分通过操作系统无关访问层进行；和与设备的硬件无关地传输消息数据，所述传输至少部分通过设备无关访问层进行。在如下的章节中，通过参照只作为例子来用的附图，更具体地描述本发明。从如下的说明和所附的权利要求书中可以清楚地看到本发明的其它优点和特征。图1显示了根据本发明原理的软件的逻辑排列功能块；图2是根据本发明原理的、用于消息交换的、在系统控制器与每个机框(shelf)之间的网络；图3显示了根据本发明原理构造的共享总线布局；图4显示了根据本发明原理的、机框间消息的星形总线布局；图5是根据本发明原理的、把消息发送到服务地点的客户应用；和图6是根据本发明原理的、核实部件功能的测试方法。具体实施例方式虽然从现在开始，参照显示本发明优选实施例的附图更全面地描述本发明，但是，从如下描述的开头就应该明白，本领域的普通技术人员可以对这里所述的发明进行修改，而仍然可以取得本发明的良好结果。因此，如下的描述应该被理解成面向本领域普通技术人员的概括性、原理性公开，而不是对本发明的限制。下面描述本发明的示范性实施例。为了清楚起见，并非实际装置的所有特征都加以描述。在如下的描述中，那些众所周知的功能或结构将不作详细描述，因为它们有可能使本发明的重点不突出。应该认识到，在任何实际实施例的开发过程中，必须作出许多装置特有的决定，以达到开发者的特殊目的，譬如说，遵从因装置而异的系统相关和商业相关约束。此外，还应该认识到，这样的开发努力也许既复杂又费时，但是，仍然是从本公开中获益的本领域普通技术人员要承担的例行任务。进程间通信(IPC)指的是在同一台计算机内，或者在网络上，数据在一个进程与另一个进程之间的交换。IPC隐含着保证对请求作出响应的协议。IPC可以由程序自动执行。图1显示了根据本发明原理的软件的逻辑排列功能块。图1显示了增强型服务110、连接管理112、公共代理114、公共OAM(操作、管理、和维护)116、统一进程间通信(UIPC)118、设备无关访问(DIA)层120、设备驱动器122、实时操作系统(RTOS)124、硬件126、操作系统无关访问(OIA)层128、异步传输模式(ATM)130、同步数字分层结构(SDH)和准同步数字分层结构(PDH)132、分组语音通信(VoiceoverPacket(VoP))134、综合数字环载波(IDLC)136、窄带(NB)用户138、宽带(BB)用户140、和因特网协议(IP)142。图1显示了沿水平方向排列的一些项目，还显示了沿垂直方向排列的其它项目。首先讨论水平方向。设备的公共项，譬如，增强型服务、连接管理、公共代理、公共OAM(操作、管理、和维护)、统一进程间通信(UIPC)、和实时操作系统(RTOS)等被显示成沿水平方向排列。现在讨论垂直方向。其它项目，譬如，异步传输模式(ATM)、同步数字分层结构、准同步数字分层结构(PDH)、分组语音通信(VoP)、综合数字环载波(IDLC)、窄带(NB)用户、宽带(BB)用户、和因特网协议(IP)被显示成沿垂直方向排列。沿垂直方向排列的那些项目通常依赖于所使用设备的每个特定部分的特性。取决于所使用的各种通信系统，可以去掉沿垂直方向排列的软件模块之一。图1的上部，即从“增强型服务”到“公共OAM”，依赖于软件的应用。本发明涉及与系统单元的内部部分和外部通信系统两者通信的统一进程间通信(UIPC)。系统的内部通信是在UIPC的操作系统部分中处理的，而系统的外部通信是在包括UIPC的硬件部分的那些部分中处理的。操作系统无关访问层(OIA)与操作系统的类型无关地处理通信功能。设备无关访问层(DIA)包含在本发明中。UIPC包括应用程序接口(API)和如下所述的协议栈。图2是根据本发明原理的、用于消息交换的、在系统控制器与每个机框之间的网络。图2显示了支持的网络布局，包括单元管理系统210、带有插件213的系统控制器212、带有插件215的机框2(214)、智能设备216、带有插件219的机框3(218)、和带有插件221的机框4(220)。在图2中，为了让机框4(220)与系统控制器212通信，尽管机框4(220)与系统212之间的通信在物理上穿过机框3(218)，但是，存在着一条根据本发明原理构成的、在机框4(220)与系统212之间的想象的直通路径。在下文被标为“总线布局”的部分中，当把本发明与总线布局的类型无关地应用于机框间的相互通信时，本发明的灵活性就显现出来了。换句话来说，在共享总线型的布局(图3)和在星形总线型的布局(图4)中，本发明都可以应用于机框间的相互通信。图3显示了根据本发明原理构造的共享总线布局。图4显示了根据本发明原理的、机框间消息的星形总线布局。在下文被标为“应用类型”的部分中，通过对第一机框的插件与不同机框的插件进行通信时的通信过程加以考虑(图5)，本发明的其它特征就呈现出来了。图5是根据本发明原理的、把消息发送到服务地点的客户机。在下文被标为“应用ID”的部分中，显示了用于根据系统用户删除和添加软件的软件的应用ID。在下文被标为“UIPC网络地址”的部分中，显示了要用于让消息到达可以路由消息的处理器或实体(entity)的网络地址。就软件功能和部件接口来说，这里包含了有关统一进程间通信(UIPC)部件的功能描述。UIPC提供了借此在同一个插件、同一个机框、或不同机框上的各种任务之间路由消息的手段。如下的八个文件提供了本申请文件的背景和附加信息开放系统互连，基本参考模型，ITU-TX.200；开放系统互连，数字链接服务定义，ITU-TX.212；开放系统互连，网络服务定义，ITU-TX.213；开放系统互连，传输服务定义，ITU-TX.214；公共软件平台系统结构文件，Aztek分号70881；DIA部件描述，Aztek分号70891；UIPC详细级别设计，LTITL分号SDC005-UIPC；和OIA部件DLD，LTITL分号SDC005-OIA。本申请文件自始至终都使用如下的定义和缩写术语“API”指的是应用程序接口；术语“EMS”指的是单元管理系统；“跳段(hop)”指的是在数段相继路径上传输消息的过程中的一段路径；术语“链接”指的是两个物理端点之间的连接；术语“NE”指的是网络单元；术语“网络单元”指的是单元管理系统独立管理的一个单位(一个网络单元可以由一个或多个局部的或地理上分散的机框组成)；术语“节点”指的是可独立寻址的、UIPC通信网络的任何一个单元；和术语“智能端点”指的是可以接收消息的、附在插件上的设备(这种设备的例子有DSL调制解调器)。术语“UIPC”指的是统一进程间通信(UIPC也可以指通用进程间通信)；术语“OIA”指的是操作系统无关适配层；术语“DIA”指的是设备无关适配层；术语“DSL”指的是数字用户线；术语“IAD”指的是综合访问设备；术语“RTOS”指的是实时操作系统；和术语“TCP/IP”指的是在传输控制协议/因特网协议。部件综述本发明的UIPC部件意在用于各种应用之间的所有处理器内和处理器间通信。这个部分包括本发明支持的网络单元布局的描述、本发明所使用的寻址的基本描述、和本发明的UIPC支持的应用模型的描述。如下特性包含在本发明的UIPC和本发明的其它单元中。UIPC提供了网络单元内部任何地方的任务之间的双向消息传送。UIPC允许异步发送消息的应用。应用程序接口(API)将没有阻塞地直接返回。UIPC允许不会超时地发送消息和同步等待响应的应用。UIPC使基础性物理传输机制抽象化。要求需要与服务通信的应用知道那个服务的位置。在下文标为“应用类型服务”的部分中描述服务应用。如下的附加特性包含在本发明的UIPC和本发明的其它单元中。UIPC提供借此可以把消息广播出去的机制。无需改变高层协议，就能够改变低级UIPC协议。无需改变低层协议，就能够改变高级UIPC协议。UIPC一条链路一条链路地检测传输错误和重试有错分组(这意味着，要求有管理每条链路的、协议的链路层以使那条链路是可靠的)。同一个UIPC应用程序接口(API)用于处理器内和处理器间通信。UIPC进行大消息的分割和组装。UIPC允许端到端面向连接和无连接通信。UIPC提供允许调试输出的机制。UIPC协议参数在运行期间是可以设置的。UIPC提供为每条链路设置最大传输单元的机制。UIPC使跳段与改变最大传输单元相适应。UIPC支持实时关键性消息的消息优先级。UIPC是与操作系统无关的。UIPC让消息透明地从控制器传送到附在插件上的设备(这些设备可以，也可以不遵从UIPC协议)。UIPC让消息从网络单元内的任何一个机框路由到另一个机框。UIPC提供用于报告协议错误和统计的应用程序接口(API)。除了本发明的上述特性之外，还为本发明考虑到实时系统设计的特性。实时系统设计的相关特性如下。在实时系统中，一些消息必须在某种时间限制下发送。这意味着，在协议栈的最低级上的分组的最大传输单位必须小到足以使大消息不会浪费通信流水线的带宽。在实时系统中，处理器或通信带宽可能是有限的。这意味着对效率的需要。消息的处理应该是最低限度的。应该使协议额外开销达到最小。要在功能与效率之间权衡利弊。像TCP/IP那样的协议栈是富特征的，但是实现这些特征需要花费许多额外开销。从效率的角度来考虑，使协议与实时系统相适应最有可能使协议额外开销达到最小，并且，最适合于大多数普通类型的消息传送。这意味着特征受到限制。需要附加特征的少数几种应用也许不得不参与到供应某个附加功能中去，而不依赖于协议栈来供应所需特征。在实时系统中，实时操作系统(RTOS)一般不让任务在多个端点上等待。其结果是，通常借助于可以从多个源，譬如，其它任务或中断服务例程(ISR)接收消息的一个消息队列完成各种任务。这意味着UIPC需要支持借助于单个消息队列构造起来的多个任务。在实时系统中，实时操作系统(RTOS)一般提供所有任务可以访问所有存储器的平坦(flat)存储模式。在这种模型中，几个任务可以共享数据，而不会有在消息中传送数据的额外开销或用于实施共享存储器的操作系统额外开销。一些实时操作系统(RTOS)可以提供把存储器限制在某个任务可以访问的保护存储模式。在这样的模型中各种任务之间的通信依赖于消息传送或共享存储器的使用。存储器模型不影响在本说明书中提到的应用程序接口(API)或协议定义。但是，它的确影响这些部分的实现。在作出实现建议的地方，本说明书假设更普通的平坦存储模型。网络单元布局网络单元代表独立管理的设备构件。网络单元可以由一个或多个局部的或地理上分散的机框组成。网络单元分布的方式称为网络单元布局。本发明的UIPC支持的布局是树结构。可能存在一个与多个其它机框相连接的主系统控制器机框。对着其它机框的任何机框可能有，也可能没有把通信路径与系统控制器相连接的直接硬件。为任何机框之间的通信配备软件路由功能。它与网络布局无关。存在两种类型的路由机制一种是静态路由，另一种是动态路由。除了机框之外，每个机框包含数个插件。插件可以包含可以，也可以不通过UIPC协议进行通信的、附在它们身上的智能设备。这些插件或设备可以被当作树结构的分支或叶片。图2是根据本发明原理的、用于消息交换的、系统控制器与每个机框之间的网络。图2显示了支持的网络布局，它包括单元管理系统210、带有插件213的系统控制器212、带有插件215的机框2(214)、智能设备216、带有插件219的机框3(218)、和带有插件221的机框4(220)。图2显示了设计本发明的UIPC的网络布局。本发明的UIPC支持在单个插件上的任务之间、在同一个机框上的不同插件上的任务之间、在任何机框上的任务之间、以及在任何机框和所附智能设备(例如，数字用户线路调制解调器和综合访问设备)上的任务之间的消息交换。请注意，这里假设，如果需要的话，可以认为需要在两个机框之间流动的消息是通过系统控制器机框212路由的。这样就可以使协议简单化，并且降低了与管理更一般的网络布局的、诸如因特网协议(IP)之类的协议相联系的额外开销。还请注意，单元管理系统210也可以通过UIPC进行通信。消息可以在单元管理系统210与任何机框上的任何插件之间路由。就UIPC而言，单元管理系统(EMS)210看起来正好像任何其它机框。总线布局上述网络布局从外部的观点定义了本发明的系统。现在来描述总线布局。总线布局从内部的观点描述本发明的机框。总线布局的设计影响消息如何流过机框上的插件和在机框上的插件之间流动。总线布局可以是共享总线型的(图3)，也可以是星形总线型的(图4)。在共享总线型布局中，任何插件都可以与任何其它插件通信。但是，有些共享总线设计只让插件与单个主机通话。在星形总线型布局中，每个插件与中央集线器连接。与布局无关，必须存在一些与外部世界的连接。从外部源到达机框的控制消息将由处在两种总线布局之一下的单个插件来处理。因此，一个插件总有一些在外部系统与插件之间路由消息的功能。图3显示了根据本发明原理构成的共享总线布局。图3描绘了含有插件1(312)、插件2(314)、插件3(316)、插件4(318)和插件5(320)的机框310。在图3中，机框310包括与另一个机框(除了机框310之外)存在外部连接的插件1(312)。如插件4(318)发送的消息所示，与其它机框交换的消息由插件1(312)路由。对于在插件之间路由消息，图3还显示了两种可能选择。在让任何插件与任何其它插件通话的设计中，如果插件知道彼此的地址，那么，可以在这些插件之间直接发送消息。这是插件4(318)与5(320)之间所示的。这是一种在插件之间获取消息的最有效手段。但是，为了简单起见，如从插件2(314)发送到插件3(316)的消息所示，装置可以选择通过中央路由器312路由所有插件间消息。这种方法也可以用于要求所有消息流过主机的共享总线。请注意，如后所述的UIPC包括用于每个插件和用于可以包容直接插件到插件路由和集中路由两者的机框的路由机制。它只依赖于每个插件的路由表是如何布居的。图4显示了根据本发明原理的、用于机框间消息的星形总线布局。图4描绘了含有插件1(412)、插件2(414)、插件3(416)、插件4(418)和插件5(420)的机框410。如图4所示，在星形总线布局中，所有消息都穿过中央路由器412。应用类型有各种类型可能存在的应用。为了便于讨论，一个应用是作为一个任务实现的。所有应用可能都需要利用UIPC。一些应用通常不与其它应用交互。这些应用被称为独立应用。其它应用提供适合于其它应用的服务。这些应用被称为服务。与服务交互的任何应用被称为客户。一些客户应用也可以是服务本身。除了应用类型之外，对于每个任务，很有可能存在着某种父母/子女(parent/child)关系。甚至独立任务也会存在创造它的某种任务(即，它的父母)。为了维护的目的，父母可能需要与他们的子女通信。例如，母任务可能想要它的子女作出强制回应，以确信它正在正常工作。如下所述的是三种应用类型(服务型，客户型，和独立型)，以及在应用之间的示范性客户机/服务器消息流动。第一种应用类型是服务型。服务是为其它应用(例如，客户)完成特定任务，譬如，控制对公共资源的访问实现的。对于客户来说，如何或在哪个插件上，和可能哪个机框实现服务是无关紧要的。服务作为抽象概念的使用使客户任务与服务所处的位置无关地利用服务。这种设计是易于改变的，因为它使服务、插件或机框内的工作部门可以不影响客户应用地发生改变。只有在一些情况下，应用才需要与另一个节点上的特定插件通话。服务利用熟知应用ID，通过UIPC登记它们自己。应用ID类似于向服务器开放插座连接时使用的传输控制协议(TCP)端口号。当与服务通信时，客户机需要知道服务的应用ID。如果客户机需要与特定单元的硬件，譬如，机框或机框上的具体插件上的服务通话，那么，它还必须指定网络地址。熟知服务的例子有管理OAM(操作、管理、和维护)相关请求的OAM任务，或负责接收报警信号的报警信号管理任务。第二种应用类型是客户型。客户是与服务通话的任何应用。与另一个服务通话的服务被认为是那个其它服务的客户。也不是服务的客户不含有熟知应用ID。但是，为了让服务能够把响应发送给客户，UIPC将把一个应用ID指定给客户的消息队列，以便可以把响应路由给客户。第三种应用类型是独立型。独立应用是不与其它应用通话的那些应用。与客户一样，独立应用不含有熟知应用ID。现在来讨论有关示范性客户机/服务器消息流动的信息。存在着许多种各种应用之间的消息流动的组合。理解消息流动的关键是UIPC包含了确定应该把消息发往何方的路由机制。系统中的每个插件都具有路由功能。每个机框也具有在插件或机框之间分配消息的路由功能。为了展示UIPC支持的最复杂路由，现在请参照图5。图5是根据本发明原理的、把消息发送到服务地点的客户应用。图5描绘了系统控制器机框510和机框516。系统控制器机框510含有机框控制器512和插件516。机框516含有机框控制器522和插件526。插件526含有可以是任何任务530的客户应用530。插件526含有UIPC528。机框控制器522含有UIPC524。插件516含有服务X520和UIPC518。机框控制器512含有UIPC514。图5描绘了把消息发送到服务X520的客户应用530。客户应用530由任何任务530来表示。在图5中，服务X520是在系统控制器机框510上实现的，和客户是在某个其它机框516上实现的。客户请求UIPC528借助于系统控制器510的网络地址把消息发送到服务X520。在客户机插件526上的UIPC528把消息转发到机框路由器。机框路由器查找目的地网络地址。如果它与我的网络地址不符，那么，就把消息路由到系统控制器510。系统控制器510上的机框路由器查找目的地网络地址，并且确定是在机框510中的插件516上实现的。把消息发送给那个插件516。然后，在那个插件516上的UIPC518把消息路由到服务X520。应用ID这个部分说明如何把熟知应用ID指定给应用，供应用使用，和为应用所知。在插件中可用的应用ID的最大号码是UIPC_MAX_APP_ID。在插件中可用的应用ID的最大号码是得到与允许的进程间通信(IPC)队列的最大号码相对应的操作系统无关访问层(OIA)允许的。熟知应用ID是由应用从UIPC_MAX_WEL_KNOWN_APP限定的一列应用ID中，即UIPC_MAX_APP_ID的值的前半部分中，选择出来的。它像与传输控制协议(TCP)一起使用的熟知端口号。在这种情况下的应用被定义为除UIPC之外的任何东西。这种应用包括公共操作、管理、和维护(OAM)部分，以及其它应用。对于不是熟知应用的应用，从UIPC_MAX_APP_ID限定的那些值的其它后半部分中分配应用ID。这个范围是从UIPC_DYN_APP_ID_START(UIPC_MAX_WEL_KNOWN_APP+1)到UIPC_MAX_APP_ID。当任务想要发送或接收消息时，指定这些应用ID，一旦任务完成了消息的发送或接收，就释放这些应用ID。当这些应用ID被释放时，可以重新使用它们。UIPC网络地址网络地址用于让消息到达可以路由消息的处理器或实体。因此，每个插件、机框、机架(rack)、或智能端点拥有唯一的网络地址。也可以把机框组织成也可以拥有唯一网络地址的机架。也可以让应用ID包含在告诉路由器哪个应用应该接收消息的消息中。更简单地说，网络地址让消息到达插件，和应用ID让消息到达插件上的任务。网络地址必须能够与机架、机框、插件、或附在插件上的智能端点的相联系。为此，定义了划分成A、B、C、和D四个类别的32位地址。这类似于具有4个类别的因特网协议(IP)寻址。每个类别包括8个位。类别A代表机架。类别B代表网络单元中机框的地址。类别C地址代表插件。类别D地址代表智能端点。这种方案允许每个网络或子网络上拥有256个独立的设备。地址类别的使用使路由器能够屏蔽掉不关心的区段。这样就简化了路由表。例如，可能让消息到达附在插件上的特定设备。由于所有想知道的是如何让消息到达插件上，因此，机框路由器可以忽略地址的类别D部分。不需要有关附在插件上的设备的、在其路由表中的任何条目。同样，由于所有想知道的是如何让消息到达设备上，因此，插件上的路由器可以忽略地址的类别A和B部分。也可以把特殊地址定义成用于不知道或不应该使用特定地址的环境中。例如，一个插件上的应用可能需要与已知位于机框上、还不知道在什么地方实现服务的服务通信。特殊地址也可以用在把地址动态地指定给路由器的地方。到未指定路由器(例如，一个插件)的网络层控制消息可以包含特殊类型的地址，并且传送使未指定路由器能够具有新地址的信息。任何协议层也可以在通信协议控制消息的时候使用特定地址。通过特殊地址还可以支持消息的广播。如下的特殊值可以用作地址的类别A、B、C、或D部分。路由器应该从类别A地址开始、一直到类别D地址处理它们，以确定如何路由消息。将描述的第一个特殊值是“任何位置”值。“任何位置”值是0xFF。当“任何位置”值在消息的地址当中时，把消息定向到可以在任何插件(类别C部分是这个值)或任何机框(类别B部分是这个值)上的服务。换言之，当地址的类别C部分具有值0xFF时，那么，把消息定向到可以在任何插件上的服务，和当地址的类别B部分具有值0xFF时，那么，把消息定向到可以在任何机框上的服务。如果路由器把这个地址看作类别值，那么，应该把消息传送到传输层。传输层将确定服务是否已经注册成利用消息中的应用ID来接收消息。将描述的第二个特殊值是“这个位置”值。“这个位置”值是0xFE。如果地址的类别具有“这个位置”值，那么，它就指示消息终止在接收消息的路由器上，或者，如果较低类别地址不包含“忽略(0xFD)”值，就终止在较低类别地址上。将描述的第三个特殊值是“忽略”值。“忽略”值是0xFD。如果类别具有“忽略”值，那么，消息应该终止在不具有0xFD值的最高类别路由器上。“忽略”值用在把消息定向到特定机框或插件上。“忽略”值用在有关类别B和C路由器的路由器地址中。类别B路由器将具有像0xXXXXFDFD那样的地址，和类别C路由器将具有像0xXXXXXXFD那样的地址。还请注意，正像任何其它插件一样，机框路由器处在上面的插件也将拥有它自己的地址。将描述的第四个特殊值是“广播”值。“广播”值是0xFC。接收包含“广播”值的地址的路由器应该向它的路由表中与出现0xFC的类别匹配的所有地址广播消息。例如，接收带有0xXXXXFCFD的消息的机框将向插件的每一个发送消息。0xXXXXFCFC的值将使每个插件发送消息，并且将其转发给所有类别D设备。将描述的第五个特殊值是“系统控制器”值。“系统控制器”值是0xFB。“系统控制器”值只应用于类别B地址。“系统控制器”值用在把消息特别发送给系统控制器机框的时候。现在给出有用地址的四个例子。应用把消息发送到这个机框上某处的服务0xFEFEFFFD。应用把消息发送到这个插件上的服务0xFEFEFEFD。应用把消息发送到可以在任何机框的任何插件上的服务0xFFFFFFFD。应用向系统中的所有插件广播消息0xFCFCFCFD。部件描述本发明的UIPC划分成两个主要部分应用程序接口(API)和协议栈。应用程序接口为应用提供了无需知道协议的细节或如何执行协议，借助于简便的手段发送消息。为了清楚起见，为支持平坦存储模式的操作系统给出推荐装置。本发明的UIPC意在提供穿过同一机框上的插件或穿过机框的、在和不在处理器上两者的任务间通信。本发明的UIPC负责让消息到达它们的目的地。但是，消息的内容由应用负责。因此，UIPC不提供以机器无关格式表示用户数据的机制。这将由表示层负责。由于UIPC意在用作实时协议，因此，不包含与表示层相联系的额外开销。UIPC部件被设计成使把应用程序接口与协议处理分开。这就使不需要协议栈的有效处理器内通信，而同时可以使需要协议栈的处理器间通信。UIPC应用程序接口是作为程序库而存在的，程序库是从应用任务的环境(context)调用的。应用调用UIPC应用程序接口来发送和接收消息。为了进行处理器间消息传送，UIPC应用程序接口可以与UIPC协议任务(也称为“UIPC任务”)通信。通过把消息发送到UIPC协议任务的队列中，就可以做到这一点。应用程序接口(API)是可以由任何任务使用的共享程序库。应用程序接口把接口提供给UIPC提供的所有外部功能。应用程序接口无需通过UIPC任务，就可以处理处理器内操作。通过检查接受的端点处理，看一看它们是代表在处理器上的端点，还是代表不在处理器上的端点，就可以做到这一点。如果在处理器上，那么，通过调用操作系统无关访问层(OIA)消息传送应用程序接口，把消息直接发送到由端点所指消息队列中。如果不在处理器上，那么，把消息发送到UIPC协议任务的消息队列中。调入Uipc_InitCardContext()初始化本发明的UIPC。UIPC内部表全局表UIPC全局表全局表包含有关具体插件中的所有任务的信息。在全局中的每个条目是一个任务控制块(TCB)。每个任务控制块含有任务专用信息。任务控制块的第一栏是任务ID。任务控制块中的第二栏是应用ID。这是任务的主队列的应用ID。每个任务含有动态消息管理表(handlertable)、静态消息管理表、和动态消息类别表。每当任务调用Uipc_RegisterOneTimeApi()时，就在任务的动态消息管理表中形成一个条目。在动态消息管理表中的条目不是永久的。一次性应用程序接口的响应一到达，就删除这个条目。动态消息管理表是利用平衡二叉树(binarytree)实现的。每当任务调用Uipc_RegisterMsgHandler()时，就在静态消息管理表中形成一个条目。静态消息管理表专用于观察应用程序接口。与动态消息管理表不同，静态消息管理表中的条目是永久的。静态消息管理表是利用阵列实现的。每当任务调用Uipc_GenerateTempMsgClass()时，把消息类别返回到任务，并且在动态消息类别表中进行必要的更新，以便特定的消息类别变成被使用的。每当任务调用Uipc_FreeTempMsgClass()时，UIPC就在动态消息类别表中作必要的修改，以便将来可以使用特定的消息类别。动态消息类别表也被当作阵列来实现。全局表包含到上述所有表格的指针。除此之外，全局表还包含到任务的空闲消息管理函数的指针。全局表还包含对于每个任务来说，必须用在Uipc_RcvLoop()内的等待时间。每当在Uipc_RcvLoop()应用程序接口内时，就在等待时间内查询全局表。由于全局表被所有任务访问，因此，旗语(semaphore)将保护全局表。这个旗语是在Uipc_InitCardContext()期间建立起来的。每当调入Uipc_InitTaskContext()时，借助于为那个任务的tidandwaitTime输入的有效值，在全局表中形成一个条目，并且为静态消息管理表和动态消息类别表分配存储器。把appId、到空闲消息管理表的指针、和到动态消息管理表的指针设置成NULL.在Uipc_SetMainQueue()期间，填充appId，和在Uipc_RegisterIdleHandler()期间，填充到空闲消息管理程序的指针。动态消息管理表每个任务必须完成这个动态消息管理表。这个表专用于一次性应用程序接口(API)。UIPC动态消息管理表动态消息管理表在其中含有三栏。第一栏是消息类别，第二栏是回调函数指针，和第三栏是定时器管理。每当任务调用Uipc_RegisterOneTimeApi()时，就在任务的动态消息管理表中形成一个条目。每当消息借助于像UIPC_MSG_RSP那样的消息方向到达时，就利用消息类别查找该表格，以找出相应的回调函数。在调用回调函数之后，从任务的动态消息处理表中删除该条目。动态消息处理表中的条目不是永久的。为了从动态消息处理表中删除条目，要调用UIPC专用应用程序接口Uipc_DeleteMsgHndlrTableEntry()。一次性应用程序接口的响应一到达，就删除这个条目。即使出现超时情况(如果在特定时间内响应没有到达)，也要删除动态消息处理表中的条目。通过UIPC控制数据把有关消息到达或超时的情况告知上层。动态消息处理表是利用平衡二叉树实现的。UIPC静态消息管理表每个任务必须完成静态消息管理表。UIPC静态消息管理表每当任务调用Uipc_RegisterMsgHandler()时，在静态消息管理表中形成一个条目。静态消息管理表专用于观察应用程序接口。每当消息借助于像UIPC_MSG_REP或UIPC_MSG_REQ那样的消息方向到达时，就利用消息类别查找该表格，以找出相应的回调函数。如果找到条目，那么，就调用回调函数。与动态消息处理表不同，静态消息管理表中的条目是永久的。静态消息管理表是利用阵列实现的。因为每个表拥有它自己的静态消息管理表，所以不需要旗语来保护这个表。UIPC动态消息类别表每个任务必须完成动态消息类别表。每当任务调用Uipc_GenerateTempMsgClass()时，把静态消息类别范围(从UIPC_DYN_MSG_CLASS_START到UIPC_MAX_NO_DYN_MSG_CLASS)内的自由消息类别赋予任务。如果没有自由消息类别可用，那么，向应用程序接口用户报告没有可用的。在分配了自由消息类别之后，更新这个表格，以便使特定消息类别变成被使用的。每当任务调用Uipc_FreeTempMsgClass()时，就释放消息类别，以便将来可以使用特定的消息类别。因为每个表拥有它自己的动态消息类别表，所以不需要旗语来保护这个表。UIPC栈为了进行处理器间消息传送，UIPC应用程序接口(API)可以与UIPC协议任务(也称为“UIPC任务”)通信。通过把消息发送到UIPC协议任务的队列中，就可以做到这一点。UIPC路由程序库也显示了。UIPC路由程序库使UIPC应用程序接口或UIPC协议任务能够确定如何路由消息。这是基于应用ID和网络地址的。对于处理器间通信来说，难以胜任让所有消息都经过UIPC协议任务。因此，UIPC应用程序接口首先调用路由程序库，看一看是否可以把消息直接发送到同一处理器上的任务队列中。如果不可以，UIPC应用程序接口就把消息转发到UIPC协议任务。UIPC协议任务将通过协议栈传送消息。在栈的网络层上，路由应用程序接口将再次被调用，以确定应该在哪条物理链路上发送消息。请注意，UIPC任务可以由子任务组成。这取决于协议栈层的实现。但是，从UIPC应用程序接口的角度来看，只需要知道有关单个UIPC协议任务的情况，并且与单个UIPC协议任务通信。在UIPC应用程序接口把消息传送给UIPC之后所发生的情况是隐藏的。路由程序库上的注释也是恰如其份的。路由是由协议的传输层和网络层两者负责的。网络层确定应该把消息发送到哪条物理链路上。网络层根据网络地址作出这样的确定。传输层确定应该把消息发送给哪个应用。传输层根据应用ID和网络地址两者作出这样的确定。这取决于如何完成这些路由表的实现。可以让网络层的路由表和传输层的路由表彼此分离，以便去耦这两层。但是，从在协议任务外部的功能(例如，UIPC应用程序接口)的角度来看，要求某些路由功能，而这与如何实现堆栈无关。因此，路由程序库作为一个独立的条目显示出来的。实际上，可以仅把稀(thin)应用程序接口加在网络层和传输层展示的功能上面。协议层开放系统互连(OSI)堆栈模式用于定义存在于通信协议中的功能层。开放系统互连(OSI)是网络结构的模型，并且是一组实现它的协议。可以把这组协议称为协议栈。可以在7个层之间划分OSI结构，这7个层从最低到最高依次是(i)物理层、(ii)数字链路层、网络层、(iv)传输层、(v)会话层、(vi)表示层、(vii)应用层。本发明的UIPC堆栈模式符合开放系统互连(OSI)定义，但是，没有必要包括开放系统互连(OSI)规定的所有7个层。UIPC协议被修整得适合于实时系统，并且不需要开放系统互连(OSI)层的所有功能。在如下的部分中描述本发明的各个层的功能。但是，在讨论每层的规定之前，先把如下的一般要求应用于每一层。这些要求被当作实现这些层的原则。每层的首标应该包含协议鉴别符。该鉴别符指示在消息中正携带着哪种协议或协议组合。它在首标内通常是2个或3个位。这样，将来无需改变其它协议，就可以实现不同的协议。例如，正在被网络层处理的输入消息可能含有指示哪个协议模块应该是要下一个处理消息的、在网络层首标中的协议鉴别符。如果UIPC想要支持诸如传输控制协议(TCP)或用户数据报协议(UDP)之类的传输层协议，协议鉴别符就告诉网络层是否把消息传递给传输控制协议或用户数据报协议模块。用户数据报协议(UDP)指的是提供数据报服务的因特网标准网络层、传输层和会话层协议。用户数据报协议是像TCP那样，放在因特网协议(IP)上面的层上无连接协议。一些协议层可能依赖于其它协议层，并且，不能独立使用。例如，作为依赖于物理高级数字链路控制(HDLC)层的链路层协议的LAPD就是这种情况。缩写“LAPD”代表D信道上的链路访问过程。每一层都保存消息优先级。高优先级消息或数据段(在需要分段的长消息的情况下)总是在其它消息或数据段之前发送。值得推荐的是，本发明只支持两种优先级，即正常的和高的。任何更多的优先级都有可能引起混乱。但是，本发明可以支持其它的优先级。每一层都应该提供标志，以便使那一层上扩充的协议在将来可以扩充。如何把它付诸实施的例子是为网络层预订提供扩充寻址的特殊标志值。每一层可以定义在端点的同等层之间交换的特殊控制消息。这些控制消息可以让每一方都能协商协议参数或进行流控制。如下的部分描述每个协议层的特性和责任。每个部分还包括该层应该提供的一系列原语。原语的作用是显示向其它软件(即，相邻上协议层)提供的外部接口。它们不描述在两个端点之间传递的实际消息。这里不描述这样的消息的定义和任何相关的状态机。在进行详细设计时再定义它们。原语是利用国际电信联盟(ITU)专门术语命名的，并且被分类成Request(请求)、Respone(响应)、Indication(指示)和Confirm(确认)。Request这是层必须支持的函数，其作用是由在它上面的相邻层调用去请求一些动作。Respone这是由远端在接收到请求响应的指示时调用的。其结果是，请求者将接收到确认。Indication这是发生了某一事件的通告。意图是让相邻上层或生成的代码过一会接收这些指示。大多数指示是远端通过请求，启动一些动作的结果。Confirm这是已经对请求作出响应的确认。每个原语都含有与之相联系的原语专用数据。在层与层之间传递原语的机制在这里不是特别规定的，因为它是层的详细设计的一部分。注意到必须定义最大传输单位(MTU)也是很重要的。最大传输单位(MTU)定义最大消息尺寸。在这个尺寸以下的任何消息都以单个消息发送。因此，高优先级的时间关键因素的消息可以在不长于两个长度为最大发送单位的消息所花费的时间(一个时间间隔用于发送消息，另一个时间间隔用于发送高优先级消息)的时间内得到处理。为了保证正好是这种情况，在网络层消息、链路层消息、和物理层(例如，高级数据链路控制)帧之间存在着一一对应关系。需要在这些等级上把消息捆绑在一起，以便有助于保证实时性能。确定最大发送单位是应用设计的一部分。这样，不将其定义成UIPC的一部分。但是，UIPC的确定义了只有UIPC部件可见的内部应用程序接口(API)，以便设置最大发送单位。最大发送单位由应用性能要求、应该获取消息的跳段数、和正在使用的通信链路的速度来决定。存在着源自把消息从一个节点路由到下一个节点的网络的复杂因素。如果最大发送单位(MTU)对于每个跳段来说，都是不同的，那么，必须采取一些措施来解决不一致性问题。问题出在一个节点发送MTU大的消息，而在具有小MTU的跳段上通过节点转发消息的时候。一个节点难以知道消息在上面行进的所有链路的所有MTU。事实上，发送节点甚至可能不知道在什么链路上行进。它所知道的就是让消息到达相邻节点。因此，在每个节点上的协议栈应该解决与那个节点相连接的链路上的MTU尺寸之间的差异。如本说明书下文的“网络层”部分所述的，网络层具有消息分段功能。这应该被用来把较大的MTU分段成较小的MTU。如果网络层在每个节点上没有这样做，那么，另一种可选方案将建立端到端连接，并且通过所有节点协议最大MTU应该是什么。但是，这种方式将导致额外开销，并且对无连接消息力不从心。UIPC静态消息管理表每个任务必须完成静态消息管理表。UIPC静态消息管理表每当任务调用Uipc_RegisterMsgHandler()时，在静态消息管理表中形成一个条目。静态消息管理表专用于观察应用程序接口。每当消息借助于像UIPC_MSG_REP或UIPC_MSG_REQ那样的消息方向到达时，就利用消息类别查找该表格，以找出相应的回调函数。如果找到条目，那么，就调用回调函数。与动态消息处理表不同，静态消息管理表中的条目是永久的。静态消息管理表是利用阵列实现的。因为每个表拥有它自己的静态消息管理表，所以不需要旗语来保护这个表。UIPC动态消息类别表每个任务必须完成动态消息类别表。每当任务调用Uipc_GenerateTempMsgClass()时，把静态消息类别范围(从UIPC_DYN_MSG_CLASS_START到UIPC_MAX_NO_DYN_MSG_CLASS)内的自由消息类别赋予任务。如果没有自由消息类别可用，那么，向应用程序接口用户报告没有可用的。在分配了自由消息类别之后，更新这个表格，以便使特定消息类别变成被使用的。每当任务调用Uipc_FreeTempMsgClass()时，就释放消息类别，以便将来可以使用特定的消息类别。因为每个表拥有它自己的动态消息类别表，所以不需要旗语来保护这个表。网络层网络层负责获取处理器之间的消息。网络层具有如下特性。网络层根据网络地址路由消息。网络层检查网络地址，以确定是否把消息指定到接收它的处理器，或者是否需要通过另一个接口转发消息，让它到达它的最后目的地。网络层支持消息的分段/组装。因为不同的链路可以具有尺寸不同的最大传输单位(MTU)，所以，与网络层可以不让消息通过传输层地路由它们的事实结合在一起来考虑，网络层也可以处理MTU尺寸之间的转换。这意味着在这一层上支持消息分段和组装。网络层对应于无状态操作。因为网络层不提供可靠的点到点或端到端消息传输，所以它是无状态的。一旦消息被发送出去，就忘掉它。点到点的可靠性是由数据链路层来负责的。必要时，端到端的可靠性由传输层来负责。类别D路由-特殊情况网络层还必须支持把消息路由到附在插件上的设备中。这些设备的一些可以通过UIPC通信。在这种情况中，它们将具有类别D地址，并且，把消息路由到这些地址就像把消息路由到任何其它地址一样。如果它们不运用UIPC，网络层必须实施借此设备可以具有虚地址的措施。在这种情况下，代理应用将在插件和寄存器上运行，以接收有关特定类别D地址的消息。代理应用负责接收这些消息和把它们转发到各个设备。另外，这些消息不需要利用传输层协议，因为，并不把它们指定给各种应用。请注意，原语只松散地对应于国际电信联盟(ITU)定义。请参见上述文件“开放系统互连，网络服务定义，ITU-TX.213”。这是因为国际电信联盟(ITU)使用了比UIPC所需的更复杂的模型。它把网络层模型化成两个端点之间的连接。面向连接网络层比网络层要复杂得多，因为已经为它提供了链路层。另外把UIPC的网络层模型化成像不需要连接的因特网协议(IP)那样的基于分组的协议。另外，国际电信联盟(ITU)不定义指定网络地址的任何机制。假设这个信息以某种方式适用于网络层。因此，UIPC定义了附加的地址相关原语，以便网络层具有执行地址指定功能的接口。原语与网络层的外部接口显示在表3的原语中。表3-网络层原语和参数一览表这些参数定义如下。术语“远端网络地址”指的是把操作对准它的节点的地址。术语“优先级”指的是用户数据的优先级。术语“协议描述符”指的是在用户数据中携带更高级协议的标识符。术语“用户数据”指的是发送的数据。用户数据对网络层是透明的。请注意，原语只松散地对应于国际电信联盟(ITU)定义。请参见上述文件“开放系统互连，网络服务定义，ITU-TX.213”。这是因为国际电信联盟(ITU)使用了比UIPC所需的更复杂的模型。它把网络层模型化成两个端点之间的连接。面向连接网络层比网络层要复杂得多，因为已经为它提供了链路层。另外把UIPC的网络层模型化成像不需要连接的因特网协议(IP)那样的基于分组的协议。另外，国际电信联盟(ITU)不定义指定网络地址的任何机制。假设这个信息以某种方式适用于网络层。因此，UIPC定义了附加的地址相关原语，以便网络层具有执行地址指定功能的接口。根据网络层所需的操作，如下信息应该是网络层消息首标的组成部分目的地地址、源地址、网络消息类型(可以是网络层控制或用户数据消息的某种类型)、分段信息(与分段的消息有关的)、控制(用于网络层控制消息和指示消息的类型)。传输层传输层负责应用之间的端到端通信。它具有如下特性把消息路由到作为端点的应用或服务-传输层引入了应用ID的概念。应用可以登记它们自己，以接收为特定应用ID指定的消息。这支持客户机/服务器应用。这一层将确定是否应该把消息路由到这个处理器上的任务中。以消息为基础-借助于写操作和缓冲器调用传输层，在单个读操作中，在远端上接收缓冲器中的数据。可以把缓冲器看成是一种消息。这可以与基于流方法相对照，在基于流的方法中，读操作与在单个写操作中还是在多个写操作中发送字节无关地简单接收偶尔适用的字节。提供无连接消息传送。在这种情况中，依靠应用和低层来保证可靠的端到端传输。为了降低额外开销，无连接消息传送不追究远端实际上是否接收到消息和消息是否是有效的。低层通过CRC(循环冗余校验)检验已经保证了消息是有效的，并且让消息逐条链路地重新发送。一般来说，如果应用必须知道远端应用接收到消息，它就期望应用级确认。由于这些其它层共同负担保证有效端到端传输的工作，因此，可以使用无连接操作。但是，请注意，传输层的确具有舍弃掉部分消息的机制，在那里长消息的某些段可能已经被丢弃掉了。由于这种无连接消息传送比面向连接消息传送更易实现，因此，建议首先实现这种无连接消息传送。提供面向连接消息传送。在这种情况中，为应用建立和维持端到端连接。这在功能上类似于传输控制协议(TCP)网络接口。当在面向连接路径上设置和通信时，存在着附加的额外开销和复杂性。因此，建议只有当不指望通信那么可靠时，或当资源或实时考虑较少时才使用这种模式。虽然在这里没有规定，但是支持无连接和面向连接消息传送的低级设计可能包括两个独立的传输层模块或实现两种类型的消息传送的单个模块的使用。多路复用来自可变端点的消息-假设多个端点可以发送同一个应用，传输层根据源地址组装消息。建造路由表为了把消息路由给特定的应用，传输层负责建造把应用ID的路由表构造成真实消息队列ID的映射。对路由表的访问需要通过只有UIPC部件看得见的内部应用程序接口(AP1)展示出来。这样做是需要的，以便可以通过UIPC应用程序接口功能进行有效查询，以确定应该在处理器上，还是不在处理器上路由消息。原语到传输层的外部接口显示在表4的原语中。请注意，连接建立和释放原语只应用于面向连接模式。表4-传输层原语和参数一览表术语“应用ID”指的是应用的标识符。它用于区分可以具有给定网络地址的处理器提供的个别服务。应用可以具有熟知ID，从而其它其它可以寻址它们。应用ID是可移植跨接处理器的限制值。应用ID和网络地址组合在一起形成应用的唯一地址。术语“远端网络地址”指的是把操作指向它的节点的地址。术语“近端网络地址”指的是指定给近端的地址。术语“始发者”指示动作是由传输层的用户先发起，还是由传输本身先发起。术语“优先级”指示用户数据的优先级。术语“协议描述符”指的是表示由用户数据中携带着什么样的更高级协议的标识符。术语“队列管理”指的是管理要接收指向特定应用ID的消息的队列。队列管理指向与队列的拥有者的应用ID有关的信息。术语“理由”指的是动作的理由代码。这是实现专用的。术语“用户数据”指的是发送的数据。它对传输层是透明的。请注意，传输层含有不与国际电信联盟(ITU)定义中的任何东西对应的原语。请参见上述文件“开放系统互连，传输服务定义，ITU-TX.214”。这是因为国际电信联盟(ITU)不含有设置传输服务访问点(TSAP)的原语。传输服务访问点大体上对应于应用ID。国际电信联盟(ITU)假定传输服务访问点通过一些其它手段登记，和信息适用于传输层。相反，UIPC传输层含有登记应用ID和根据它们建造路由表的附加原语。消息首标推荐根据传输层所需的操作，如下的信息应该是网络层消息首标的组成部分开始应用ID、终止应用ID、控制(用于传输层控制消息和指示消息的类型)。应用层本发明的UIPC不包括应用层协议。图6是根据本发明原理的、核实部件功能的测试方法。图6显示了黑箱(blackbox)测试。图6显示了根据本发明原理的、用于测试的可能配置。它依靠操作系统无关访问层(OIA)来抽象化操作系统调用，以便测试系统可以在工作站操作系统上运行。有两种进程在运行进程1(610)和进程2(612)。在每种进程中的是代表实时操作系统任务的线程。因为进程在独立的存储空间中运行，所以每个进程可以具有与别的进程无关地运行的UIPC事例。因此，它们可以是，每一个都具有它们自己的UIPC网络地址。任务1(614)、任务2(616)、和任务3(618)代表可以驱动UIPC应用程序接口(AIP)628和630的应用。UIPC任务620在进程1内部运行。UIPC任务622在进程2内部运行。UIPC应用程序接口在操作系统无关访问(OIA)层632和634上运行，并且适用于各种任务。UIPC把操作系统无关访问(OIA)层用于消息排队功能。为了模拟处理器间通信，使用了设备无关访问(DIA)层通信驱动器模拟器624和626。这些模拟器可以仅使用一些，如网络接口。它们也可以把错误注入，以核实协议管理错误。由于这是UIPC部件的测试，而不是设备无关访问(DIA)层的测试，因此，模拟器需要做的唯一事情是获得两个进程之间的消息。可以把图6推广到包括模拟不同类别路由器的其它进程。为了进行测试，可以对任务1-3编程，以运行UIPC应用程序接口的各种序列和自动核实结果。其它选择包括利用脚本或让用户界面执行各种命令。与它们如何驱动UIPC无关，这是从黑箱的视角来做的。对于UIPC来说，这些任务看起来与任何其它任务一样。虽然通过对本发明实施例的描述已经展示了本发明，并且，虽然已经相当详细地描述了这些实施例，但是，限于这样的细节，或者，无论以何种方式把所附权利要求的范围限于这样的细节都不是本申请人的意图。对于本领域的普通技术人员来说，其它各种优点和改进是显然的。因此，从更宽泛的方面来讲，本发明不限于所示的和所述的具体细节、典型的设备和方法、以及示范性的例子。于是，偏离这样的细节并不意味着偏离申请人一般性发明构思的精神内涵或范围。权利要求1.一种把消息数据从源传送到目的地的方法，该方法包括与通信设备的操作系统无关地发送消息数据，所述发送至少部分通过操作系统无关访问层进行；和与设备的硬件无关地传输消息数据，所述传输至少部分通过设备无关访问层进行。2.根据权利要求1所述的方法，设备形成用于机框间消息的共享总线布局。3.根据权利要求1所述的方法，设备形成用于机框间消息的星形总线布局。4.根据权利要求1所述的方法，还包括借助于设备的操作系统部分处理设备内的内部通信；和借助于设备的硬件部分处理与设备的外部通信。5.根据权利要求1所述的方法，还包括当源和目的地两者都在设备的第一机框上时，和当源在第一机框上和目的地在设备的第二机框上时，以及当源在第二机框的第一插件上和目的地在第二机框的第二插件上时，和当源在第一机框上和目的地在设备的外部和不在机框的任何一个上时，进行消息数据从源到目的地的所述传送。6.一种把消息数据从源传输到目的地的通信设备，该设备包括设备的操作系统部分，用于与所述设备的操作系统无关地处理所述设备内的内部通信；和设备的硬件部分，用于与所述设备中的硬件设备无关地处理与所述设备的外部通信。7.根据权利要求6所述的设备，还包括用于机框间消息的共享总线布局。8.根据权利要求6所述的设备，还包括用于机框间消息的星形总线布局。9.根据权利要求6所述的设备，还包括至少包括第一插件的第一机框；和至少包括第二插件和第三插件的第二机框；当源和目的地两者都在设备的所述第一机框上时，和当源在所述第一机框上和目的地在所述第二机框上时，以及当源在所述第二插件上和目的地在所述第三插件上时，和当源在所述第一机框上和目的地在设备的外部和不在机框的任何一个上时，所述设备进行消息数据从源到目的地的所述传输。10.一种在上面存储着一组指令的计算机存储介质，该组指令用于实现把消息数据从源传送到目的地的方法，该组指令包括用于执行下列步骤的一条或多条指令与通信设备的操作系统无关地发送消息数据，所述发送至少部分通过操作系统无关访问层进行；和与设备的硬件无关地传输消息数据，所述传输至少部分通过设备无关访问层进行。11.根据权利要求10所述的存储介质，设备形成用于机框间消息的共享总线布局。12.根据权利要求10所述的存储介质，设备形成用于机框间消息的星形总线布局。13.根据权利要求10所述的存储介质，还包括借助于设备的操作系统部分处理设备内的内部通信；和借助于设备的硬件部分处理与设备的外部通信。14.根据权利要求10所述的存储介质，还包括当源和目的地两者都在设备的第一机框上时，和当源在第一机框上和目的地在设备的第二机框上时，以及当源在第二机框的第一插件上和目的地在第二机框的第二插件上时，和当源在第一机框上和目的地在设备的外部和不在机框的任何一个上时，进行消息数据从源到目的地的所述传送。全文摘要与不同硬件和软件兼容的统一进程间通信系统和统一进程间通信方法。统一进程间通信系统可以与使用的通信方法无关地与任何设备一起使用。统一进程间通信(UIPC)方法是高度可移植的，因为UIPC方法把设备无关访问层(DIA)引入到系统中，并且把进程间通信与每个硬件设备松散地耦合起来。文档编号H04L29/08GK1404264SQ0211618公开日2003年3月19日申请日期2002年4月23日优先权日2001年9月4日发明者尹宁铉申请人:三星电子株式会社