CN101848210A

CN101848210A - 分布式处理系统

Info

Publication number: CN101848210A
Application number: CN201010144683A
Authority: CN
Inventors: 久保允则; 中富高之; 篠崎新
Original assignee: Olympus Corp
Current assignee: Olympus Corp
Priority date: 2009-03-24
Filing date: 2010-03-23
Publication date: 2010-09-29
Also published as: US20100250899A1; JP2010224935A

Abstract

一种分布式处理系统，包括：具有一个以上的输入和一个以上的输出的多个处理部件；和连接多个处理部件的控制单元，所述分布式处理系统的特征在于，控制单元根据来自客户机的服务执行请求，生成执行转移信息，该执行转移信息包括执行特定的服务所需要的处理部件和执行顺序。

Description

分布式处理系统

技术领域

本发明涉及分布式处理系统。

背景技术

以往，在数据流式分布式处理中，针对在处理中使用的处理部件(以下适当地称为“PE”)组，通过从确定路径的控制单元(以下适当地称为“CU”)向处理部件的广播方式的通信或一对一方式的通信，来建立处理路径。这种处理例如已在日本特开平6-162228号公报中提出。

但是，以往的情况是各个处理部件具有一个输入一个输出的情况。因此，不能应对使用具有多个输入多个输出的处理部件的情况。

发明内容

本发明就是鉴于上述情况而提出的，其目的在于，提供一种分布式处理系统，在使用具有多个输入多个输出的处理部件的情况下，也能够构建路径。

为了解决上述课题并达到目的，根据本发明的分布式处理系统，分布式处理系统包括：具有一个以上的输入和一个以上的输出的多个处理部件；和连接多个所述处理部件的控制单元，所述分布式处理系统的特征在于，所述控制单元根据来自客户机的服务执行请求，生成执行转移信息，该执行转移信息包括执行特定的服务所需要的所述处理部件和执行顺序。

并且，根据本发明的优选方式，优选在确定处理路径后，所述控制单元向执行特定的服务所需要的多个所述处理部件分别发送相同的所述执行转移信息。

并且，根据本发明的优选方式，优选所述控制单元同时向多个所述处理部件发送。

并且，根据本发明的优选方式，优选所述执行转移信息的发送是从执行顺序为第一个的所述处理部件开始、到执行顺序为最后一个的所述处理部件为止依次发送的。

并且，根据本发明的优选方式，优选所述执行转移信息的发送是从执行顺序为最后一个的所述处理部件开始、到执行顺序为第一个的所述处理部件为止依次发送的。

并且，根据本发明的优选方式，优选在确定处理路径后，所述控制单元只向执行特定的服务所需要的所述处理部件中执行顺序为第一个的所述处理部件发送所述执行转移信息。

并且，根据本发明的优选方式，优选在确定处理路径后，所述控制单元只向执行特定的服务所需要的所述处理部件中执行顺序为最后一个的所述处理部件发送所述执行转移信息。

并且，根据本发明的优选方式，优选接收到所述执行转移信息的所述处理部件向下一个其他的所述处理部件发送所述执行转移信息。

并且，根据本发明的优选方式，优选所述处理部件具有一个输入和多个输出，与其他多个所述处理部件连接。

并且，根据本发明的优选方式，优选所述处理部件具有多个输入和一个输出，与其他多个所述处理部件连接。

优选所述处理部件具有多个输入和多个输出，与其他多个所述处理部件连接。

附图说明

图1是表示路径构建流程的图。

图2是表示将要使用的任务和路径的图。

图3是表示实施例1中的路径构建步骤的程序图。

图4是表示实施例1中对任务的索引分配的图。

图5是表示实施例1中从客户机CL向控制单元CU的服务执行请求的数据结构的图。

图6是表示实施例1中从控制单元CU向处理部件PE发送的路径信息的图。

图7是表示实施例1中从处理部件PE向处理部件PE发送的信息的图。

图8是表示实施例1中从处理部件PE向控制单元CU的通信的图。

图9是表示实施例1中从控制单元CU向客户机CL的响应的内容的图。

图10是表示实施例1中的客户机CL的步骤的流程图。

图11是表示实施例1中的控制单元CU的步骤的流程图。

图12是表示实施例1中的处理部件PE的步骤的流程图。

图13是表示实施例2中按照从执行顺序靠前的PE到后面的PE的顺序进行发送时的路径构建程序的图。

图14是实施例3中通过广播(broadcast)发送路径信息时的路径构建的程序图。

图15是表示实施例3中从控制单元CU向处理部件PE广播的路径信息的数据结构的图。

图16是表示实施例4中从控制单元CU采用斗链方式发送路径信息的情况，表示按照从执行顺序靠前的处理部件PE到后面的处理部件PE的顺序进行发送时的路径构建的程序图。

图17是表示实施例4中的斗链(bucket brigade)方式的路径信息的数据结构的图。

图18是表示实施例4中控制单元CU向处理部件PE发送的路径信息的内容的图。

图19是表示实施例4中处理部件PE1向处理部件PE2发送的路径信息的内容的图。

图20是表示实施例4中处理部件PE2向处理部件PE5发送的路径信息的内容的图。

图21是表示实施例4中的斗链方式的控制单元CU的步骤的流程图。

图22是表示实施例4中的斗链方式的处理部件PE的步骤的流程图。

图23是表示在实施例5的斗链方式中，从执行顺序为最后一个的处理部件向第一个处理部件发送路径信息的步骤的程序图。

具体实施方式

以下，根据附图具体说明本发明的分布式处理系统的实施例。另外，本发明不限定于该实施例。

首先，在说明实施例之前，定义在下面的说明中使用的用语。

(客户机)

客户机CL指用户具有的终端。能够从该终端向控制单元或处理部件发送指示。

(控制单元)

控制单元CU指管理处理部件的信息，根据用户的服务执行请求，进行要使用的处理部件的确定、处理路径的管理、服务执行时的任务执行转移的管理等的控制部。

(处理部件)

处理部件PE指在计算中使用的节点。处理部件提供某个特定的处理即任务。处理部件具有处理一个以上的任务的功能、及处理中所需要的数据的输入输出功能和数据存储功能。

(数据流式分布式处理)

例如，JPEG的编码处理被划分为下取样、DCT、霍夫曼编码等多个处理块。不是由一个程序来执行JPEG编码，而是准备每个处理块的程序(也可以是硬件)。一个处理块的输入被加工并输出，成为下一个处理块的输入。把这样一次次地交接数据并处理，实现整体上的一个大的处理的框架结构称为数据流式分布式处理。数据的交接可以是硬件的总线方式，也可以是网络方式。

(任务)

任务指处理部件提供的处理。例如，对于JPEG的编码而言，“下取样”等是任务的例子。各个任务被赋予了被称为任务标识符(TID)的识别序号。一般经常使用的任务被分配了标识符。并且，经常使用的任务标识符是公知的。任务在处理部件上执行。

(服务)

服务指具有关联性的一个以上的任务的集合。服务用于实现具有比任务更汇总的意义的处理。JPEG编码处理是服务的一个例子。

(服务序号)

服务序号指用于识别客户机CL请求的服务的唯一序号。服务序号由控制单元唯一地生成并管理。

(服务执行请求)

服务执行请求指委托控制单元准备客户机想要执行的服务。

(路径信息)

在数据流式分布式处理中，为了生成具有意义的结果，需要将执行各个任务的处理部件适当连接。把这种处理部件的排列方式称为路径信息。把形成路径称为路径构建。路径信息由控制单元确定。

(处理路径建立)

处理路径建立指形成能够与其他处理部件互相通信与任务处理有关的数据等的状态。

下面，参照图1说明构建路径的步骤。

(1)客户机CL指定处理所需要的任务和顺序，作为服务执行请求发送给控制单元CU。任务利用被称为任务标识符TID的数值来表示。

(2)在控制单元CU中预先登记了处理部件PE的信息、例如地址、任务标识符等。控制单元CU根据从客户机CL发送来的信息，确定要使用的处理部件PE。

(3)控制单元CU向处理部件PE发送路径信息。

(4)建立处理部件PE之间的路径，关于路径建立的具体情况将在后面说明。

(5)在路径构建完成后，向控制单元CU发送响应。

(6)控制单元CU向客户机CL发送要使用的处理部件PE的地址。所发送的地址是执行任务的第一个处理部件PE和最后一个处理部件PE。

(7)客户机CL与第一个处理部件PE连接。

(8)客户机CL与最后一个处理部件PE连接。

(9)客户机CL发送要让服务处理的数据。

除客户机CL之外的路径已经建立。因此，如果客户机CL与第一个处理部件PE、以及客户机CL与最后一个处理部件PE连接，则形成环路。

从客户机CL与最后一个处理部件PE连接是与通常连接的朝向(从第一个到最后一个)相反的方向。这是因为通常客户机CL存在防火墙，不允许来自外部的连接。

【实施例1】

下面，按照上述的步骤说明本发明的实施例1的分布式处理系统。其中，客户机如图2所示想要连接任务。另外，PE之间的连接不限于下述的示例。

在第一个说明的实施例中，控制单元CU向各个处理部件PE发送该处理部件PE的连接目的地、连接源的信息，构建路径。

各个处理部件PE的条件如下所述。假设在通信中使用TCP/IP。但是，通信协议不限于TCP/IP。并且，一个处理部件PE提供一个任务。

表1表示各个处理部件PE的信息。

(表1)

PE 提供的任务 PE地址

PE1 任务1 192.168.0.101

PE2 任务2 192.168.0.102

PE3 任务2 192.168.0.103

PE4 任务2 192.168.0.104

PE5 任务3 192.168.0.105

PE6 任务4 192.168.0.106

PE7 任务5 192.168.0.107

PE8 任务6 192.168.0.108

表2表示各个任务和任务标识符的定义。

(表2)

提供的任务任务标识符

任务1 11

任务2 12

任务3 13

任务4 14

任务5 15

任务6 16

表3表示客户机的地址。

(表3)

客户机地址

192.168.0.10

并且，表4表示使用的服务序号。

(表4)

服务序号

199

假设已经知道在控制单元CU中登记有各个处理部件PE的信息。并且，假设客户机CL、各个处理部件PE也已经知道控制单元CU的地址。

图3是表示路径构建步骤的程序图。在后面的附图中，完成了连接的处理部件PE之间利用“握手标记”表示。

(1)客户机CL向控制单元CU发送需要的任务作为服务执行请求。包括产生错误的情况在内，在构建了路径时，从控制单元CU得到响应。因此，客户机CL等待一直到有了响应。

(2)控制单元CU从客户机CL获取服务执行请求。控制单元CU确定提供构成该服务的任务的处理部件PE，并生成向各处理部件PE发送的路径信息。生成用于识别来自该客户机CL的处理的标识符“服务序号”。

(3)控制单元CU从执行顺序为最后一个的处理部件PE开始顺序地发送路径信息(在图中利用单点划线表示)。按照从执行顺序为最后一个的处理部件PE到第一个处理部件PE的顺序来进行发送，这是为了等待来自前级的处理部件PE的连接。

在路径信息中记述有服务标识符、要连接的处理部件PE的地址、要连接过来的处理部件PE的地址、是否是第一个或最后一个处理部件PE的信息、以及客户机的地址。

在通过处理部件PE进行接收后，切断控制单元CU与处理部件PE之间的连接。

(4)处理部件PE始终处于等待状态。处理部件PE8从控制单元CU接收路径信息。处理部件PE8由于执行顺序是最后一个，所以没有连接目的地。并且，等待来自处理部件PE6和处理部件PE7的连接。接收到的路径信息将在以后使用，所以进行存储。

(5)控制单元CU向处理部件PE7发送路径信息。

(6)从控制单元CU接收到路径信息的处理部件PE7与下一个处理部件PE8连接(在图中利用实线表示)。此时，发送包括服务序号在内的信息。被连接的处理部件PE8能够参照服务序号，识别是针对哪个服务执行请求的路径信息。由此，建立处理部件PE7与处理部件PE8之间的路径。然后，处理部件PE7进入等待来自前面的处理部件PE的连接的状态。

(7)被从处理部件PE7连接的处理部件PE8参照服务序号和连接源地址，检查是否是正确的连接。并保持与处理部件PE7的连接。处理部件PE8也要被从处理部件PE6连接，所以等待。

(8)控制单元CU向处理部件PE6发送路径信息。

(9)处理部件PE6从控制单元CU接收路径信息，并与处理部件PE8连接。然后，等待来自处理部件PE5的连接。

(10)处理部件PE8接受来自处理部件PE6的连接。

(11)由于对处理部件PE8的输入全部备齐，所以处理部件PE8通知控制单元CU连接完成(在图中利用虚线表示)。

(12)控制单元CU记录已接收了相应的服务序号的处理部件PE8的连接完成的情况。在接收到了来自全部处理部件PE的连接完成的通知后，向客户机发送结果。因此，需要存储是从哪个处理部件PE接受到完成通知。

(13)控制单元CU向处理部件PE5发送路径信息。

(14)处理部件PE5从控制单元CU接收路径信息，并与作为输出目的地的处理部件PE7连接。

(15)处理部件PE7接受来自处理部件PE5的连接。

(16)处理部件PE7向控制单元CU发送完成通知。

(17)控制单元CU接收来自相应任务的处理部件PE7的连接完成通知，并记录该情况。

(18)处理部件PE5在继处理部件PE7之后，与处理部件PE6连接。并且，等待来自处理部件PE2、处理部件PE3、处理部件PE4的连接。

(19)处理部件PE6接受来自处理部件PE5的连接。

(20)处理部件PE6向控制单元CU发送完成通知。

(21)控制单元CU接收来自相应任务的处理部件PE6的连接完成通知，并记录该情况。

(22)控制单元CU向处理部件PE4发送路径信息。

(23)处理部件PE4从控制单元CU接收路径信息，并与作为输出目的地的处理部件PE5连接。

(24)处理部件PE5接受来自处理部件PE4的连接。

(25)控制单元CU向处理部件PE3发送路径信息。

(26)处理部件PE3从控制单元CU接收路径信息，并与作为输出目的地的处理部件PE5连接。

(27)处理部件PE5接受来自处理部件PE3的连接。

(28)控制单元CU向处理部件PE2发送路径信息。

(29)处理部件PE2从控制单元CU接收路径信息，并与作为输出目的地的处理部件PE5连接。

(30)处理部件PE5接受来自处理部件PE2的连接。

(31)处理部件PE5向控制单元CU发送完成通知。

(32)控制单元CU接收来自相应任务的处理部件PE5的连接完成通知，并记录该情况。

(33)控制单元CU向处理部件PE1发送路径信息。

(34)处理部件PE1从控制单元CU接收路径信息，并与作为输出目的地的处理部件PE2连接。

(35)处理部件PE2接受来自处理部件PE1的连接。

(36)处理部件PE2向控制单元CU发送完成通知。

(37)控制单元CU受理来自相应任务的处理部件PE2的连接完成通知，并记录该情况。

(38)处理部件PE1与作为输出目的地的处理部件PE3连接。

(39)处理部件PE3接受来自处理部件PE1的连接。

(40)处理部件PE3向控制单元CU发送完成通知。

(41)控制单元CU接收来自相应任务的处理部件PE3的连接完成通知，并记录该情况。

(42)处理部件PE1与作为输出目的地的处理部件PE4连接。

(43)处理部件PE4接受来自处理部件PE1的连接。

(44)处理部件PE4向控制单元CU发送完成通知。

(45)控制单元CU接收来自相应任务的处理部件PE4的连接完成通知，并记录该情况。

(46)处理部件PE1向控制单元CU发送完成通知。在该时间点，处理部件PE之间的路径被构建。

(47)控制单元CU接收来自相应任务的处理部件PE1的连接完成通知，并记录该情况。

(48)控制单元CU从全部处理部件PE接收到完成通知，所以向客户机CL发送结果(在图中利用虚线表示)。

(49)客户机CL接收结果、即第一个处理部件和最后一个处理部件的PE地址。

(50)客户机CL与第一个处理部件PE连接(在图中利用单点划线表示)。

(51)处理部件PE1接受来自客户机CL的连接。

(52)客户机CL与最后一个处理部件PE连接(在图中利用双点划线表示)。

(53)处理部件PE8接受来自客户机CL的连接。

(54)客户机CL向第一个处理部件PE发送待处理的数据。

(55)处理部件PE1处理数据，将结果发送给处理部件PE2。

(56)处理部件PE1将结果发送给处理部件PE3。

(57)处理部件PE1将结果发送给处理部件PE4。处理部件PE1在向3个处理部件PE发送时，可以是顺序(逐个地)发送的方式，也可以是同时(广播)发送的方式。此时，关于发送的内容是全部是相同的内容、或者对每个处理部件PE都是不同的内容，这依赖于应用。

(58)处理部件PE2处理数据，将结果发送给处理部件PE5。

(59)处理部件PE3处理数据，将结果发送给处理部件PE5。

(60)处理部件PE4处理数据，将结果发送给处理部件PE5。

(61)处理部件PE5从前面3个处理部件PE接收到数据后进行处理，并将结果发送给处理部件PE6。

(62)处理部件PE5将结果发送给处理部件PE7。

(63)处理部件PE6处理数据，将结果发送给处理部件PE8。

(64)处理部件PE7处理数据，将结果发送给处理部件PE8。

(65)处理部件PE8从处理部件PE6和处理部件PE7接收数据并进行处理，将结果发送给客户机CL。

(66)客户机CL接收结果。

从各个处理部件PE向控制单元CU的完成通知也可以不是前面示出的顺序。并且，各个处理部件PE在与下一个处理部件PE连接时，也可以不是前面示出的顺序。

(数据结构)

下面说明数据结构。

在说明数据结构之前，在客户机CL侧对各个功能附加唯一的序号(以下适当称为“索引”)。图4是表示向任务分配索引的图。

在图4中，利用三角形围起来的数字是输入管脚序号。利用四方形围起来的数字是索引。在后面的附图中采用相同的表述方式。输入管脚序号是对处理部件PE的输入附带的序号，由客户机CL进行编号。只具有一个输入的处理部件PE，输入管脚序号只存在0号。当存在多个输入时，输入管脚序号按照1、2、3这样连续编号。具有与各个输入管脚序号对应的前级的处理部件PE。

(从客户机CL向控制单元CU的通信，程序(1))

图5表示从客户机CL向控制单元CU的服务执行请求的数据结构。

首先，记述第一个使用的任务数。将之后使用的任务标识符按照其数量进行排列。该顺序成为索引。然后，如附图所示，记述与各个处理部件PE的输出、输入有关的信息。

(从控制单元CU向处理部件PE的通信，程序(3))

图6表示从控制单元CU向处理部件PE发送的路径信息。

服务序号是由控制单元CU确定的唯一的数值，在识别来自客户机CL的请求时使用。在该示例中，假设控制单元CU分配199。

输入管脚数表示向该处理部件PE连接过来的其他处理部件PE的数量。由此，处理部件PE能够识别可以等待几个连接。

其中，也许其他的客户机CL偶尔也想要使用该处理部件PE。因此，为了进行区分，必须知道要连接过来的处理部件PE的地址。因此，在要连接的处理部件PE数的后面也包含这些处理部件的地址。

输出数是表示该处理部件PE的连接目的地处理部件PE有几个的数值。最后一个处理部件PE(在该示例中是处理部件PE8)不存在下一个处理部件PE。因此，输出数为0。之后接着的是连接目的地处理部件PE的地址，所以处理部件PE读取与该数量相当的后续数据，获得下一个处理部件PE的地址。并且，按照顺序进行连接。

在该示例中，假定每一个处理部件PE执行1个任务。但是，不限于此，也可以执行多个任务。在这种情况下，在处理部件PE与下一个PE连接时，必须指定使用的任务序号。因此，可以在上述数据结构中附加使用的任务序号。

下面，说明从处理部件PE向处理部件PE的通信(程序(6))。

图7表示从处理部件PE向处理部件PE发送的信息。

被连接的处理部件PE根据服务序号得知是针对哪个任务的连接。在被连接的处理部件PE中，即使不作为数据接收也能够知道要连接过来的处理部件PE的地址。因此，数据中不包含连接源的地址。在被连接的处理部件PE中，能够根据上述的“要连接过来的处理部件PE的地址”和在连接时发送过来的服务序号，得知是否是正确的连接。

说明从处理部件PE向控制单元CU的通信(程序(11))。

各个处理部件PE与全部连接目的地连接，在被从所指定的全部处理部件PE连接后，向控制单元CU发送连接完成通知。图8表示此时的数据结构。

控制单元CU存储自己发送的路径信息。并且，等待从处理部件PE发送与对应的服务序号对应的连接完成通知。

说明从控制单元CU向客户机CL的通信(程序(48))。

控制单元CU从全部处理部件PE接收到响应后，由于已在处理部件PE之间建立了路径，所以向客户机CL发送结果。图9表示其数据结构。图9表示从控制单元CU向客户机CL的响应的内容。

客户机CL按照所指定的服务序号，与第一个处理部件PE和最后一个处理部件PE连接，由此形成环路。

下面，顺序说明一直到客户机CL、控制单元CU、处理部件PE的路径完成的流程。

首先，参照图10说明客户机CL的步骤。图10是表示客户机CL的步骤的流程图。

在步骤S1001，客户机CL向控制单元CU发送服务执行请求。

在步骤S1002，客户机CL处于等待状态直到来了响应。

在步骤S1003，客户机CL从控制单元CU接收第一个处理部件PE和最后一个处理部件PE的PE地址。

在步骤S1004，客户机CL与第一个处理部件PE和最后一个处理部件PE连接。

下面，参照图11说明控制单元CU的步骤。图11是表示控制单元CU的步骤的流程图。

在步骤S1101，控制单元CU从客户机CL接收服务执行请求。

在步骤S1102，控制单元CU确定在服务的处理中使用的处理部件PE。

在步骤S1103，控制单元CU从执行顺序为最后一个的处理部件PE开始顺序地发送连接信息。

在步骤S1104，控制单元CU接收来自发送了连接信息的处理部件PE的完成通知。

在步骤S1105，控制单元CU判定是否从全部处理部件PE接收到了完成通知。

在步骤S1105的判定结果为是(Yes)时，在步骤S1106，向客户机CL发送结果，并结束处理。并且，在步骤S1105的判定结果为否(No)时，返回S1104。

下面，参照图12说明处理部件PE的步骤。图12是表示处理部件PE的步骤的流程图。

在步骤S1201，处理部件PE从控制单元CU接收路径信息。

在步骤S1202，判定处理部件PE是否是执行顺序为最后一个的处理部件PE。

在步骤S1202的判定结果为否时，转入步骤S1203。在步骤S1203，处理部件PE与下一个处理部件PE连接。并且，转入步骤S1204。在步骤S1202的判定结果为是时，转入步骤S1204。

在步骤S1204，等待来自自己前面的处理部件PE的连接。

在步骤S1205，判定是否已完成全部连接。

在步骤S1205的判定结果为否时，返回步骤S1204。

在步骤S1205的判定结果为是时，转入步骤S1206。在步骤S1206，处理部件PE向控制单元CU发送连接完成通知。

在步骤S1207，判定处理部件PE是否是第一个或最后一个处理部件。在步骤S1207的判定结果为否时，结束处理。在步骤S1207的判定结果为是时，在步骤S1208，等待来自客户机CL的连接。

【实施例2】

下面，说明本发明的实施例2的分布式处理系统。在该实施例中，说明从客户机CL向各个处理部件PE发送路径信息的情况，即按从执行顺序靠前的PE到靠后的PE的顺序进行发送的情况。

其中，使用的服务与前述的服务相同。

在控制单元CU向各个处理部件PE发送路径信息的上述示例中，说明了控制单元CU先向前面的处理部件PE发送路径信息，并顺序地向后面的处理部件PE发送的情况。图13表示其程序。

图13是表示按从执行顺序靠前(第一个)的处理部件PE到靠后(最后一个)的PE的顺序进行发送的情况的路径构建程序的图。

图中的记号的意义与上述示例中的记号的意义相同。路径信息(单点划线)、连接(黑线)、连接(虚线)等在通信中使用的数据结构，与从后向前地发送路径信息的实施例1的情况相同。

与从后向前地向处理部件PE发送路径时的不同之处是，处理部件PE接收到路径信息并与下一个处理部件PE连接时，下一个处理部件PE有可能还没有接收到路径信息。

当从前一个处理部件PE与处理部件PE连接后，服务序号被发送过来。然后，从控制单元CU发送过来与该服务序号对应的路径信息，并保存。

并且，在从控制单元CU发送过来路径信息时，如果服务序号一致，则与下一个处理部件PE连接。在将全部的输入和输出连接后，处理部件PE向控制单元CU发送完成通知。

【实施例3】

下面，说明本发明的实施例3的分布式处理系统。在该实施例中，说明从控制单元CU通过广播(broadcast)向全部处理部件PE发送路径信息的情况。

使用的服务与上述的服务相同。

说明控制单元CU通过一次广播向在服务中使用的全部处理部件PE发送路径信息，然后构建路径的情况。

图14表示通过广播(broadcast)发送路径信息时的路径构建的程序。

控制单元CU通过广播向构成路径的全部处理部件PE发送路径信息。

接收到路径信息的各个处理部件PE与输出目的地连接，同时也接受输入过来的处理部件PE的连接。

各个处理部件PE在全部的输入和输出备齐时，向控制单元CU发送连接完成。

(数据结构)

图15表示从控制单元CU向处理部件PE广播的路径信息的数据结构。

为了通过广播来发送路径信息，采取在一次发送中具有全部处理部件PE的路径信息的结构。

“使用的PE数”记述在该服务中使用的处理部件PE的数量。在其后面，按照索引顺序排列“使用的PE数”个的各个处理部件PE的地址。

各个处理部件PE将自身IP地址和在路径信息中记述的IP地址进行比较。由此，能够得知自身索引。

在处理部件的PE地址之后，按照索引顺序排列记述了各个处理部件PE的输出数、输出目的地的索引(排列了PE的输出数个)、输入数、输入源的地址(排列了PE的输入数个)。

如果得知索引，则能够读取自身PE的输入输出记述部分，并与作为输出目的地的处理部件PE连接，等待来自输入源的处理部件PE的连接。

【实施例4】

下面，说明本发明的实施例4的分布式处理系统。在该实施例中，说明从控制单元CU按照斗链方式发送路径信息的情况，即从执行顺序靠前的处理部件PE向靠后的处理部件PE发送的情况。

使用的服务与上述的服务相同。

斗链方式指控制单元CU向第一个处理部件PE发送全部路径信息。接收到全部路径信息的处理部件PE向下一个处理部件PE发送路径信息。这样，采用斗链方式将路径信息传递给后面的处理部件PE，一直传递到最后一个处理部件PE。客户机CL向各个处理部件PE分配索引的情况也与上述相同。关于此时的数据结构将在后面叙述。

图16是表示从控制单元CU采用斗链方式发送路径信息的情况，表示从执行顺序靠前的处理部件PE向靠后的处理部件PE发送的情况下的路径构建程序的图。

控制单元CU向第一个处理部件PE1发送路径信息。处理部件PE1参照路径信息，与自身PE的下一个的全部输出目的地连接，并发送该路径信息。

如果有要连接过来的处理部件PE，则等待连接。例如，对于处理部件PE1而言，相当于从客户机CL连接过来。这样，不断地将路径信息传递下去。最后一个处理部件PE通知控制单元CU已传递到最后一个。

下面，根据图16说明步骤。

(1)客户机CL向控制单元CU发送服务执行请求(在图中利用实线表示)。包含错误的情况在内，如果构建了路径，则将从控制单元CU得到响应，所以进行等待直到有了响应。

(2)控制单元CU从客户机CL接收服务执行请求。控制单元CU确定提供这些任务的处理部件PE，并生成要向处理部件PE发送的路径信息。

(3)控制单元CU向第一个处理部件PE1发送路径信息(在图中利用单点划线表示)。然后，等待从最后一个处理部件PE发送过来完成通知。

(4)处理部件PE1接收路径信息，并根据其中记述的信息，向处理部件PE2发送路径信息。该连接将被保持。即，在为了发送路径信息而进行连接的同时，也完成这些处理部件PE之间的路径。

(5)处理部件PE1也与处理部件PE3连接。因此，也向处理部件PE3发送路径信息。

(6)处理部件PE1与处理部件PE4连接。因此，也向处理部件PE4发送路径信息。

(7)处理部件PE2与作为输出目的地的处理部件PE5连接，并发送路径信息。

(8)处理部件PE3与作为输出目的地的处理部件PE5连接，并发送路径信息。

(9)处理部件PE4与作为输出目的地的处理部件PE5连接，并发送路径信息。

(10)处理部件PE由于全部的输入已备齐，所以与作为输出目的地的处理部件PE6连接，并发送路径信息。

(11)处理部件PE5与另一个输出目的地即处理部件PE7连接，并发送路径信息。

(12)处理部件PE6与输出目的地即处理部件PE8连接，并发送路径信息。

(13)处理部件PE7与输出目的地即处理部件PE8连接，并发送路径信息。

(14)处理部件PE8由于是最后一个处理部件PE，所以向控制单元CU回复路径已完成。

(15)由于路径已完成，所以控制单元CU向客户机CL发送第一个和最后一个PE地址。

(16)客户机CL与第一个处理部件PE连接。

(17)客户机CL与最后一个处理部件PE连接。

下面，说明数据结构。

从客户机CL向控制单元CU进行服务执行请求的数据结构与最开始的方式相同。

图17表示斗链方式中从控制单元CU向处理部件PE发送的路径信息的数据结构。由控制单元CU根据从客户机CL发送过来的任务的排列而生成。

“自己的索引”指接收到该路径信息的处理部件PE的索引。在路径内，各个处理部件PE具有唯一的索引值。在该实施例中，按照下面所述分配针对处理部件PE的索引。

PE1 0

PE2 1

PE3 2

PE4 3

PE5 4

PE6 5

PE7 6

PE8 7

在从控制单元CU向第一个处理部件PE即处理部件PE1发送时，索引值为0。并且，根据发送目的地处理部件PE的索引值，由发送路径信息的处理部件PE进行改写。其他部分不改写，而是照原样使用由控制单元CU发送过来的内容。

在处理部件PE接收到路径信息后，寻找当前的索引。在使用的处理部件PE数的后面记述有各个处理部件PE的地址。因此，找到该地址，识别出连接目的地的地址。

在这些地址的后面，按照索引顺序记述有各个处理部件PE的输出数及各个处理部件PE的索引、以及要向自己连接过来的处理部件PE。与输出目的地的处理部件PE连接，将“当前的索引”改写为该处理部件PE的索引值，并发送路径信息。反复进行输出数次的该动作。然后，等待来自前面的处理部件PE的连接。

关于处理部件PE1，按照图18说明是如何处理从控制单元CU接收到的路径信息的。

图18表示控制单元CU向处理部件PE1发送的路径信息的内容。其中，该路径信息包含于图17所示的路径信息中，换言之，是更具体化后的内容。

处理部件PE1从路径信息中读取自己的索引。处理部件PE1由于是第一个，所以被记述为0。

然后，记述有使用的PE数。因此，跳过该部分，读出处理部件PE1的输出数。其中，PE1的输出数被记述为3，所以得知与3个处理部件PE连接。

另外，然后记述有连接目的地的索引。因此，参照前面的索引和PE地址的对应表，得知处理部件PE的地址。

因此，处理部件PE1能够与输出目的地的3个处理部件PE连接。在连接后，将从控制单元CU接收到的路径信息的“自己的索引”部分改写为对方的索引，并发送。

在路径信息中，在输出目的地的后面记述有输入的处理部件PE，所以处理部件PE1读取该部分。处理部件PE1是第一个处理部件PE，从客户机CU向其连接。因此，记述有客户机的地址。处理部件PE1等待客户机利用该服务序号连接过来。

图19表示处理部件PE1向处理部件PE2发送的路径信息的内容。

处理部件PE2在接收到路径信息后，查看自己的索引栏，跳跃到记述有索引1的输出信息的部分并读取。得知输出目的地的PE索引是4、即是处理部件PE5。因此，与处理部件PE5连接。

此时，处理部件PE2把接收到的路径信息的“自己的索引”部分变更为4，并发送路径信息。处理部件PE2读取向处理部件PE2的输入部分，得知只从索引0(PE1)对其连接。处理部件PE2等待处理部件PE1采用服务序号199进行的连接。

下面，说明处理部件PE2连接的处理部件PE5的动作。

图20表示处理部件PE2向处理部件PE5发送的路径信息的内容。

处理部件PE5具有来自3个处理部件PE的输入。因此，不确定最先被从哪个处理部件PE连接。并且，如果查看最先接收到的路径信息，则得知从哪里进行了几个连接。因此，能够等待来自处理部件PE的连接。

因此，被连接的顺序可以是任何顺序。并且，与下一个处理部件PE的连接是与处理部件PE1和PE2等相同的处理。

其中，其他处理部件PE是与这些处理相同的处理，所以省略重复说明。最后一个处理部件PE在全部的输入备齐后，通知控制单元CU路径信息已传递到最后一个。

下面，说明该实施例中直到客户机CL、控制单元CU、处理部件PE的路径完成为止的步骤。并且，客户机CL与控制单元CU向各个处理部件PE直接发送路径信息的情况相同。

图21是表示斗链方式中的控制单元CU的步骤的流程图。

在步骤S2101，控制单元CU从客户机CL接收服务执行请求。

在步骤S2102，控制单元CU确定要使用的处理部件PE。

在步骤S2103，控制单元CU向执行顺序为第一个的处理部件PE发送路径信息。

在步骤S2104，控制单元CU在采用斗链方式顺序发送了路径信息后，等待来自最后一个处理部件PE的通知。

在步骤S2105，控制单元CU接收到来自最后一个处理部件PE的通知后，向客户机CL发送结果。

图22是表示斗链方式中的处理部件PE的步骤的流程图。

在步骤S2202，处理部件PE接收路径信息。其中，在针对处理部件PE的输入有多个时，接收多个的全部路径信息。

在步骤S2203，判定是否是最后一个处理部件PE。

在步骤S2203的判定结果为是时，在步骤S2206，向控制单元发送完成通知。并且，转入步骤S2205。

在步骤S2203的判定结果为否时，在步骤S2204，向全部输出目的地的处理部件PE发送路径信息。

在步骤S2205，处理部件PE等待连接。然后结束处理。

【实施例5】

下面，说明本发明的实施例5的分布式处理系统。在该实施例中，说明从控制单元CU采用斗链方式发送路径信息的情况，即从执行顺序为最后一个的处理部件开始向第一个处理部件发送的情况。

在该实施例中，说明从后面的处理部件PE向前面的处理部件PE顺序传递路径信息的方式。

图23是表示在斗链方式中，从执行顺序为最后一个的处理部件开始向第一个处理部件发送路径信息的步骤的程序图。

关于路径信息的数据结构，采用与上述的从第一个处理部件向最后一个处理部件发送路径信息的情况相同的数据结构。

控制单元CU向最后一个处理部件PE8发送路径信息。在从第一个处理部件向最后一个处理部件发送的情况下，从控制单元CU发送时的索引为0，但在从最后一个处理部件向第一个处理部件发送的情况下，根据处理部件PE数而变化。在该实施例中设为7。

处理部件PE8与作为向处理部件PE8的输入的处理部件PE6和处理部件PE7连接。对于其他处理部件PE，也是把路径信息改写为合适的索引，并与输入的处理部件PE连接。第一个处理部件PE向控制单元CU发送连接完成。

在上述各个实施例中，关于通信部分使用TCP/IP进行了说明，但也可以使用UDP，与有线、无线区别等无关，只要能够实现上述通信，则对通信方式没有限定。

在上述各个实施例的程序图中，发送完成通知的定时也可以不是前面叙述的顺序。

在上述各个实施例的程序图中，在具有多个输出的处理部件PE向下一个处理部件PE发送路径信息的情况下，也可以不是这里示出的顺序。

在上述各个实施例的程序图中，在具有多个输入的处理部件PE从前面的处理部件PE接收路径信息的情况下，也可以不是治理示出的顺序。

关于在上述各个实施例中叙述的数据结构，只要能够实现前面叙述的动作，则不限于该形式。

如以上说明的那样，根据本发明，能够构建将通过顺序连接一个输入一个输出的处理部件而形成的处理路径在中途划分为多个，并且将多个路径集中为一个的路径，能够增大路径的自由度，能够适用于各种应用。

如上所述，本发明对自由度大的分布式处理系统比较有用。

本发明发挥能够提供一种在使用具有多个输入多个输出的处理部件的情况下，也能够构建路径的分布式处理系统的效果。

Claims

1.一种分布式处理系统，其包括：具有一个以上的输入和一个以上的输出的多个处理部件；和连接多个所述处理部件的控制单元，所述分布式处理系统的特征在于，

所述控制单元根据来自客户机的服务执行请求，生成执行转移信息，该执行转移信息包括执行特定的服务所需要的所述处理部件和执行顺序。

2.根据权利要求1所述的分布式处理系统，其特征在于，在确定处理路径后，所述控制单元向执行特定的服务所需要的多个所述处理部件分别发送相同的所述执行转移信息。

3.根据权利要求2所述的分布式处理系统，其特征在于，所述控制单元同时向多个所述处理部件发送。

4.根据权利要求2所述的分布式处理系统，其特征在于，所述执行转移信息的发送是从执行顺序为第一个的所述处理部件开始、到执行顺序为最后一个的所述处理部件为止依次发送的。

5.根据权利要求2所述的分布式处理系统，其特征在于，所述执行转移信息的发送是从执行顺序为最后一个的所述处理部件开始、到执行顺序为第一个的所述处理部件为止依次发送的。

6.根据权利要求1所述的分布式处理系统，其特征在于，在确定处理路径后，所述控制单元只向执行特定的服务所需要的所述处理部件中执行顺序为第一个的所述处理部件发送所述执行转移信息。

7.根据权利要求1所述的分布式处理系统，其特征在于，在确定处理路径后，所述控制单元只向执行特定的服务所需要的所述处理部件中执行顺序为最后一个的所述处理部件发送所述执行转移信息。

8.根据权利要求4所述的分布式处理系统，其特征在于，接收到所述执行转移信息的所述处理部件向下一个其他的所述处理部件发送所述执行转移信息。

9.根据权利要求2所述的分布式处理系统，其特征在于，所述处理部件具有一个输入和多个输出，与其他多个所述处理部件连接。

10.根据权利要求2所述的分布式处理系统，其特征在于，所述处理部件具有多个输入和一个输出，与其他多个所述处理部件连接。

11.根据权利要求2所述的分布式处理系统，其特征在于，所述处理部件具有多个输入和多个输出，与其他多个所述处理部件连接。