在多群集网络中进行通信的方法、连接设备及网桥的制作方法

专利名称：在多群集网络中进行通信的方法、连接设备及网桥的制作方法
技术领域：
本发明涉及在多群集网络中进行通信的方法，例如，基于但不局限于HAVi群集，以及这种网络中的设备和用于连接群集的网桥设备。
背景技术：
HAVi-表示家庭音频/视频交互，目前定义在IEEE 1394总线(通过2000版本增强的1995版本)上(2001年5月15日发布的版本1.1)，并因而继承了对IEEE 1394的限制。一个限制是使用单群集网络。
这种HAVi网络难以遍布整个住宅，尽管家庭网络应当典型地连接家庭中的所有设备。需要的是连接几个不同的HAVi群集。
2002年11月21日以汤姆森许可贸易公司的名义递交的PCT专利申请EP02/013175和EP02/13179涉及一种利用GUID代理技术将HAVi网络与UPnP网络相连的网关。

发明内容
本申请描述了网桥设备和网络设备，尤其是在这些设备中实现的软件组件及其在多群集环境下的相互作用。
应当注意，不同的软件组件自身构成了独立的实体和发明，并可以针对每一个单独地要求保护。
本发明涉及一种网桥设备，包括至少两个接口，用于对网络中的各个网络设备群集进行接口，其中所述网桥设备包括用于连接群集的至少两个接口入口，其特征在于所述网桥设备，针对每个入口，包括第一软件组件，用于从内部客户端接收对至少一个网络设备的设备描述配置存储器数据的请求，所述第一软件组件适用于通过对其他设备中的类似软件的功能调用，从其他设备中得到设备描述数据。
根据本发明的实施例，所述第一软件组件适用于通过对去往远程群集设备的路径上的网桥设备的类似软件组件的功能调用，获得针对不具有类似软件组件的远程群集设备的数据。
根据本发明的实施例，所述第一软件组件适用于通过向位于与其相同的群集上的、不具有类似软件组件的设备发布介质相关请求消息，获得针对所述设备的数据。
根据本发明的实施例，所述第一软件组件适用于保持下述列表中的至少一个a)所述网络上的其他设备的第一软件组件的标识符列表；b)不具有类似第一软件组件的设备的列表，与去往所述列表中的设备的路径上的最近入口的相应标识符相关联。
根据本发明的实施例，所述第一软件组件适用于在其入口本地群集上监控不具有第一软件组件的设备的设备描述数据的变化，并在与所述网桥设备的其他入口相连的群集上产生相应的设备描述数据改变事件。
根据本发明的实施例，所述网桥设备，针对每个入口，还包括第二软件组件，用于使各个入口的入口的其他软件组件与入口群集的通信介质进行接口，所述第二软件组件包括应用程序可编程接口，其中至少特定的方法能够全局地访问所述网络的其他设备的软件组件，以便远程访问所述通信介质。
根据本发明的实施例，所述全局可访问的方法包括写入、读取、锁定、登记、丢弃、指示中的至少一个。
根据本发明的实施例，所述网桥设备，针对每个入口，还包括第三软件组件，用于保持所述网络的所有群集上的所有设备的列表。
根据本发明的实施例，所述第三软件组件适用于在检测到所述网络的任意群集上的变化时，产生第一事件，将所述变化的本质通知给其入口的软件组件。
根据本发明的实施例，所述第三软件组件适用于产生第二事件，用于只将事件发布入口的远程设备列表的状态通知给其他入口的第三软件组件。
根据本发明的实施例，所述第二事件包括好比是事件发布入口的远程设备，即，通过事件发布入口的共同入口能够到达的设备的潜在不完全列表。
根据本发明的实施例，所述第三软件组件适用于产生第三事件，用于通知所述群集上的所有设备的第三软件组件，主入口的远程设备列表稳定。
根据本发明的实施例，所述第三事件包括好比是事件发布入口的远程设备，即，通过事件发布入口的共同入口能够到达的设备的完全列表。
根据本发明的实施例，每个入口包括第四软件组件，用于向共同入口转发在入口的本地群集上检测到的事件消息。
根据本发明的实施例，每个入口包括第五软件组件，用于在网桥的群集之一上，接收来自另一设备的第五软件组件的请求；以及装置，用于向在它的其他群集上的第五软件组件转发所述请求，将初始请求者的标识符用作源地址，并将对此请求的非级联响应转发回初始请求设备。
根据本发明的实施例，每个入口包括第五软件组件，用于在网桥的群集之一上，接收来自另一设备的第五软件组件的请求；以及装置，用于向在它的其他群集上的第五软件组件转发所述请求，其中转发入口将转发入口的源地址作为参数添加到转发请求上，用于接收和级联对所述转发请求的响应，并用于将对此请求的级联响应转发回初始请求设备。
根据本发明的实施例，用于转发所述请求的所述装置适用于使用第一消息类型向网桥设备的第五软件组件转发请求，以及使用第二消息类型向非网桥设备的第五软件组件转发请求，其中所述转发入口的标识符是所述第一消息中的参数，而不是所述第二消息中的参数。
根据本发明的优选实施例，每个入口包括第五软件组件，用于在网桥的群集之一上，接收来自另一设备的第五软件组件的请求；以及装置，用于向在它的其他群集上的第五软件组件转发所述请求，将初始请求者的标识符用作源地址，用于截取对此转发请求的响应，用于级联这些响应的内容，并将对所述初始请求的单一级联响应发送回所述初始请求设备。
根据本发明的实施例，所述网桥设备包括装置，用于转换其群集的通信介质之间的分组的传送类型。
根据本发明的实施例，每个入口包括第六软件组件，用于在接收到来自另一设备的第六软件组件的连接建立请求时，针对跨越所述网桥的连接，建立本地群集上的连接段。
根据本发明的实施例，入口的所述第六软件组件适用于建立其本地群集上的连接，并通知其本地群集的下一入口，以执行去往连接端设备的路径上的下一段建立。
本发明的另一目的是一种多群集网络中的群集连接设备，其中群集通过网桥设备相连，每个网桥设备包括至少两个群集接口，其中将每个接口看作其相应群集上的网络设备，其特征在于所述网络设备包括第一软件组件，用于从内部客户端接收对至少一个网络设备的设备描述配置存储器数据的请求，所述第一软件组件适用于通过对至少一个其他设备中的类似软件的功能调用，从至少一个其他设备中得到设备描述数据。
根据本发明的实施例，所述第一软件组件适用于通过对去往远程群集设备的路径上的网桥设备的类似软件组件的功能调用，获得针对不具有类似软件组件的远程群集设备的数据。
根据本发明的实施例，所述第一软件组件适用于通过向位于与其相同的群集上的、不具有类似软件组件的第二设备发布介质相关请求消息，获得针对所述第二设备的数据。
根据本发明的实施例，所述第一软件组件适用于保持下述列表中的至少一个a)所述网络上的其他设备的第一软件组件的标识符列表；b)不具有类似第一软件组件的设备的列表，与去往所述列表中的设备的路径上的最近入口的相应标识符相关联。
根据本发明的实施例，所述设备还包括第三软件组件，用于保持所述网络的所有群集上的所有设备的列表，其中所述第三软件组件包括装置，用于从与其本地群集相连的入口获得远程设备列表，以及用于将远程设备列表与本地群集设备列表相级联。
根据本发明的实施例，所述第三软件组件还适用于在网络设备列表中保持在好比是设备自身的本地群集的远程设备的路径上的最近入口的指示。
根据本发明的实施例，所述设备包括第五软件组件，用于从本地客户端接收对远程软件组件的列表的请求，以及用于只向所述本地群集的设备的第五软件组件转发所述请求。
根据本发明的实施例，所述设备包括第六软件组件，所述第六软件组件包括针对相同设备的客户端的应用程序可编程接口，适用于接收用于建立宿设备和源设备之间的连接的请求，所述第六软件元件适用于在源和宿设备之间的路径上，确定在去往宿设备的路径上距源设备最近的入口，并向该入口发送适当的请求，以建立其本地群集上的连接，并用于向该路径上的其他适当的入口传播此请求。
应当注意，网桥的入口也是其本地群集上的设备。
本发明的另一目的是一种用于发现网络中的设备的方法，所述网络包括至少两个设备群集和至少一个网桥，其中至少两个群集通过网桥相连，每个网桥包括至少两个接口入口，用于连接相应群集，所述方法包括以下步骤-使每个入口获得其本地群集的设备的标识符列表；-使每个入口请求来自与其相同的群集的每个入口的远程设备列表；-使每个入口通过从其共同入口请求其本地设备和通过共同入口能够达到的远程设备的列表，构建其自身的远程设备列表。
根据本发明的实施例，所述方法还包括以下步骤如果网桥位于到给定设备的最短路径上，则使所述网桥通过以所述给定设备为目的地的消息。
根据本发明的实施例，所述最短路径是具有最少数目的要跨越入口的路径。
本发明的另一目的是一种建立网络中的源设备和宿设备之间的连接的方法，所述网络包括通过网桥设备相连的多个设备群集，其中每个网桥设备包括用于连接群集的接口入口，所述方法的特征在于以下步骤(a)在网桥的入口中以及网络的其他网桥感知设备中设置流管理器软件组件；(b)在设备的流管理器软件组件级，从来自本地客户端的连接接收请求；(c)在宿设备和源设备之间的路径上，标识距源设备最近的入口，并向该入口发送连接请求；(d)使接收到所述连接请求的入口建立源设备和入口的网桥之间的连接段；(e)使接收到所述连接请求的入口使其网桥的下一入口在去往所述源设备的路径上建立入口的本地群集上的下一连接段；(f)如果存在，标识去往宿的路径上的下一网桥，指示位于去往宿设备的路径上的下一网桥的远程入口建立适当的连接段；(g)返回步骤(e)，直到建立去往宿的连接段。


在对本发明的优选实施例的描述中，本发明的其他特征将显而易见。本发明并不局限于实施例。将借助于附图对实施例进行描述。
图1是多群集HAVi网络的示意图；图2是HAVi-HAVi网桥的示意图；图3是示出了使用SddManager的不同情况的网络示意图；图4是示出了使用CMM的示例的多群集HAVi网络的示意图；图5是示出了通过网桥发送消息的示意图；图6是表示事件发布算法的示意图；图7是表示针对登记处的业务改善的示意图；图8是表示针对网桥登记处的请求/响应算法的示意图；图9是现有技术的HAVi流连接模型的示意图；图10是示出了多群集流构建的示意图；
图11是示出了针对数据的可选路由的多群集网络示意图；图12是HAVi网桥感知设备的软件结构的示意图；图13是示出了本地发现方法的多群集网络示意图；图14是示出了叶节点网桥上的第一远程列表更新的多群集网络示意图；图15是示出了网桥网络管理器相互作用的多群集网络示意图；图16是示出了用于构建网络管理全局列表的方法的示意图；图17是示出了对网络管理器的客户端调用的多群集网络示意图；图18是示出了远程列表概念的多群集网络示意图；图19是示出了新设备的连接的示意图；图20是示出了更新远程列表的传播的示意图；图21是具有环路的网络中的本地发现方法的示意图；图22是示出了入口根据其请求远程列表的方法的示意图；图23是示出了以不完全远程列表进行入口更新的方法的示意图；图24是示出了利用事件发送不完全远程列表的示意图；图25是包括两个HAVi群集和利用GUID代理技术的网桥的网络的示意图。
具体实施例方式
一种用于桥接两个HAVi群集的方法基于软件组件代理方案。图25是由通过网桥设备链接的两个HAVi群集形成的网络的示例。以分别被称为设备控制模块(DCM)和功能组件模块(FCM)的软件组件表示设备和子设备或功能。
HAVi设备发现方法基于IEEE 1394总线上的‘GUID’识别。GUID表示全局惟一标识符。GUID惟一地标识了IEEE 1394设备。
网桥一侧的设备将不会由网桥另一侧的设备识别，因为其在IEEE1394级是不可见的。一侧的控制器将不能使用另一侧的目标。网桥设备构建一侧DCM和FCM的代表，以便将其作为DCM和FCM暴露给另一侧，作为其所代表的真实软件组件的代理组件。
在图25中，以其SEID(软件组件ID)表示真实的DCM和FCM。SEID是GUID(在每个设备的底部示出了示例)和该设备内部惟一的号码的组合。
将这些DCM和FCM通过代理SE(软件组件)表示在网桥的另一侧。以虚线示出，以便将其与真实的SE区别。针对每个真实的DCM和FCM，有一个代理SE。控制应用程序可以通过其代理SE控制网桥后面的真实目标设备。
本发明的本实施例将基于使用GUID代理的入口和网桥。但是，本发明并不局限于此特定的情况。此外，尽管HAVi 1.1是基于IEEE1394的，但本实施例的群集可以基于其他网络技术，尤其是基于因特网协议(IP)或无线技术(IEEE 802.11、Hiperlan 2…)。在本实施例中，作为示例，这些灵活性通过使用GUID代理技术实现。在本发明的优先权日可用的最新的HAVi版本是版本1.1。HAVi 1.1并未描述网桥，所以如果HAVi 1.1设备与多群集网络相连，其将不能感知任何网桥。
本申请首先描述了HAVi网桥设备，然后，描述HAVi网桥感知设备，即，能够利用网桥设备的资源并与之通信的设备。由于网桥对于HAVi 1.1设备不是透明的，可能会需要这种设备。
I]网桥设备图1示出了包括通过两个网桥104和105按照串联方式互连的三个群集101到103的网络。群集101基于IEEE 1394，群集102基于IP技术，而群集103是基于如IEEE 802.11的无线网络。例如，群集102上的设备可以是HAVi设备，或是网桥针对其管理HAVi代理表示的UPnP设备。
根据本实施例的GUID代理解决方案的原理在于，在本地群集上，通告位于本地群集外部的设备的GUID，从而本地HAVi设备得知它们的存在。一旦知道了远程设备的远程GUID，则此设备就可以通过HAVi软件组件进行寻址，因为消息发送系统在其内部表中知道必须向哪个设备发送HAVi消息。当向远程设备发送HAVi消息时，其目的地地址为代理GUID的地址。网桥适当地传递来自基于被代理GUID的HAVi中间件和HAVi适用模块(DCM、FCM、应用程序)的消息。
在图2中示出了HAVi-HAVi网桥的软件体系结构。尽管多于两个入口也是可能的，其由根据本实施例的两个入口构成。每个入口与HAVi群集(例如，IEEE 1394-1995总线)相连，并为其群集上可寻址的实体。完全的HAVi栈涉及网桥。HAVi模块是否仿真其自身的两种实例或者两个独立的模块是否针对相同的功能性同时运行是与实现相关的。尽管从功能上将每个入口存在一个消息发送系统，在图2中，只示出了一个消息发送系统。利用驻留在其中的节点的GUID寻址软件组件——且消息发送系统是软件组件，并且每个入口拥有其自己的GUID。
a)SddManager自描述设备数据(SDD)是HAVi设备向其他设备提供与其自己相关的信息(设备类型、容量、版本等)的手段。在HAVi-1.1中，SDD是IEEE 1394 HAVi.设备的配置ROM(包含如GUID等其他信息)的一部分，并由其他设备利用直接IEEE 1394读取事务进行读取。
这对于单一IEEE 1394群集较好，但当HAVi网络是多群集的，且构建在不同的介质技术上时，这种读取事务是不足够的。于是，所需的是读取网络上的任意HAVi设备的SDD数据的手段。这可以通过HAVi消息来实现。根据本实施例，软件组件可以利用消息发送系统来访问HAVi设备的SDD数据。为了向任意群集上的任意客户端提供所请求的SDD数据，在HAVi栈中定义了应用程序专用接口(API)。
SddManager是一种新的系统软件组件，其在本地处理对SDD数据的请求和收集来自远距离SddManager的响应方面，具有与登记处的相似性，而与登记处之间的不同在于登记处存在于具有中间功能性(IAV)和完全功能性(FAV)的所有设备上，而在任意根据本实施例的网桥感知HAVi设备上实现SddManager。网桥感知设备是FAV或IAV类型的(完全A/V设备或中间A/V设备)。在HAVi 1.1或更低版本的设备上不存在SddManager。因此，具有SddManager的设备将与不具有SddManager的设备共同存在于相同的群集上。这意味着HAVi设备中的客户端应用程序或软件组件将优选地调用其本地SddManager用于所有请求，并且本地SddManager将负责收集所有信息(向其他SddManager发送查询和/或进行本地低级操作)。如果在设备上没有本地SddManager，则客户端将不得不通过其他手段获得信息。在后一种情况下，客户端运行在不具有网桥知识的HAVi-1.1设备上。然后，其只能访问本地IEEE 1394群集设备。
根据本实施例，客户端执行以下处理，以获得SDD数据if(local SddManager exists)(301，302，303)call the local SddManagerelse//(i.e.the device is not a bridge aware device)(304)use local API(e.g.CMM1394)to retrieve the SDD dataof the local cluster device//it canbe only the local clusterhere换句话说，客户端应用程序优选地适用于在具有SddManager的设备上和不具有SddManager的设备上进行操作。
根据本实施例，SddManager对其从由其他SddManager通知的事件中获得的SDD数据信息进行高速缓存。这允许减少网络上的业务量，并减少做出请求时从SddManager到客户端的响应时间。高速缓存集中在SddManager中，并不必由相同设备上的几个客户端冗余地进行。
在SddManager级，执行以下处理if(query from a client concerns local data only(i.e.in the samedevice))send responseelseif(remote SddManager exists for the target device to be queried)(301)call the remote SddManagerelseif(target device is on the local cluster)(303) use local API(e.g.CMM1394)to retrieve the SDD dataelse//i.e.the target device is not bridge aware and noton the local cluster(302)call the SddManager or the bridge exit portal换句话说，如果从客户端接收到的查询并不是只涉及本地可用数据，则SddManager首先检查要获得针对其的SDD数据的目标设备是否包含SddManager，并在包含的情况下，调用目标的SddManager。否则(即，目标设备不具有SddManager)，其检查目标设备是否在本地群集上，并使用如通信介质管理器等本地API获得数据(例如，用于IEEE1394的CMM 1394)。对于远程非网桥感知目标设备，向本地群集的退出入口的SddManager转发请求。
图3示出了针对以上述两个处理表示的不同情况的消息序列。参考数字对应于在上述两种处理中所给出的步骤。
优选地，SddManager存储(本地和远程)网络上所有其他SddManager的列表，并针对不具有SddManager的设备，存储最近入口的GUID(如下所述，由网络管理器提供)，以向其发送查询。
SddManager提供以下服务

在本实施例中，SddManager具有以下数据结构(a)DeviceProfile定义struct DeviceProfile{DeviceClass deviceClass；boolean withDcmManager；boolean withStreamManager；boolean withResourceManager；boolean withDisplayCapability；boolean deviceActive；
booleanbridge；}；描述此结构在HAVi_Device_Profile类下存储在IEEE 1394配置ROM中找到的值(HAVi-1.1规范，458页)。
deviceClass参数给出了设备的类型(FAV、IAV、…)。如果该模块出现在该设备中，则withXxxManager布尔值为真。withDisplayCapability表示对于IAV，DDI控制器是否出现，以及对于FAV，DDI控制器和级2UI(用户接口)是否出现。如果该设备有效，则deviceActive布尔值为真。bridge参数表示该设备是否为网桥。
(b)Vendor定义struct Vendor{VendorIdvendorId；//definedinHAVi-1.1 p110DeviceManufacturer vendorText； //defined inHAVi-1.1 p149}；描述与制造商有关的信息。最大字符数为50，以UNICODE UTF-16在2个字节上进行编码，所以最大尺寸为100字节。
(c)Model定义struct Model {ModelIdmodelId；//defined in HAVi-1.1p200DeviceModelmodelText； //defined in HAVi-1.1p149}；描述此结构给出了与模型有关的信息。最大字符数为50，以UNICODEUTF-16在2个字节上进行编码，所以最大尺寸为100字节。
(d)DcmProfile定义struct DcmProfile {uinttrans ferredDcmCodeUnitSize；uintinstalledDcmCodeSpace；uintinstalledDcmWorkingSpace；Version MessageVersion；//defined inHAVi-1.1 p110}；描述此结构包含与DCU有关的信息。这些字段与HAVi-1.1规范在第9.10.7节460页中定义的相同。
(e)SddData定义struct SddData {Version version；//definedin HAVi-1.1 p110DeviceProfile deviceProfile；Vendor vendor；Modelmodel；UserPreferredName userPreferredName；//defined in HAVi-1.1 p150DeviceIcon deviceIcon；//definedin HAVi-1.1 p158DcmProfile dcmProfile；sequence<octet>dcmReference；}；描述此结构提供了与HAVi设备有关的信息。其基本上是与HAVi-1.1规范的IEEE1394配置ROM SDD部分中相同的信息。对于与这些字段有关的详细信息，参见HAVi-1.1规范第9节。注意，在设备配置文件(profile)中添加了一比特，网桥比特，由deviceProfile结构体中的网桥布尔值表示。此数据块用于表示HAVi设备是否为网桥。还应当注意，dcmProfile和dcmReference仅针对BAV设备是有效字段。
SddManager的应用程序可编程接口(API)如下SddManager∷GetSddData原型Status SddManager∷GetSddData(in GUID guid，outSddData sddData)参数■guid-客户端想要获得针对其的SDD数据的GUID。
■sddData-指定GUID的SDD数据。
描述此方法获得针对由其GUID指定的给定HAVi设备的SDD数据。如果GUID是本地设备(客户端的主机)的GUID，则本地SddManager与相应的SDD数据一起发送响应。如果GUID是远程设备的GUID，则本地SddManager负责获得远程SDD数据。根据上面已经展示的处理来完成。
错误代码■SddManager∷EUNKNOWN_GUID-GUID未知。
■SddManager∷ENOT_READY-当前正在更新SDD数据。客户端可以稍后再试。
■SddManager∷ELAV-指定的GUID是LAV设备，所以不具有SDD数据。
SddManager使用以下事件SddDataChanged原型void SddDataChanged(in GUID guid，in SddDatasddData)参数■guid-已经改变了SDD数据的设备的GUID■sddData-新SDD数据。
描述本事件用于将由GUID指定的设备的SDD数据的变化通知给网络上的设备。作为SddManager的主机的设备可以提供针对其本地SDD数据的这种事件。
网桥设备可以通过检测到具有改变后的SDD的设备的本地入口上的SDD数据变化(例如，通过针对IP群集的组播消息)并向其他入口的SddManager传输信息，来提供针对不具有SddManager的远程设备的SDD数据的事件。
在这种情况下(当网桥传播针对不具有SDD管理器的设备的事件时)，包括不具有SddManager的设备的群集的所有入口将向其自身的共同入口传输该事件，而其共同入口将依次远程地转发该事件，根据已知的SDD处理(针对IEEE 1394网络的总线复位和配置ROM读取，针对IP网络的组播分组的发送)更新本地群集。例如，不具有SDDManager的设备可以是如基本(BAV)非IEEE 1394设备的HAVi 1.1设备。对于遗留设备(LAV)，并不存在问题，因为其不具有SDD数据。
如下执行IEEE 1394配置ROM增强为了与SddManager结构体的定义相一致，在IEEE 1394 HAVi设备的配置ROM中增加新的字段，如下。
此HAVi_Device_Profile是IEEE 1394配置ROM的24比特立即值(如IEEE 1212所规定的那样)字段，已经包括·HAVi_Device_Class[bit 0...3]
·HAVi_DCM_Manager[bit 4]·HAVi_Stream_Manager[bit 5]·HAVi_Resource_Manager[bit 6]·HAVi_Display_Capability[bit 7]·HAVi_Device_Status[bit 8]·Bits 9...23保留在比特9中增加新的字段HAVi_Bridge是1比特立即值字段，针对IAV/FAV设备规定了此设备是否为HAVi网桥。对于BAV，此比特应当为0。
HAVi_Bridge值 含义0 不是网桥1 是网桥b)通信介质管理器现在，对网桥入口的修改后的通信介质管理器(CMM)进行描述根据本实施例，网桥的CMM(事实上为每个入口的CMM，由于每个网桥有几个CMM)的API，对于其API/方法中的至少一些是全局可访问的，代替了只能由主机设备的元件组件进行访问(即，本地可访问性)。这对于每类CMM都是有效的。此后，将描述针对基于IEEE 1394的设备的CMM(CMM1394)和针对基于IP设备的CMM(CMMIP)，由于其存在于网桥设备中。
CMM1394 API为服务通信 局部性由(目的地)访问/针对类型 事件由(目的地)发送Cmm1394∷GetGuidListM 本地 全部Cmm1394∷Write M 本地 信任网桥中全局
PC041008Cmm1394∷ReadM本地 信任网桥中全局Cmm1394∷LockM本地 信任网桥中全局Cmm1394∷EnrollIndicationM本地 信任网桥中全局Cmm1394∷DropIndication M本地 信任网桥中全局<Client>∷Cmm1394Indicatio MB 本地 CMM1394(信任)n 网桥中全局NewDevices E本地 CMM1394(全部)GoneDevices E本地 CMM1394(全部)NetworkReset E本地 CMM1394(全部)GuidListReadyE本地 CMM1394(全部)CMMIP API如下服务通信类型 局部性 访问Cmmlp∷GetGuidList M本地 全部Cmmlp∷GetlpAddress M本地 信任网桥中全局Cmmlp∷GetGuid M本地 信任网桥中全局Cmmlp∷Send M本地 信任网桥中全局Cmmlp∷EnrollIndication M本地 信任网桥中全局Cmmlp∷DropIndicationM本地 信任网桥中全局<Client>∷CmmlpIndicationMB 本地 CMMIP(信任)网桥中全局
NewDevicesE本地CMMIP(全部)GoneDevices E本地CMMIP(全部)ChangedDevicesE本地CMMIP(全部)GuidListReady E本地CMMIP(全部)ProxyGuidCreated E全局CMMIP(CMMIP)enroll和drop API允许远程HAVi软件组件从CMM的入口的网络本地的设备接收低级消息。‘send’API(针对IP的send，针对IEEE1394的read-write-lock)允许向远程群集上的特定设备发送消息。例如，这些装置可以由通过远程安装的设备控制模块(DCM)使用，以便通过一个或多个网桥，与其受控设备进行通信。
想要使用远程CMM(即，不位于与其相同的设备中)的HAVi SE必须知道由远程CMM使用的链接技术，即，其必须知道上述API。
由HAVi SE使用的处理是·发现远程CMM技术，通过以软件组件类型属性值0x00000001(即，通信介质管理器)查询本地登记处(其向远程登记处发送查询)，并获得远程CMM的SEID。根据本实施例，此SEID的软件句柄(swHandle)部分给出CMM的类型(针对CMM1394的0x0001、针对CMMIP的0x0009…·如果SE知道如何处理相应的链接技术，则其可以使用CMM。例如，其必须能够根据该技术，规定要发送给远程设备的消息的内容。
图4示出了其GUID等于1的设备的软件组件指示网桥的远程CMMIP向GUID等于3的远程IP设备发送IP消息的示例。
总之，至少使网桥入口的CMM的特定的功能能够由除了CMM自身设备本地的客户端以外的其他客户端访问，尤其是，为了允许这些客户端使用CMM的API，以便直接在不同的网络技术上进行通信，例如，发送低级消息等。
c)设备发现/网络管理器根据本实施例，创建网络管理器软件组件，以提供与连接于整个HAVi网络的所有设备有关的信息。CMM提供与其本地群集相连的GUID列表。网络管理器能够给出整个多群集网络的GUID列表，包括本地群集。每个入口中都存在网络管理器。优选地，网络管理器也出现在网桥感知设备中。
由网络管理器提供以下服务服务 通信类型 局部性访问/对于事件(消息或 发送方(接收事件) 方)NetworkManager∷GetNetDeviceListM 本地 全部NetworkManager∷GetNetDeviceInfoM 全局 全部NetworkManager∷NetworkUpdated E 本地 网络管理器(全部)NetworkManager∷GetRemoteDeviceList M 全局 网络管理器NetworkManager∷RemoteNetworkChangedE 全局 网桥中的网络管理器(网桥中的网络管理器)NetworkManager∷RemoteNetworkUpdatedE 全局 网络管理器(向所有网络管理器发送)表7网络管理器数据结构如下(a)ClusterType定义enum ClusterType {IEEE1394，IP}；描述ClusterType提供了与特定群集上所使用的技术有关的信息。根据本实施例，定义了两种群集技术1394(HAVi-1.1)和IP，但也可以容易地添加其他技术。
(b)NetDeviceInfo定义
struct NetDeviceInfo {GUID deviceGuid；uint hops；GUID nearestPortalGuid；ClusterType clusterType；}；描述NetDeviceInfo结构提供了与设备有关的信息，而无论其在网络中的位置，即其提供GUID本身、到达其的跳数(由网络管理器使用来解决环路问题，如稍后所述)、到达此设备1的最近入口的GUID及其与之相连的群集的类型。最后两项允许客户端到达其最近入口上的CMMXXX，以便访问远程群集的低级特征，并向远程设备发送低级消息。
(c)RemoteNetworkState定义enum RemoteNetworkState {STABLE，CHANGING，FINAL}；描述RemoteNetworkState提供了与入口后面的远程网络(即，位于包括网络管理器的入口后面的群集)的状态有关的信息。STABLE表示入口的远程群集设备列表是稳定的，且其他网络管理器可以依赖其。CHANGING表示远程列表仍在进行修改。FINAL表示远程列表应当是稳定的，但需要群集的其他入口的确认(详见，行为发现处理)。
网络管理器API如下(a)NetworkManager∷GetNetDeviceList原型Status NetworkManager∷GetNetDeviceList(out uint updateId，outsequence<NetDeviceInfo>activeNetDeviceList，out sequence<NetDeviceInfo>nonactiveNetDeviceList)参数■updateId-网络的更新号码。每次改变列表时，此号码递增1，其可以由客户端使用来检查网络是否保持相同。
■activeNetDeviceList-网络上的所有有效设备(activedevice)的列表。第一项应当为本地设备。
■nonactiveNetDeviceList-网络上的所有非有效设备(non-active)的列表。
描述此API返回整个网络上的所有设备的列表，分为有效设备列表和无效设备列表。在NetDeviceInfo结构中包含与每个设备有关的信息。这给出了设备的GUID、到达其最近的入口的GUID和其所依附的群集的类型。例如，在图4中，SE获得GUID 3，得知其群集是基于IP的，且到达其的最近入口是GUID 6，所以其可以向其GUID等于6的设备的CMMIP发送CmmIp∷Send HAVi消息。
错误代码■NetworkManager∷ENOT_READY-列表仍不可用，系统可能正在对其进行更新。这是一种瞬时错误，客户端软件组件可以重试或使用NetworkUpdated事件。
(b)NetworkManager∷GetRemoteDeviceList原型Status NetworkManager∷GetRemoteDeviceList(out uint updateId，out sequence<NetDeviceInfo>activeRemoteDeviceList，out sequence<NetDeviceInfo>nonactiveRemoteDeviceList)
参数■updateId-网络的更新号码。每次改变列表时，此号码递增1，其可以由客户端使用来检查网络是否保持相同。
■activeNetDeviceList-此网桥后面的网络上的所有有效设备的列表。
■nonactiveNetDeviceList-此网桥后面的网络上的所有非有效设备的列表。
描述此API返回在包括网络管理器的网桥后面的网络上的所有可到达设备的列表，分为有效设备列表和无效设备列表(有效设备为准备好接收消息的设备，如设备的SDD数据所规定的那样，针对IAV和FAV的HAVi，专用于BAV)。在NetDeviceInfo结构中包含与每个设备有关的信息。这给出了设备的GUID、到达其的退出入口的GUID、跳数、最近入口和其所依附的群集的类型。在本实施例中，将对此API的访问限制于网络管理器。由设备(网桥或非网桥)的网络管理器使用，查询网桥设备的远程设备列表，并因而构建其内部表，并解决环路问题。根据变体，使API对于其他软件组件也是可用的。
错误代码■NetworkManager∷ENOT_READY-列表仍不可用，系统可能正在对其进行更新。这是一种瞬时错误，客户端软件组件可以重试或使用RemoteNetworkChanged事件(只针对网桥设备的网络管理器)和RemoteNetworkUpdated事件(针对所有网络管理器)。
(c)NetworkManager∷GetNetDeviceInfo原型Status NetworkManager∷GetNetDeviceInfo(in GUID guid，out NetDeviceInfo deviceInfo)参数■guid-客户端想要与其有关的一些信息的GUID。
■deviceInfo-与此设备有关的信息，即，相应的NetDeviceInfo结构体。
描述此API提供了与给定网络设备有关的完整信息。网络管理器返回NetDeviceInfo结构。
错误代码■NetworkManager∷EUNKNOWN_GUID-GUID未知。
根据本实施例，网络管理器事件如下(a)NetworkUpdated原型void NetworkUpdated(in uint updateId，insequence<NetDeviceInfo>activeNetDeviceList，insequence<NetDeviceInfo>nonactiveNetDeviceList，in sequence<GUID>changedDevices，in sequence<GUID>goneDevices，in sequence<GUID>newDevices)参数■updateId-网络的更新号码。每次改变列表时，此号码递增1，其可以由客户端使用来检查网络是否保持相同。
■activeNetDeviceList-整个HAVi网络上的有效设备的列表。第一项应当为本地设备。
■nonactiveNetDeviceList-整个HAVi网络上的非有效设备的列表。
■changedDevices-改变了跳数和最近入口的GUID的列表。
■goneDevices-离开网络的GUID的列表。
■newDevices-加入网络的GUID的列表。
描述NetworkUpdated是本地事件，发送给作为网络管理器的主机的设备的软件组件。当在HAVi网络上某处存在变化(无论什么群集)时，即，在网络管理器从与其本地群集相连的网桥接收到一个或多个RemoteNetworkUpdated事件之后(远程变化)，或在其本地群集上的变化之后，产生此事件。在重新配置期间，网络管理器可以返回针对NetworkManager∷GetNetDeviceList API的NetworkManager∷ENOT_READY，直到NetworkUpdated。activeNetDeviceList和nonactiveNetDeviceList内容的定义与NetworkManager∷GetNetDeviceList API中所定义的相同。changedDevices，goneDevices和newDevices字段只提供GUID，因为在旧设备列表中，离开的设备是已知的，而在新设备列表中为新的改变后的设备提供了完整的信息。
根据变体实施例，如果相同群集上的其他设备不具有网络管理器，则使此事件能够由驻留在这些设备中的软件组件访问。
(b)RemoteNetworkUpdated原型void RemoteNetworkUpdated(in uint updateId，in sequence<NetDeviceInfo>activeRemoteDeviceList，in sequence<NetDeviceInfo>nonactiveRemoteDeviceList，in sequence<GUID>changedDevices，in sequence<GUID>goneDevices，in sequence<GUID>newDevices)参数■updateId-网络的更新号码。每次改变列表时，此号码递增1，其可以由客户端使用来检查网络是否保持相同。
■activeNetDeviceList-整个HAVi网络上的有效设备的列表。
■nonactiveNetDeviceList-整个HAVi网络上的非有效设备的列表。
■changedDevices-改变了跳数和最近入口的GUID的列表。
■goneDevices-离开网络的GUID的列表。
■newDevices-加入网络的GUID的列表。
描述RemoteNetworkUpdated是只针对网络管理器的全局事件。当网络管理器已经检测到其正在针对其本地群集而代理的部分网络中的变化时，以及当网络被认为是稳定的时，产生此事件(与下一事件相反，仅向网桥网络管理器发送，并在列表的状态还未稳定时使用)。因为网络管理器共同入口群集上的改变或因为由与其共同入口相连网桥转发的改变，此事件可能发生。在重新配置期间，网络管理器可以返回针对NetworkManager∷GetNetDeviceList API的NetworkManager∷ENOT_READY，直到RemoteNetworkUpdated。activeRemoteDeviceList和nonactiveRemoteDeviceList内容的定义与NetworkManager∷GetRemoteDeviceList API中所定义的相同。changedDevices，goneDevices和newDevices字段只提供GUID，因为在旧设备列表中，离开的设备是已知的，而在新设备列表中为新的改变后的设备提供了完整的信息。
(c)RemoteNetworkChanged原型void RemoteNetworkChanged(in RemoteNetworkState state，in uint updateId，insequence<NetDeviceInfo>activeRemoteDeviceList，insequence<NetDeviceInfo>nonactiveRemoteDeviceList，in sequence<GUID>changedDevices，in sequence<GUID>goneDevices，in sequence<GUID>newDevices)参数■state-远程网络的状态，这对于以远程列表迭代来解决环路问题是有用的。
■updateId-远程网络的更新号码。每次改变列表时，此号码递增1，其可以由客户端使用来检查远程网络是否保持相同。
■activeNetDeviceList-整个HAVi网络上的有效设备的列表。
■nonactiveNetDeviceList-整个HAVi网络上的非有效设备的列表。
■changedDevices-改变了跳数和最近入口的GUID的列表。
■goneDevices-离开网络的GUID的列表。
■newDevices-加入网络的GUID的列表。
描述RemoteNetworkChanged是只以网桥设备的网络管理器为目的地的全局事件。其与RemoteNetworkUpdated事件相同，但在其重新配置步骤期间，此事件由网桥设备中的网络管理器使用。在这些步骤期间，在达到稳定的网络状态(尤其是，如果出现环路)之前，可以产生几个事件。这避免了因为网络仍未稳定而向网桥感知设备发送不会被使用的消息。此字段的含义与针对RemoteNetworkUpdated事件的含义相同。
根据以上描述，在根据本实施例的网桥之间的发现处理如下目的在于发现所有与HAVi网络相连的设备。一旦完成，每个入口中的‘远程’设备列表给出与通过其自身能够达到哪些设备有关的信息。尽管IEEE 1394.1拓扑通过屏蔽(mute)网桥而打开环路，但本实施例中，与环路有关的行为却不同。根据本实施例，网桥可能对于特定的路径是可通过的，而对其其他路径则不行，所以当环路存在时，并不将网桥全部屏蔽，而是如果其位于去往由GUID标识的设备的特定路径上，其将提供其远程列表中的这些GUID。根据以下所解释的特定标准来决定是否通过网桥。在本实施例中，跳数反映出为了到达目的地而跨越的入口数，而不是网桥数。由于可以通过其共同入口而不是通过其群集到达入口，所以做出这种选择(即，尽管对于群集上的非入口设备，将不得不完全跨越网桥，但对于去往入口的消息也不必跨越整个网桥)。
基本发现处理如下每个本地群集执行其自身的本地发现处理。其自身所知的针对IEEE 1394群集的发现处理是基于IEEE 1394总线复位的，包括利用‘selfID’分组的拓扑信息传播。
一旦此阶段完成，CMM1394读取所有节点的配置ROM，以获得其GUID。(如果出现)读取SDD数据以获得与相连设备有关的HAVi定义消息。
其自身所知的针对IP群集的发现处理是基于组播通告分组的。
根据本实施例的CMMIP根据这些通告，构建其GUID列表，例如，当新设备与群集相连时，出现这些通告。在这些分组中也包含SDD数据。
在这一点上，本地GUID列表和SDD数据对于两种群集类型都是已知的，因而群集的网络管理器知道出现在其本地群集上的网桥设备。
为了构建完整的网络设备列表，网络管理器开始彼此查询。
根据本实施例的处理为(1)网络管理器查找其群集上的网桥。
(2)网桥设备的网络管理器调用与其本地群集相连的其他网络的入口的NetworkManager∷GetRemoteDeviceList API。这些被查询入口的共同入口应当构建了其网络侧的设备的列表。
(3)网桥设备的网络管理器(通过HAVi消息，或者根据优选实施例，通过网桥内部信息共享等)从其共同入口获得将成为其自身的远程设备列表的列表。当共同入口已经调用了与其自身的群集相连的其他网桥设备的NetworkManager∷GetRemoteDeviceList API时，共同入口能够提供此列表。
(4)网桥感知(BA)设备的网络管理器调用与其本地群集相连的网桥设备的NetworkManager∷GetRemoteDeviceList API。这样构建了其完整网络GUID列表。
HAVi SE调用其本地网络管理器的NetworkManager∷GetNetDeviceList API。
如果在所请求的信息可用之前进行此步骤，则可以返回ENOT_READY错误，并且客户端将必须等待。根据本实施例，步骤1和2实际上并行进行，所以提出了避免死锁问题的机制。设备列表构建处理从拓扑的叶节点群集进行到根节点群集(至少针对不具有环路的网络)。
发现规则如下将以下规则应用于发现处理。根据远程网络状态，即‘改变中’、‘最终’或‘稳定’对其进行分类。此外，存在一些普通规则，无论任何状态。因此，将规则分类为“G”、“C”、“F”和“S”类。


表8
上述处理包括确保直通的步骤，如果需要，包括适当地解决冗余路径冲突的迭代处理。为此，定义了三种可能的状态——改变中、稳定和最终。利用RemoteNetworkChanged事件中的RemoteNetworkState数据结构，传播与这些状态有关的信息。
根据变体实施例，在此发现处理中实现超时处理，以便避免使较慢的网桥在能够应答之前被来自其他网桥的大量事件冲击。
(d)消息发送根据HAVi规范，从一个软件组件向另一个软件组件发送HAVi消息。通过SEID(软件组件标识符)来标识软件组件。此SEID由软件组件驻留在其中的设备的GUID和该设备内惟一的swHandle构成。HAVi消息的报头包含目的地SEID和源SEID。
在本实施例中，网桥设备并不修改HAVi消息(这里所称的HAVi消息不包含TAM报头)。目的地SEID、源SEID、协议类型、消息类型、消息号码、消息长度和消息体字段保持不变。但是，消息发送系统将消息路由到目的地。为此，当网桥中的消息发送系统在群集上接收到HAVi消息时，其查看目的地SEID，更精确地，查看包含在此SEID中的GUID。如果此GUID是其自身的GUID，则此消息是针对内部SE的，并传递该消息。如果此GUID出现在其远程GUID列表中，则其将此消息转发到其共同入口(或者适当的共同入口，如果存在多于一个共同入口的话)。然后，共同入口将向相应的目的地设备(考虑其内部表)发送此消息。此设备可以是最终目的地设备或者是路径上的下一个网桥。
对于消息发送系统的普通行为，并未发生任何改变·消息号码仍然遵循HAVi-1.1规范第3.2.1.2.3节第29页中的规则。对于消息的最初发送方和最终接收方也是如此。位于路径上的网桥中的消息发送系统并不关心HAVi消息内部是什么，而只是对其进行转发。
·只发送‘简单’消息(即，不要求确认)，而不要求确认。
·发送‘可靠’消息，并阻止调用方，直到接收到肯定或否定确认(Ack或Nack)为止。对于最初发送方也是如此，位于路径上的网桥中的消息发送系统只是转发消息(初始消息，Ack或Nack消息)。
返回到图4所示的拓扑，当GUID为1的设备中的SE想要向GUID为3的设备中的另一SE发送HAVi可靠消息时，GUID为1的设备的消息发送系统向网桥入口(GUID为5的设备)发送消息。网桥的消息发送系统查看目的地SEID，更精确地，查看包含在此SEID中的GUID，并推导出此消息是针对其远程列表中的设备的。然后，消息发送系统向其共同入口转发HAVi消息，其共同入口依次将HAVi消息发送给GUID为3的设备(参见图5)。然后，从GUID为3的设备通过网桥向GUID为1的设备发送确认响应。
如下进行错误处理只是将在HAVi-1.1规范中已经规定的添加到对HAVi消息的错误处理中。事实上，位于路径上的网桥中的消息发送系统只是转发消息。
(e)事件管理器当SE正在发送事件时(利用EventManager∷PostEvent API)，事件管理器只将其发布在其本地群集上(利用EventManager∷ForwardEvent API)。接收到来自另一事件管理器的事件的网桥的事件管理器将此事件转发到到其共同入口。该共同入口然后将该事件发送到其群集(利用EventManager∷ForwardEvent API)等。
入口的事件管理器将事件转发到其共同入口与否的规则在于原始发布方的GUID是否存在于其共同入口的远程列表中。作为ForwardEvent消息中的参数，给出原始发布方的GUID。这里，提醒一下ForwardEvent APIStatus EventManager∷ForwardEvent(in SEID posterSeid，in Eventld eventld，in sequence<octet>eventlnfo)posterSeid参数是向其本地事件管理器发布事件的原始SE的SEID。包含在此SEID中的GUID给出了SE所驻留的设备的GUID。入口使用此GUID来确定其是否转发此事件。
当网桥向远程群集转发来自非BA设备(可以从远程设备控制这些设备)的事件时，入口的事件管理器并不向其群集的非BA设备的事件管理器转发从其共同入口接收到的事件消息(即，远程事件)。
因此，事件的错误处理保持与HAVi-1.1中相同(参见事件管理器协议章节5.4.5，第144页)。小的更新在于，每个入口用作位于其后的装置的代理。所以，事件管理器将接收来自其本地群集的事件管理器(其向之发送消息的事件管理器)的响应，且当入口接收到来自其共同入口群集的所有响应时，入口将进行响应，合并和反映这些响应。
图6示出了针对多群集网络上的事件发布(post)的基本处理。由GUID为3的设备的事件管理器向其群集的所有事件管理器转发从GUID为3的设备中的SE发布的事件。然后，一旦发布方的GUID在其共同入口的远程列表中，入口就向远程群集转发此事件(这就是为什么入口6并不将其转发给入口5的原因)。然后，入口将此事件转发给除非BA设备以外、位于其群集上的事件管理器(这是为什么设备2未接收到此事件的原因)。
根据变体实施例，对PostEvent API的“全局”参数进行如下修改。目前，其被定义为表示事件是否为HAVi网络本地或HAVi网络全局的布尔值。以如下的‘enum’结构体替代此布尔值。
enum EventScope{LOCAL，CLUSTER，NETWORK}；在优选实施例中，PostEvent API保持不变。
(f)登记处在HAVi中，由SE向登记处发送登记处查询请求(Registry∷GetElement或Registry∷MultipleGetElement)。基本处理是SE查询其本地登记处，然后，登记处将向HAVi网络上的所有其他登记处转发该查询。一旦登记处从远程节点接收到查询，其在搜索其自身的数据库之后，应答该查询。
这里以网桥保持此概念。接收到来自远程节点的查询的登记处将应答搜索其自身的数据库，除网桥设备中的登记处以外。基本处理保持为SE查询其本地登记处，登记处将向网络上的所有登记处转发该请求。稍后，对其进行详细描述。
入口的登记处自然地向其共同入口的登记处转发来自其群集的登记处的请求。但只有在请求的最初发送方的GUID出现在其共同入口的远程列表中时(即，其共同入口位于去往最初发送方的反向路径上)，才这样做。与先前一样，这避免了在不同的路径上向相同的目的地发送消息。如果此最初GUID不在其共同入口的远程列表中，则将不转发请求。对于拓扑环路，这有可能发生。在这种情况下，其共同入口将通过其群集上代理最初GUID的网桥来接收请求(所以，通过另一路由)。此外，网桥的登记处并不转发来自非BA设备的登记处的请求。这些设备对远程GUID一无所知，因此，将不能向远程SEID发送消息(对登记处的基本查询返回包括GUID的SEID)。
在被请求时，则共同入口的登记处可以向其群集上的其他登记处转发请求，包括其他网桥。随即，在整个网络上发送登记处请求。
BA设备的登记处只向其群集发送其请求，所以由登记处本身控制群集之间的登记处通信(‘群集分离’)。在图7中，与网络管理器列表(本地和远程)一起示出了三网桥环路网络。
根据变体实施例，基本处理如下最初登记处(设备GUID 1)向整个网络上的所有登记处发送查询。于是，在第一群集上发送的HAVi消息数为9个(由于网络上有9个登记处)，每个登记处一个。在另一群集上，此数目减少，由于所有网桥并未转发所有消息。
根据优选实施例，登记处(GUID 1)只向其自身群集的所有登记处发送查询。现在，此第一群集上的HAVi消息数为3个。然后，网桥的登记处以其共同入口的群集重复此操作(但只有当最初发送方GUID1出现在其共同入口的远程列表中时才如此这就是为什么GUID为7的入口并未将其转发给GUID为8的入口的原因)。
此小示例示出了对查询的改进(以三个消息代替九个)，但对于响应出现相同的现象。利用优选实施例，入口中的登记处通过合并其共同入口群集登记处的所有响应，创建了单一的响应。此外，在此示例中，每个设备都可以通过一个网桥到达，但当链接几个网桥时，在最初发送方附近的群集中，冗余HAVi消息数据变得巨大。
如下执行登记处消息处理利用群集分离，最初登记处查询其群集上的所有登记处。这减少了请求的总体业务量。为了使入口能够知道其是否必须向其共同入口转发该请求(根据共同入口的远程列表)，HAVi消息的源SEID必须使最初发送方的SEID(如果改变此源SEID，则因为针对网络管理器行为而选择的路由管理，环路网络中的查询将不能终止)。但，网络中的所有登记处将响应最初请求方，并且最初请求方将接收到比其发送的查询多的响应，这可能是不能被理解的。这就是为什么根据本实施例，初始请求方只接收来自其本地群集的登记处的响应的原因。
以下变体可以用于解决此问题(以GetElement作为示例)1.BA设备的登记处知道其只向其群集发送查询，但其将接收到来自整个网络的所有登记处的响应。只针对请求进行了消息数的减少，而并未针对响应进行消息数的减少。因为并不转发来自非BA设备的请求，因而其能够工作。
2.修改Register∷GetElement API。增加新的参数以包括与最初请求方的SEID有关的信息。API变为Status Registry∷GetElement(in SEID initialRequester，in SimpleQuery query，out sequence<SEID>seidList)接收到此消息的网桥的入口根据包含在此最初请求方参数的SEID中的GUID，知道其是否必须向其共同入口转发该查询。针对响应进行业务量改进。当向其远程群集转发请求时，网桥必须向HAVi 1.1设备发送HAVi 1.1消息，而向BA设备转发此新消息(根据每个设备的SDD的版本字段)。这些请求是新请求，具有网桥的源SEID(而不再是最初请求方的SEID)。入口将收集所有发送给其的响应(因为其是请求的源SEID)，并将其合并为一个将要发送给其最初请求方的SEID列表(原始上，入口从其接收到请求的设备)。
3.在上述变体2中，非网桥登记处并不使用最初请求方的标识。此信息只对于网桥设备的登记处是有用的，以便确定是否向远程群集转发请求。另一变体在于以专用于网桥设备的新方法扩展登记处的API。网桥感知登记处将使用此针对入口登记处的调用。
Status Registry∷ForwardGetElement(in SEID initialRequester，in SimpleQuery query，out sequence<SEID>seidList)于是，被调用的网桥设备知道最初请求方的标识。非网桥设备接收正常GetElement调用。两个调用均包含网桥的源SEID，而不是最初请求方的SEID。当网桥接收到来自登记处的所有响应时，其将这些响应合并为一个SEID列表，并对其最初接收到的ForwardGetElement调用进行响应。
4.第四变体在于避免修改登记API。网桥原样转发GetElement请求，即不修改HAVi消息中的源SEID。当网桥设备接收到来自其群集上的登记处(另一网桥或非网桥设备)的响应时，其不对该响应进行转发。分析该响应，并提取出SEID列表，以便构建其将要发送回其曾经从其接收到查询的请求方的合并SEID列表。当其接收到所有响应时，其可以与合并SEID列表一起，发送其自身的响应。
下表尝试总结了四个已提出的变体的pros和cons。
表9优选变体是第三和第四个，因为不需要修改GetElement API。变体3具有能够在网桥之间同步的优点。
图8给出了利用第三变体的、针对GetElement调用的相互作用的示例。
最初发送方向其本地登记处发送GetElement请求。然后，本地登记处将此GetElement请求转发给其本地群集上的其他登记处。当网桥的登记处接收到此请求时，其将此请求转发给共同入口登记处(假设包含在源SEID中的GUID在此共同入口的远程列表中)。然后，将此看作新请求。向共同入口的群集上的登记处发送此新请求。向非网桥设备发送GetElement，而向网设备发送ForwardGetElement。如果此群集中出现其他网桥，则重复此处理。
在每个远程群集上，由网桥设备的登记处发送不同的请求，即，网桥并不是简单地将最初请求放置在远程群集上。网桥设备保持对这些请求的跟踪，以便将其群集的登记处的响应回馈给其共同入口。当网桥设备已经接收到来自其群集的登记处的所有响应时，其将所有响应合并为单一的响应(一个SEID列表)，并将该单一的响应提供给其共同入口。然后，共同入口可以将增加了其自身的SEID列表的这个SEID列表发送给请求方登记处。如果请求方登记处在另一网桥中，则此响应将为ForwardGetElement响应，或者为针对与最初请求方相连的网桥的GetElement响应。
在图8的特定示例中，通过网桥设备合并SEID列表·GUID为6的入口将来自GUID为7的设备的列表(E)及其自身的列表(D)回送给GUID为5的共同入口。GUID为5的入口获得此列表，并加入其自身的列表(C)。结果为(C，D，E)。
·GUID为10的入口将来自GUID为8的设备的列表(空)、来自GUID为3的设备的列表(空)、来自GUID为4的设备的列表(F)及其自身的列表(空)回送给GUID为9的共同入口。结果为(F)。
·GUID为1的设备的登记处接收来自GUID为2的设备的响应(B)、来自GUID为5的设备的响应(C，D，E)和来自GUID为9的设备的响应(F)。其加入其自身的列表(A)，并将应答回送给SE。最终结果为(A，B，C，D，E，F)。
针对GetElement方法所提及的也可以应用于MultipleGetElement方法。以下为专用于网桥登记处的新API
Status Registry∷ForwardMultipleGetElement(in SEID initialRequester，in ComplexQuery query，out sequence<SEID>seidList)(g)流已知的HAVi流管理器是允许建立流连接的系统软件组件。流连接使源功能组件和宿功能组件相关联(因而，关联源和宿设备)，并确保所需资源的可用性。这些资源可以是信道、带宽等。图9示出了由HAVi规定的流连接模型。两个功能组件进行互连。在每个关联设备中，已经进行了功能控制模块和设备控制模块(FCM/DCM)之间的内部连接。在关联设备之间进行设备连接(图9中的两个完全A/V设备)。逻辑连接是HAVi级的(即，在软件组件之间)，而物理连接涉及真实的设备(在逻辑级，以DCM/FCM所表示的那些)。
在已经建立流连接之后，可以在源和宿之间发送流。在HAVi中，想要创建流连接的每个应用程序应当使用其本地流管理器(即，位于相同设备中的流管理器)。
根据HAVi规范，以FCM(功能组件模块)在网络中表示功能组件，而以DCM(设备控制模块)在网络中表示设备。当客户端应用程序从其本地流管理器请求流连接时，其指示源和宿功能组件的标识。在FcmPlug结构中组合了提供给流管理器的信息·TargetID功能组件(不是FCM)所处的设备的GUID，且是对设备中的组件的索引。
·插件方向插入或拔出。
·插件数量如果功能组件管理几个插件。
流管理器使用DCM的服务来实现内部连接(即，设备内的连接)。为了操作DCM模块，流管理器使用HAVi消息。因此，建立内部连接的方式并不依赖于介质的技术(例如，IEC61883/IEEE1394等)。
流管理器使用其链路层的服务(例如，IEC1883 CMP协议等)来建立设备流连接。
根据本实施例，对多群集流的处理如下
在单群集HAVi网络上，为了建立流，客户端使用其本地流管理器。此本地流管理器完全负责此流。在多群集网络上，客户端本地的流管理器可能并不位于与源和/或宿设备相同的群集上。此外，其可能并不知道源和/或宿设备所使用的介质技术。因此，基本原理在于使路径上的流管理器进行合作。
对于简单的单群集流，客户端能够规定由流管理器使用的传送类型、传输格式、信道和插件。对于多群集流，认为客户端能够选择针对流将要跨越的每个群集的所有这些参数是不现实的(目标是能够具有客户端根本不了解的介质技术)。所以，客户端不得不规定带宽策略(静态或动态)和流类型(对于流惟一的)。然后，流管理器负责所有传送问题。
以流管理器SprayOut和TapIn API建立HAVi中的广播流。
根据本实施例，当流管理器在这些API上接收到本地调用，且目标设备是远程的(即，不在本地群集上)时，其将向与目标功能组件(设备)相连的最近入口的流管理器转发此调用。然后，此流管理器将执行广播连接，但此连接将只是远程群集本地的。所以，广播流不会跨越网桥，但能够远程地控制。
现在，将描述所提出的针对点到点流的API。
为了保持与HAVi-1.1设备的后向兼容性，需要针对那些跨越网桥或位于远程群集上的流，定义新的流管理器方法。此后，将对其进行展示。
与已知的流管理器API相比，为新方法添加了下划线。
服务 通信 局部性 访问/针对事件类型 发送方(接收方)StreamManager∷FlowTo M 本地 全部StreamManager∷MultiClusterFlowTM 全局 全部oStreamManager∷OnThePathM 全局 网桥中的流管理器StreamManager∷SprayOutM 本地 全部
StreamManager∷Tapln M本地全部StreamManager∷Drop M全局全部StreamManager∷GetLocalConnectio M全局全部nMapStreamManager∷GetGlobalConnecti M全局全部onMapStreamManager∷ForwardGetGlobalM全局网桥中的流管理器ConnectionMapStreamManager∷GetConnection M全局全部StreamManager∷GetStream M全局全部ConnectionAdded E全局流管理器(全部)ConnectionDroppedE全局流管理器(全部)ConnectionChangedE全局流管理器(全部)表10(a)StreamManager∷MultiClusterFlowTo原型Status StreamManager∷MultiClusterFlowTo(in boolean dynamicBw，in FcmPlug source，in FcmPlug sink，in boolean anyStreamType，in StreamType streamType，out ConnectionId connId)参数■dynamicBw-表示应当设置动态(dynamicBw为真)还是静态(dynamicBw为假)带宽分配。
■source-识别源插件的FcmPlug结构体。
■sink-识别宿插件的FcmPlug结构体。
■anyStreamType-表示流类型是否必须为由客户端规定或由流管理器选择的流类型。
■streamType-流类型，如果由客户端规定的话。
■connId-由FlowTo返回的ConnectionId值。
描述此API允许客户端请求在多群集HAVi网络上创建流。在这种网络上，源设备和宿设备不需要位于相同的介质类型上。对于源和宿惟一必须相同的参数是流类型。可以对流类型进行转换，但是这将在转换器模块(例如，具有一种流类型的输入和另一种不同流类型的输出的转换器FCM)中进行。由网桥进行传送类型转换。根据本实施例，连接两个不同介质技术的网桥能够将流和消息的传送类型从一种转换为另一种。
因此，根据本实施例，客户端不需要关心此多群集连接所使用的传送类型、传输格式和信道。这些将由位于流的路径上的网桥的流管理器来处理。
错误代码■StreamManager∷ESOURCE_FCM-由source表示的FCM不存在。
■StreamManager∷ESINK_FCM-由sink表示的FCM不存在。
■StreamManager∷ESOURCE_PLUG-由source表示的FCM不包含所指定的插件。
■StreamManager∷ESINK_PLUG-由sink表示的FCM不包含所指定的插件。
■StreamManager∷EUNSUP_STREAM-连接要求了不支持的流类型。
■StreamManager∷ENO_MATCH_STREAM-插件不兼容(流类型失配)。
■StreamManager∷ENO_MATCH_BW-源带宽超出了宿所支持的带宽，或者hint.Stype.maxBW超出了源/宿FCM的支持Stype.maxBW(带宽失配)。
■StreamManager∷ENO_MATCH_SPEED-源使用了宿不支持的传输速度。
■StreamManager∷ENO_MATCH_DIR-插件不兼容(方向失配)。
■StreamManager∷ESOURCE_BUSY-源插件是另一个流的成员。
■StreamManager∷ESINK_BUSY-宿插件是另一个流的成员。
■StreamManager∷EDEV_BUSY-分配设备插件失败。
■StreamManager∷EINSUFF_BANDWIDTH-带宽分配失败。
■StreamManager∷EINSUFF_CHANNEL-信道分配识别。
■StreamManager∷ESTATICBW-dynamicBw为假，流类型是可变速率，但不能将源设置为静态带宽分配。
■StreamManager∷ERESERVED_SOURCE-需要建立(不重叠)所需的连接，但由于预留保护而被拒绝。
■StreamManager∷ERESERVED_SINK-保留由sink表示的FCM(而且不是由做出FlowTo请求的软件组件保留的)。
■StreamManager∷EDEV_CONN-建立设备连接失败。
■StreamManager∷ESHARE-不能建立连接，因为源插件不可共享(而且拥有方不同于进行FlowTo请求的软件组件)。
(b)StreamManager∷OnThePath原型Status StreamManager∷OnThePath(in boolean dynamicBw，in FcmPlug source，in FcmPlug sink，in StreamType streamType，in TransportType segmentTransportType，inTransmissionFormatsegmentTransmissionFormat，in Channel segmentChannel，in ConnectionId connId)
参数■dynamicBw-表示应当设置动态(dynamicBw为真)还是静态(dynamicBw为假)带宽分配。
■source-识别源插件的FcmPlug结构体。
■sink-识别宿插件的FcmPlug结构体。
■streamType-连接的流类型。流类型在整个连接上是惟一的，而传送类型、传输格式和信道可以不同(尤其是在跨越不同介质技术时)。
■segmentTransportType，segmentTransmissionFormat，segmentChannel-当前段的传送类型、传输格式和信道的值，即附属于接收到此调用的群集和入口。
■connId-由最初流管理器分配的ConnectionId值。
描述此API用在网桥中的流管理器之间，以构建跨越至少一个群集的连接。从原始的MultiClusterFlowTo方法调用中复制dynamicBw，source和sink参数。其由入口的流管理器使用，以确定需要向路径上的哪些入口发送所述流。
streamType参数标识了流的类型。此类型对于整个流是惟一的，其并不受到为了携带所述流而使用的传送的影响。改变其流类型的流(例如，从DV到MPEG2)将通过转换器(例如，FCM转换器)，事实上在转换器处两种流运行，FCM转换器是第一种流的宿，且是转换后的流的源。
“段”参数(segmentTransportType，segmentTransmissionFormat和segmentChannel)标识了用在流的当前段(即，目标流管理器本地)上的参数。这对于接收到此调用的入口的流管理器获得与建立在其段上的连接有关的所有信息，并内部地将其连接到其共同入口是有用的。
由最初流管理器填充connId参数，并由流路径上的入口流管理器使用，以将其段流“附加”到多群集流上。
错误代码■StreamManager∷EUNSUP_TRANSPORT-连接要求了不支持的流类型。
■StreamManager∷EUNSUP_STREAM-连接要求了不支持的流类型。
■StreamManager∷ENO_MATCH_FMT-插件不兼容(传输格式失配)■StreamManager∷ENO_MATCH_SPEED-源使用了宿不支持的传输速度。
■StreamManager∷ENO_MATCH_TRANSPORT-插件不兼容(传送类型失配)■StreamManager∷ENO_MATCH_DIR-插件不兼容(方向失配)■StreamManager∷ESOURCE_BUSY-源插件是另一个流的成员■StreamManager∷ESINK_BUSY-宿插件是另一个流的成员■StreamManager∷EDEV_BUSY-分配设备插件失败■StreamManager∷EINSUFF_BANDWIDTH-带宽分配失败■StreamManager∷EINSUFF_CHANNEL-信道分配失败■StreamManager∷EDEV_CONN-建立设备连接失败用于建立多群集流连接的处理如下由客户端本地并属于客户端的流管理器发起多群集流，与HAVi-1.1中一样(“属于”这里的意思是在其本地连接映射中)。将此流管理器称为“最初”流管理器。其向位于去往宿设备的路径上的目标功能组件(设备)的最近入口的流管理器转发此调用。结果，入口的流管理器能够接收本地调用(通过本地客户端)和远程调用(通过远程流管理器)。
此入口的流管理器负责进行与目标源功能组件在群集上的连接，并且其共同入口的流管理器负责流路径上的下一群集上的连接。如果流跨越其他网桥，则共同入口流管理器将向流路径上的下一网桥的流管理器发送HAVi消息，具有所有必须信息，从而此下一网桥流管理器能够向其共同入口内部转发该连接，所述共同入口将进行其群集上的连接，等等。在每一个段上，适当的流管理器将调用DCM的API来执行传送参数的选择，这些DCM可以是源和宿设备的DCM，但也可以是该路径上的网桥的DCM。
所以，处理为1.客户端调用被称为最初流管理器的其本地流管理器的MultiClusterFlowTo API。
2.最初流管理器查看源功能组件(设备，而非FCM)，并向去往宿的路径上、与源群集相连的第一入口转发调用。此入口被称为初级入口。有两种可能性，但在行为上没有区别o源功能组件在远程群集上，向与之相连的最近入口的流管理器转发MultiClusterFlowTo调用(利用有网络管理器提供的NetDeviceInfo结构中的nearestPortalGuid得知)。
o源功能组件在本地群集上，向去往宿功能组件设备的路径上的本地群集入口的流管理器转发MultiClusterFlowTo调用(宿设备的GUID在此入口的远程列表上，而不在本地群集的任意其他入口的远程列表上)。
3.初级入口上的流管理器利用流的结束点，对流类型执行所有DCM和FCM HAVi操作。此外，其对针对此群集的传送执行所有HAVi操作。
4.然后，流管理器负责建立第一段上的流，即源设备和初级入口之间。
5.然后，转发给其共同入口的流管理器。
6.此流管理器负责建立第二(或下一)段上的流。其可以去往最终宿设备或去往另一入口。由此流处理器完全确定和处理流在此段上的传送(包括HAVi操作和DCM/FCM调用)。
7.如果另一入口在此路径上，流管理器调用驻留在去往宿设备的路径上的下一入口中的流管理器的StreamManager∷OnThePathAPI。进行到步骤5。
在特定的群集上，连接的构建可能涉及源和宿端点(入口或设备)的流管理器。
将通过图10描述此处理示意图。
对于多群集流连接去除，不需要新的API。任何想要丢弃运行流的SE将调用拥有流的流管理器的丢弃API。如果是多群集流，此最初流管理器将把此调用转发给流路径上的第一入口，并且去除处理与构建处理相同，基于每个流管理器内部保存为针对其所负责的群集上的连接的标识符的ConnectionId。
利用这种解决方案，HAVi-1.1设备不能丢弃由远程流管理器建立的流，因为它从未看到过该流。其能够丢弃由其群集上的流管理器所拥有的多群集流(即使它并不了解此流的源和/或宿)。
作为变体，可以不从源到宿而是从宿到源地进行连接建立。
在多群集流上，仍然对动态带宽分配进行管理。如果在MultiClusterFlowTo API中将dynamicBw布尔参数设置为真，则DCM源负责重新分配其群集上的资源。然后，其发送BandwidthRequirementChanged事件。由负责路径上的下一段的流管理器捕获此事件。如果需要，此流管理器重新分配带宽。如果在MultiClusterFlowTo API中将dynamicBw布尔参数设置为假，则针对流的所需带宽的变化可能会使流进入故障模式(如HAVi-1.1中所述)。
如下进行流连接错误处理当在构建处理期间，不能在一个段上建立连接时，流管理器将在其Status返回值中发送回具有故障原样的OnThePath消息。然后，逐段去除连接，直到最初流管理器，最初流管理器警告其客户端，或者采用可能可用的“代替路径”(如下)。
当在一段上切断了现有连接时(因为总线复位，缺少资源等)，此段上负责此连接的流管理器发送由最初流管理器捕获的MultiClusterConnectionDropped事件，最初流管理器负责丢弃流，或者试图通过“代替路径”保持其有效。可以通过OnThePath API的connId参数获得最初流管理器。此connId参数能够对mgr参数进行访问，mgr参数是最初流管理器的SEID。
封装对转译根据本实施例，如果流从基于介质技术A的群集跨越基于介质技术B的群集并回到基于介质技术A的群集，B型群集上的流管理器决定不转译流的传送类型(例如，IP上的1394)。然后，将在群集B上对流进行封装。出于性能的原因，这可能是有用的。但，一旦在群集B上对此流增加宿设备，则将转译流，从而使介质技术B上的再现方(renderer)能够显示该流。所以，将针对群集B，进行A->B转译，然后，针对目标A型群集进行B->A转译。
利用所谓的连接映射，流管理器可以提供运行在HAVi网络上的所有HAVi流列表。利用GetGlobalConnectionMap API来完成。其以类似于Registry∷GetElement的方式工作。与前面一样，由于网络管理器所定义的环路解决处理，需要新的参数将此查询转发给其他群集的流管理器，以便减少业务量。所提出的API为Status StreamManager∷ForwardGetGlobalConnectionMap(in SEID initialRequester，out sequence<Connection>list)initialRequester参数使入口能够知道其是否必须向其共同入口转发此请求。由入口流管理器收集每个流管理器的本地连接映射，并最终将其发送回最初请求流管理器。
根据本实施例，从其群集上的设备接收GetLocalConnectionMap的网桥的流管理器根据从其SEID得出的调用方标识而进行不同的操作·调用方不是流管理器。这表示SE想要知道其本地连接映射。在应答中只发送本地连接映射。
·调用方是HAVi-1.1设备(即，非网桥感知)中的流管理器。同样，在应答中只发送本地连接映射。
·调用方是BA设备中的流管理器。向共同入口转发请求(如果满足转发规则)，并且共同入口流管理器将向其群集的所有流管理器发送GetLocalConnectionMap，并向与其群集相连的其他入口的流管理器发送ForwardGetGlobalConnectionMap。
此外，在Connection数据结构中进行了小修改，以处理新的多群集连接。在所枚举的ConnectionType中增加新条目enum ConnectionType {FLOW，SPRAY，TAP，MULTI_CLUSTER_FLOW}；
并且，在MULTI_CLUSTER_FLOW连接类型的情况下，将根据源设备，设置Connection结构的transmissionFormat和channel参数(所以，事实上，只是反映了源和路径上的第一入口之间的第一段上的流)。
将研究以从connectionId结构中复制的segmentId参数(标识负责特定群集上的流的流管理器的mgr字段)来标识每个段上的连接的需要。
根据本实施例，与在环路解决处理中所定义的主路径相比，在特定的条件下提供代替路径。
在由于在路径上的一个群集上缺乏资源而不能建立流，并假定源和宿之间的另一路由能够不通过此群集的情况下，流管理器和网络管理器可以决定将此流重新路由到代替路径上，以避免业务量拥堵的群集。这可以应用于与原始路由具有相同跳数的路由，但也可以应用于具有较高跳数的路由。在这种情况下，网络管理器必须内部保持跟踪，使其能够到达目前处于其他入口的远程列表上的设备，从而能够选择正确的路径。
图11示出了使用代替路径的示例。右侧群集1101已经有效，利用了已经不幸地几乎预留了该群集的所有资源(带宽或信道或二者皆有)的流。HAVi应用程序想要构建设备3和设备4之间的流。利用网络管理器中的基本远程GUID列表，这将不能工作，因为将通过群集1101来建立流，所以其将失败。一旦得知失败，流管理器决定针对此流使用代替路径，通过具有携带其的资源的左侧群集。甚至可以通过其共同入口14，将流发送到设备13上。
在这种代替路径决定的情况下，使用以下处理1.在构建连接期间，流建立在段(群集)上是不可能的。
2.警告群集之前的网桥(针对OnThePath调用返回的错误)。
3.网桥检查是否存在另一路径。
4.如果未找到，将错误返回针对OnThePath调用之前的网桥。
5.转到步骤3。3(h)资源管理器资源管理器应当不受网桥的影响。
II]HAVi网桥感知设备图12示出了根据本实施例的网桥感知设备(在以下的描述中称为BA设备)的内部软件体系结构。BA设备包括HAVi 1.1软件组件，加上Sdd管理器和网络管理器。
·Sdd管理器如已经在专用于网桥设备的章节中所描述的那样，BA设备的Sdd管理器将负责获得整个HAVi网络上的任意设备的SDD数据。这将通过访问远程Sdd管理器或执行本地低级调用来完成。
·CMM在针对HAVi-BA设备的CMM中基本上没有变化。CMM负责实现对低级本地群集的访问。所以，CMM仍然提供GetGuidList API，返回本地群集上的所有GUID的列表。并且其提供了在此群集上发送/接收低级消息的方式。实际上，在HAVi-1.1文献中对CMM1394作出了规定。
网络管理器BA设备的网络管理器如下进行操作·在群集重新配置之后，其执行本地发现。
·如果其检测到新网桥，其请求新网桥各自的远程列表。
·当接收到ENOT_READY错误响应时，其等待一些时间，以接收RemoteNetworkUpdated事件。
·如果在特定时间量之后，该事件仍未到来，其可以再次试图获得未作出应答的入口的远程列表。
·当其得到来自入口的所有响应时，其对列表进行比较，并构建其新列表，并填充改变、离开和新加入字段。
·当完成其网络设备列表时，其向其客户端发送NetworkUpdated事件。
·在其构建其新列表的时间期间，以ENOT_READY错误应答任何请求获得网络设备列表的客户端。
III]新HAVi信除HAVi 1.1中现有的那些以外的新HAVi软件组件类型如下。
HAVi软件组件类型ATT_SE_TYPE值 信任 系统元素SDD MANAGER0x0000 0007是是NETWORK DEVICE MANAGER0x0000 0008是是表11根据本实施例的HAVi SEID如下HAVi软件组件类型软件组件句柄SDD_MANAGER 0x0007NETWORK_DEVICE_MANAGER 0x0008COMMUNICATION_MEDIA_MANAG 0x0009ER_IP表12HAVi API代码如下。
HAVi API名称API代码SddManager 0x0017NetworkManager 0x0018Cmmlp 0x0019表13根据本实施例，针对登记处、流管理器、Sdd管理器和CMMIP的额外HAVi操作代码如下
HAVi消息API代码操作IDRegistry∷ForwardGetElement 0x0003 0x05Registry∷ForwardMultipleGetElement 0x0003 0x06StreamManager∷MultiClusterFlowTo 0x0008 0x08StreamManager∷OnThePath0x0008 0x09StreamManager∷ForwardGetGlobalConne0x0008 0x0actionMapSddManager∷GetSddData 0x0017 0x00NetworkManager∷GetNetDeviceList0x0018 0x00NetworkManager∷GetNetDeviceInfo0x0018 0x01NetworkManager∷GetRemoteDeviceList 0x0018 0x02Cmmlp∷GetGuidList 0x0019 0x00Cmmlp∷GetlpAddress 0x0019 0x01Cmmlp∷GetGuid 0x0019 0x02Cmmlp∷Send 0x0019 0x03Cmmlp∷EnroIIIndication 0x0019 0x04Cmmlp∷DropIndication 0x0019 0x05表14根据本实施例，针对Sdd管理器和网络管理器的HAVi错误代码如下HAVi错误名称 API代码 错误代码SddManager∷ENOT_READY 0x00170x0080SddManager∷EUNKNOWN_GUID0x00170x0081SddManager∷ELAV 0x00170x0082NetworkManager∷ENOT_READY 0x00180x0080
NetworkManager∷EUNKNOWN_GUID 0x0018 0x0081Cmmlp∷ENOT_READY 0x0019 0x0080Cmmlp∷EUNKNOWN_GUID0x0019 0x0081Cmmlp∷EUNKNOWN_IP_ADDRESS 0x0019 0x0082Cmmlp∷ESIZE0x0019 0x0083Cmmlp∷ENOT_FOUND 0x0019 0x0084表15根据本实施例的HAVi系统事件类型如下HAVi系统事件类型 由...发布 分布 基本事件号码MultiClusterConnection 流管理器全局0x001cDroppedSddDataChanged SDD管理器 全局0x0025NetworkUpdated 网络管理器 本地0x0026RemoteNetworkUpdate 网络管理器 全局0x0027dRemoteNetworkChange 网络管理器 全局0x0028dNewDevices 通信介质管理器IP本地0x0029GoneDevices 通信介质管理器IP本地0x002aChangedDevices 通信介质管理器IP本地0x002bGuidListReady通信介质管理器IP本地0x002cProxyGuidCreated 通信介质管理器IP全局0x002dIV]发现场景(Discovery scenarios)(a)不具有环路的网络图18示出了网络管理器在完全网络构建处理期间的相互作用。首先关闭所有设备，然后同时打开，所以针对每个设备，并行地进行发现。针对网桥网络管理器，对本地和远程列表构成进行描述。
在图13中，示出了第一本地发现处理，即IEEE1394群集上的拓扑构建和IP群集上的组播通告。在第一步结束时，网络管理器在其内部表中具有其本地设备，如图13所示。
然后，网桥设备检查其网络管理器是具有完全非远程列表还是不完全非远程列表。非远程列表包括本地列表加上与群集相连的其他入口的所有远程列表。如果在一个入口中存在这种完全列表，则将其赋予另一侧(共同入口)，其将认为其远程列表完全。在图14中，网桥AB的GUID 5的网络管理器发觉其是此设备上的惟一网桥，所以网桥可以更新GUID 6的远程列表，使其变为(1，2，5)。对于网桥设备BC也是如此，GUID 7的网络管理器将其远程列表更新为(3，4，8)。
在图15中，网桥设备的网络管理器彼此间请求设备的远程列表。网桥设备的网络管理器可能会迭代地更新其远程设备列表。具体地，针对入口6和入口7的非远程列表是完整的，一旦对请求做出应答，则可以更新入口5和8的远程列表。
在图16中，BA设备的网络管理器向与其本地群集相连的每个网桥设备请求远程设备列表，并构建其全局网络列表。
在图17中，客户端SE可以向其本地网络管理器请求整个网络上的设备的全局列表。
(b)在不具有环路的网络中增加新设备图18示出了开始点，即，不具有环路的现有网络。在网桥网络管理器中只示出了远程列表。
添加GUID为9的新设备。通过本地发现装置(selfID、组播、…)，在其所相连的群集上检测此设备。一旦检测到，则在与之相连的网桥的共同入口的网络管理器中更新此GUID。如图19所示，共同入口7利用新连接的GUID 9更新其远程列表。
然后，更新后的入口向其他网络管理器(在BA设备中以及在网桥中)发出RemoteNetworkUpdated事件。与此入口相连的网桥捕获此事件，并更新其自身的共同入口远程列表。在图20中，入口6捕获来自入口7的事件，并更新其共同入口5。
然后，对整个网络进行更新。现在，GUID 9在所有群集上均是已知的。
(c)具有环路的网络如前所述，大约同时打开如图21所示的网络的所有设备。第一步仍然是本地发现处理，创建本地列表。
在此结构中，没有入口可以具有将其作为有效远程列表赋予其共同入口的完全非远程列表。所有入口均发觉其在其群集上不是单独的，所以其在更新其自己的共同入口的远程列表之前，首先向其他入口请求它们的远程列表(图22)。并且由于在此拓扑中没有叶节点，每个入口都将等待其他入口。
由于入口不能应答GetRemoteDeviceList查询，其发送ENOT_READY响应错误。当入口中的网络管理器接收到这种错误时，其知道与其群集相连的入口并未完成对其远程列表的更新(例如，其正在等待与其共同入口相连的其他入口对于非常长的单线路网络，这将有可能发生)。
根据本实施例，入口与其共同入口就不完全远程列表进行通信。然后，共同入口以此不完全信息对其远程列表进行更新，如图23所示。
于是，入口利用RemoteNetworkChanged事件发出此不完全远程列表，如图24所示。此事件仅针对网桥的网络管理器，并清楚地指出列表并未处于稳定状态(尽管RemoteNetworkUpdated是最终稳定列表)。
权利要求
1.一种网桥设备，包括至少两个接口，用于对网络中的各个网络设备群集进行接口，其中所述网桥设备包括用于连接群集的至少两个接口入口，其特征在于所述网桥设备，针对每个入口，包括第一软件组件(SDDM)，用于从内部客户端接收对至少一个网络设备的设备描述配置存储数据(SDD)的请求，所述第一软件组件适用于通过对其他设备中的类似软件的功能调用，从其他设备中得到设备描述数据。
2.根据权利要求1所述的网桥设备，其特征在于所述第一软件组件适用于通过对去往远程群集设备的路径上的网桥设备的类似软件组件的功能调用，获得针对不具有类似软件组件的远程群集设备的数据。
3.根据权利要求1或2所述的网桥设备，其特征在于所述第一软件组件适用于通过向所述设备发布介质相关请求消息，获得针对在与其自身相同的群集上不具有类似软件组件的设备的数据。
4.根据权利要求1到3之一所述的网桥设备，其特征在于所述第一软件组件适用于保持下述列表中的至少一个a.所述网络上的其他设备的第一软件组件的标识符列表；b.不具有类似第一软件组件的设备的列表，与去往所述列表中的设备的路径上的最近入口的相应标识符相关联。
5.根据权利要求1到4之一所述的网桥设备，其特征在于所述第一软件组件适用于在其入口本地群集上监控不具有第一软件组件的设备的设备描述数据的变化，并在与所述网桥设备的其他入口相连的群集上产生相应的设备描述数据改变事件。
6.根据前述权利要求之一所述的网桥设备，其特征在于所述网桥设备，针对每个入口，还包括第二软件组件(CMM)，用于使各个入口的入口的其他软件组件与入口群集的通信介质进行接口，所述第二软件组件包括应用程序可编程接口，其中至少特定的方法能够由所述网络的其他设备的软件组件全局地访问，以便远程访问所述通信介质。
7.根据权利要求6所述的网桥设备，其特征在于所述全局可访问的方法包括写入、读取、锁定、登记、丢弃、指示中的至少一个。
8.根据前述权利要求之一所述的网桥设备，其特征在于所述网桥设备，针对每个入口，还包括第三软件组件(NM)，用于保持所述网络的所有群集上的所有设备的列表。
9.根据权利要求8所述的网桥设备，其特征在于所述第三软件组件适用于在检测到所述网络的任意群集上的变化时，产生第一事件，将所述变化的本质通知给其入口的软件组件。
10.根据权利要求8或9所述的网桥设备，其特征在于所述第三软件组件适用于产生第二事件，用于仅将事件发布入口的远程设备列表的状态通知给其他入口的第三软件组件。
11.根据权利要求10所述的网桥设备，其特征在于所述第二事件包括相对于事件发布入口的远程设备，即，通过事件发布入口的共同入口能够到达的设备的可能不完全列表。
12.根据权利要求8到11之一所述的网桥设备，其特征在于所述第三软件组件适用于产生第三事件，用于向所述群集上的所有设备的第三软件组件通知主入口的远程设备列表是稳定的。
13.根据权利要求12所述的网桥设备，其特征在于所述第三事件包括相对于事件发布入口的远程设备，即，通过事件发布入口的共同入口能够到达的设备的完全列表。
14.根据前述权利要求之一所述的网桥设备，其特征在于每个入口包括第四软件组件(EM)，用于向共同入口转发在入口的本地群集上检测到的事件消息。
15.根据权利要求1到14之一所述的网桥设备，其特征在于每个入口包括第五软件组件(Reg)，用于在网桥的群集之一上，接收来自另一设备的第五软件组件的请求；以及装置，用于向在其他群集上的第五软件组件转发所述请求，将初始请求者的标识符用作源地址，并将对此请求的非级联响应转发回初始请求设备。
16.根据权利要求1到14之一所述的网桥设备，其特征在于每个入口包括第五软件组件(Reg)，用于在网桥的群集之一上，接收来自另一设备的第五软件组件的请求；以及装置，用于向在其他群集上的第五软件组件转发所述请求，其中转发入口包含转发入口的地址，作为参数，用于接收和级联对所述转发请求的响应，并用于将对此请求的级联响应转发回初始请求设备。
17.根据权利要求16所述的网桥设备，其特征在于用于转发所述请求的所述装置适用于使用第一消息类型向网桥设备的第五软件组件转发请求，以及使用第二消息类型向非网桥设备的第五软件组件转发请求，其中所述转发入口的标识符是所述第一消息中的参数，而不是所述第二消息中的参数。
18.根据权利要求1到14之一所述的网桥设备，其特征在于每个入口包括第五软件组件(Reg)，用于在网桥的群集之一上，接收来自另一设备的第五软件组件的请求；以及装置，用于向在其他群集上的第五软件组件转发所述请求，将初始请求者的标识符用作源地址，用于截取对此转发请求的响应，用于级联这些响应的内容，并将对所述初始请求的单一级联响应发送回所述初始请求设备。
19.根据前述权利要求之一所述的网桥设备，其特征在于所述网桥设备还包括装置，用于转换其群集的通信介质之间的分组的传送类型。
20.根据前述权利要求之一所述的网桥设备，其特征在于每个入口包括第六软件组件(SM)，用于在接收到来自另一设备的第六软件组件的连接建立请求时，针对跨越所述网桥的连接，建立本地群集上的连接段。
21.根据权利要求20所述的网桥设备，其特征在于入口的所述第六软件组件适用于建立其本地群集上的连接，并通知其本地群集的下一入口，以执行去往连接末端设备的路径上的下一段建立。
22.一种多群集网络中的群集连接设备，其中群集通过网桥设备相连，每个网桥设备包括至少两个群集接口，其中将每个接口看作其相应群集上的网络设备，其特征在于所述网络设备包括第一软件组件(SDDM)，用于从内部客户端接收对至少第二设备的设备描述配置存储数据(SDD)的请求，所述第一软件组件适用于通过对至少一个其他设备中的类似软件的功能调用，从至少一个其他设备中得到设备描述数据。
23.根据权利要求22所述的设备，其特征在于所述第一软件组件适用于通过对去往远程群集设备的路径上的网桥设备的类似软件组件的功能调用，获得针对不具有类似软件组件的远程群集设备的数据。
24.根据权利要求22或23所述的设备，其特征在于所述第一软件组件适用于通过向位于与其相同的群集上的、不具有类似软件组件的第二设备发布介质相关请求消息，获得针对所述第二设备的数据。
25.根据权利要求22到24之一所述的设备，其特征在于所述第一软件组件适用于保持下述列表中的至少一个-所述网络上的其他设备的第一软件组件的标识符列表；-不具有类似第一软件组件的设备的列表，与去往所述列表中的设备的路径上的最近入口的相应标识符相关联。
26.根据权利要求22到25之一所述的设备，其特征在于还包括第三软件组件(NM)，用于保持所述网络的所有群集上的所有设备的列表，其中所述第三软件组件包括装置，用于从与其本地群集相连的入口获得远程设备列表，以及用于将远程设备列表与本地群集设备列表相级联。
27.根据权利要求26所述的设备，其特征在于所述第三软件组件还适用于在网络设备列表中保持在针对相对于设备自身的本地群集的远程设备的路径上的最近入口的指示。
28.根据权利要求25到27之一所述的设备，其特征在于所述第三软件组件适用于在检测到所述网络的任意群集上的变化时，产生第一事件，将所述变化的本质通知给其本地设备的组件。
29.根据权利要求22到28之一所述的设备，其特征在于所述设备包括第五软件组件(Reg)，用于从本地客户端接收对远程软件组件的列表的请求，以及用于仅向所述本地群集的设备的第五软件组件转发所述请求。
30.根据权利要求22到29之一所述的设备，其特征在于所述设备包括第六软件组件(SM)，所述第六软件组件(SM)包括针对相同设备的客户端的应用程序可编程接口，适用于接收用于建立宿设备和源设备之间的连接的请求，所述第六软件元件适用于在源和宿设备之间的路径上，确定在去往宿设备的路径上距源设备最近的入口，并向该入口发送适当的请求，以建立其本地群集上的连接，并用于向该路径上的其他适当的入口传播此请求。
31.一种用于发现网络中的设备的方法，所述网络包括至少两个设备群集和至少一个网桥，其中至少两个群集通过网桥相连，每个网桥包括至少两个接口入口，用于连接相应群集，所述方法包括以下步骤-使每个入口获得其本地群集的设备的标识符(GUID)列表；-使每个入口请求来自与其相同的群集的每个入口的远程设备列表；-使每个入口通过从其共同入口请求其本地设备和通过共同入口能够达到的远程设备的列表，构建其自身的远程设备列表。
32.根据前一权利要求所述的方法，其特征在于还包括以下步骤如果网桥位于到给定设备的最短路径上，则使所述网桥通过以所述给定设备为目的地的消息。
33.根据前一权利要求所述的方法，其特征在于所述最短路径是具有最少数目的要跨越入口的路径。
34.一种建立网络中的源设备和宿设备之间的连接的方法，所述网络包括通过网桥设备相连的多个设备群集，其中每个网桥设备包括用于连接群集的接口入口，所述方法的特征在于以下步骤(a)在网桥的入口中以及网络的其他网桥感知设备中设置流管理器软件组件；(b)在设备的流管理器软件组件级，从来自本地客户端的连接接收请求；(c)在宿设备和源设备之间的路径上，标识距源设备最近的入口，并向该入口发送连接请求；(d)使接收到所述连接请求的入口建立源设备和入口的网桥之间的连接段；(e)使接收到所述连接请求的入口让其网桥的下一入口在去往所述源设备的路径上建立下一入口的本地群集上的下一连接段；(f)如果存在，标识去往宿的路径上的下一网桥，指示位于去往宿设备的路径上的下一网桥的远程入口建立适当的连接段；(g)返回步骤(e)，直到已经建立了去往宿设备的连接段为止。
全文摘要
一种网桥设备，包括至少两个接口，用于对网络中的各个网络设备群集进行接口，其中所述网桥设备包括用于连接群集的至少两个接口入口。所述网桥设备，针对每个入口，包括第一软件组件(SDDM)，用于从内部客户端接收对至少一个网络设备的设备描述配置存储器数据(SDD)的请求，所述第一软件组件适用于通过对其他设备中的类似软件的功能调用，从其他设备中得到设备描述数据。本发明还涉及一种多群集网络中的设备，所述设备包括上述软件组件，以及一种设备发现方法和一种用于建立设备之间的连接的方法。
文档编号H04L12/40GK1647455SQ03807535
公开日2005年7月27日 申请日期2003年4月9日 优先权日2002年4月9日
发明者让-巴蒂斯特·亨利, 纪尧姆·比绍, 若埃尔·西罗 申请人:汤姆森许可贸易公司