CN113412478B - 消息收发方法、通信装置以及程序 - Google Patents

消息收发方法、通信装置以及程序 Download PDF

Info

Publication number
CN113412478B
CN113412478B CN201980090465.1A CN201980090465A CN113412478B CN 113412478 B CN113412478 B CN 113412478B CN 201980090465 A CN201980090465 A CN 201980090465A CN 113412478 B CN113412478 B CN 113412478B
Authority
CN
China
Prior art keywords
middleware
message
proxy
function
section
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.)
Active
Application number
CN201980090465.1A
Other languages
English (en)
Other versions
CN113412478A (zh
Inventor
藤野知之
斋藤由唯
柏木启一郎
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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Publication of CN113412478A publication Critical patent/CN113412478A/zh
Application granted granted Critical
Publication of CN113412478B publication Critical patent/CN113412478B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • 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
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • 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
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/566—Grouping or aggregating service requests, e.g. for unified processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

一个方式所涉及的消息收发方法在如下通信装置中执行该消息收发方法，即，该通信装置具有：中间件部，在经由代理而在出版方与订阅方之间进行消息交换的发行订阅系统中，该中间件部对由所述出版方发行的消息进行管理；以及存储部，其对包含提供所述代理的函数在内的库进行存储，其中，所述消息收发方法具有如下过程：所述中间件部通过回调函数的设定而对所述代理进行订阅；以及所述代理在接收到由设备发行的第1消息时，通过调用所述回调函数而将所述第1消息交付至所述中间件部。

Description

消息收发方法、通信装置以及程序
技术领域
本发明涉及通过发行订阅模型将设备所生成的数据作为消息而收发的技术。
背景技术
随着IoT(Internet of Things)的普及，传感器等多种设备具有进行数据的收发的功能。如果多个设备以及对设备进行管理的应用程序单独地进行通信，则通信对象会变得庞大，确定通信对象非常耗费工时。
因此，不单独确定通信对象地进行消息的交换的基于代理的发行订阅模型的便利性受到关注，近年来，多数IoT系统中采用发行订阅模型。
在采用发行订阅模型的IoT系统中，出版方以及订阅方未必均匀地分布。因此，有时在代理与应用程序之间设置订阅所有消息并暂时保存的服务器(例如，参照非专利文献1、2)。
非专利文献1：中村優吾、另4名、“多様なIoTデータストリームをクラウドレスで分散処理するミドルウエアの設計”、研究報告モバイルコンピューティングとパーベイシブシステム(MBL)2015.22(2015):1-8
非专利文献2：L.Atozori et al,“Internet of the Things:A Survey”,Computer Networks 54(2010)2787-2805
发明内容
然而，具有上述服务器的IoT系统中存在如下问题，即，代理与服务器之间的通信量增多，容易产生拥塞。这会导致IoT系统的可靠性降低。
本发明就是着眼于上述情形而提出的，其目的在于提供能够实现高度可靠的IoT系统的技术。
在本发明的第1方式中，消息收发方法在通信装置中执行，即，该通信装置具有：中间件部，在经由代理而在出版方与订阅方之间进行消息交换的发行订阅系统中，该中间件部对由所述出版方发行的消息进行管理；以及存储部，其对包含提供所述代理的函数在内的库进行存储，其中，所述消息收发方法具有如下过程：所述中间件部通过回调函数的设定而对所述代理进行订阅；以及所述代理在接收到由设备发行的第1消息时，通过调用所述回调函数而将所述第1消息交付至所述中间件部。
在本发明的第2方式中，所述消息收发方法还具有如下过程：所述中间件部在调用所述回调函数时将包含对所述第1消息的保存在内的规定的处理是否成功的情况指定为返回值并使得函数返回；以及所述代理根据利用所述中间件部返回的所述函数而将表示所述第1消息是否到达所述中间件部的信息发送至所述设备。
在本发明的第3方式中，所述消息收发方法还具有如下过程，即，所述中间件部通过函数调用而对所述代理进行第2消息的发行。
在本发明的第4方式中，所述消息收发方法还具有如下过程，即，所述代理使得将所述第2消息是否到达所述设备的情况指定为返回值的函数返回。
在本发明的第5方式中，所述消息收发方法还具有如下过程，即，所述中间件部通过函数调用而从所述代理获取表示所述设备的状态的设备状态信息。
在本发明的第6方式中，所述设备状态信息包含表示与所述设备的连接状态的会话信息、以及表示所述设备的死活状态的死活信息中的至少一者。
发明的效果
根据第1方式，使得中间件部及代理设置于不同的装置的情况下产生的拥塞缓和。其结果，能够实现可靠性较高的IoT系统。
根据第2方式，能够确保到达中间件部与设备之间。其结果，IoT系统的可靠性进一步提高。
根据第3方式，中间件部能够对设备提供用于控制设备的控制指令等信息。
根据第4方式，能够确保到达中间件部与设备之间。其结果，IoT系统的可靠性进一步提高。
根据第5方式，中间件部能够实时地获取设备状态信息。其结果，IoT系统的可靠性进一步提高。
根据第6方式，中间件部能够实时地判断作为消息发送目的地的设备是否处于能够通信的状态，消息到达设备的可能性提高。其结果，IoT系统的可靠性进一步提高。
总之，根据本发明，能够提供能实现高度可靠的IoT系统的技术。
附图说明
图1是表示本发明的一个实施方式所涉及的通信系统的框图。
图2是表示图1所示的通信装置的框图。
图3是图2所示的中间件部进行发行时的流程图。
图4是图2所示的中间件部进行订阅时的流程图。
图5是对关联技术所涉及的通信系统进行说明的框图。
图6是对关联技术所涉及的通信系统进行说明的框图。
具体实施方式
下面，参照附图对本发明的实施方式进行说明。
＜关联技术＞
首先，参照图5及图6对关联技术所涉及的通信系统进行说明。
图5概略地表示关联技术所涉及的通信系统50。图5所示的通信系统50是包含经由代理而在出版方与订阅方之间进行消息(message)交换的基于代理的发行订阅(Publish/Subscribe；Pub/Sub)系统在内的IoT系统。
在Pub/Sub系统中，代理在出版方与订阅方之间对消息进行中继。出版方是指消息发送者。出版方针对话题而发行(publish)消息。具体而言，出版方指定成为发行对象的话题，将包含表示指定的话题的话题信息及数据在内的消息向代理发送。订阅方是指消息接收者。订阅方订阅感兴趣的话题(subscribe)。具体而言，订阅方对代理登记感兴趣的话题的订阅。如果代理从出版方接收到消息，则暂时保存该消息，并且将该消息向订阅了出版方所指定的话题的订阅方发送。
通信系统50具有中间件部51、代理52、设备55以及应用程序56。在图5中，作为设备55而示出了3个设备55-1、55-2、55-3，作为应用程序56而示出了3个应用程序56-1、56-2、56-3。
代理52是Pub/Sub系统的代理。代理52安装于服务器等计算机终端。代理52通过在计算机终端中执行代理程序而实现。
设备55具有出版方及订阅方中的至少一者的功能。例如，设备55-1具有出版方的功能，设备55-2具有出版方及订阅方的功能，设备55-1具有订阅方的功能。例如，设备55-1具有传感器，将包含利用传感器生成的传感器数据及话题信息在内的消息向代理52发送。
中间件部51安装于与安装有代理52的计算机终端不同的服务器等计算机终端中。中间件部51在计算机终端中，通过执行作为程序的IoT中间软件而实现。
中间件部51具有出版方及订阅方的功能，利用Pub/Sub模型而与代理52通信。并且，中间件部51利用与Pub/Sub模型不同的协议而与应用程序56通信。应用程序56安装于与安装有中间件部51的计算机终端不同的计算机终端中。
中间件部51对由设备55上的出版方发行的消息进行管理。中间件部51订阅所有话题。由此，由设备55发行的消息全部都通过代理52而向中间件部51传送。中间件部51从应用程序56接收表示要订阅的话题的话题信息。中间件部51基于从应用程序56接收到的话题信息而发布由设备55发行的消息。例如，如果中间件部51接收到针对某个话题发行的消息，则将该消息向期望订阅该话题的应用程序56发送。
假设应用程序56-1对设备55-2进行控制的情况。应用程序56-1将包含用于控制设备55-2的控制指令在内的控制信号向中间件部51发送。如果中间件部51从应用程序56-1接收到控制信号，则针对设备55-2订阅的话题而发行包含控制指令在内的消息。如果代理52接收到由中间件部51发行的消息，则将该消息向设备55-2发送。设备55-2从代理52接收消息，根据接收到的消息中包含的应用程序56-1的控制指令而执行动作。
在关联技术所涉及的通信系统50中，代理52通过在计算机终端中执行1个程序而实现，经由网络而与其他模块(例如中间件部51)进行通信。
在具有上述结构的通信系统50中，存在下面说明的3个问题。
1.例如，设备55上的出版方确认中间件部51对消息的保存是否完毕，在中间件部51对消息的保存未完毕的情况下，有时要进行再次发送消息的处理等。然而，难以在设备55上的出版方与中间件部51之间确保消息的到达。这是因为，在Pub/Sub系统中，通常仅进行出版方与代理之间以及订阅方与代理之间的通信完毕确认。具体而言，通过返送表示通信完毕的肯定响应信息，从而能够实现表示两者间的通信完毕的到达的确保。为了进行出版方与订阅方之间的到达的确保，需要三者的完毕通知，流程变得复杂。另外，不仅是通信的完毕，有时还期望确保包含数据保存在内的处理完毕，在该情况下，流程变得更复杂。
2.表示与设备55的连接状态等设备55的状态的设备状态信息存在于代理52中。因此，难以确认中间件部51是否处于能够与设备通信的状态。
3.中间件部51与代理52之间的通信量增大，容易产生拥塞。
这里，对上述通信系统50的中间件部51及代理52的功能详细进行说明。
参照图6，代理52具有消息发布部521。消息发布部521具有会话管理部522以及响应部523。
消息发布部521利用Pub/SubAPI(Application Programming Interface)而从设备55接收消息。消息发布部521利用Pub/SubAPI而将接收到的消息发送至中间件部51。
并且，消息发布部521利用Pub/SubAPI而从设备控制部511接收消息。消息发布部521利用Pub/SubAPI而将接收到的消息发送至适当的设备55。设备55在从代理52接收到消息并保存于存储器时，将表示正常接收到消息的肯定响应(acknowledgement)信息发送至代理52。
会话管理部522对表示设备55的状态的设备状态信息进行保有管理。设备状态信息包含表示与设备55的连接状态的会话信息。并且，会话管理部522对表示各设备55订阅了何种话题的订阅信息进行保有管理。
响应部523在消息发布部521从中间件部51接收到消息并保存于数据库时，将肯定响应信息发送至中间件部51。并且，响应部523在消息发布部521从设备55接收到消息并保存于数据库时，将肯定响应信息发送至中间件部51。
中间件部51具有设备控制部511、设备状态管理部512、以及数据保存部513。
数据保存部513从代理52接收消息并将接收到的消息中包含的数据暂时保存于数据库。数据保存部513能够从数据库读出以往保存的数据等数据。中间件部51利用非Pub/SubAPI对应用程序56提供由数据保存部513读出的数据。
中间件部51针对代理52而登记所有话题的订阅。由此，由设备55发行的数据全部均到达中间件部51并保存于数据库。此时，产生上述问题1、即无法确认设备55是否能够在中间件部51中将数据保存于数据库的问题。在Pub/Sub系统中，判断通信是否正常完毕的是代理52，因此未考虑到中间件部51是否接收到消息并完成其保存之类的事务。毕竟对设备55仅通知表示设备55与代理52之间的通信是否成功的信息。另外，所有消息都交付至中间件部51，因此在中间件部51与代理52之间通信量增大，还产生上述问题3。
设备状态管理部512从代理52获取设备状态信息。设备状态管理部512基于设备状态信息而判断各设备55是否处于能够通信的状态。在Pub/Sub系统中，通常在中间件部51与代理52之间不存在对设备状态信息进行交换的API。因此，中间件部51无法实时地获取设备状态信息。换言之，中间件部51无法获知当前的设备的状态。由此，产生上述问题2。
设备控制部511对设备55进行控制。设备控制部511利用非Pub/SubAPI从应用程序56获取控制信号。非Pub/SubAPI是与Pub/SubAPI不同的任意API。控制信号包含表示控制对象的设备55的控制对象信息、以及用于对设备55进行控制的控制指令。在设备状态管理部512判断为控制对象的设备55处于能够接收控制指令的状态的情况下，设备控制部511利用Pub/SubAPI对代理52发送包含控制指令在内的消息。代理52将从中间件部51接收到的消息向控制对象的设备55发送。此时也产生问题1。即，中间件部51能够确认代理52是否正常接收到消息，但无法确认控制对象的设备55是否正常接收到消息。并且，如问题2那样，中间件部51无法实时地获取设备状态信息，因此无法掌握控制对象的设备55当前是否处于能够通信的状态。因此，状况变得更复杂。
＜实施方式＞
接下来，对本发明的实施方式所涉及的通信系统进行说明。
一个实施方式将代理作为库而组装于IoT中间软件，由此解决上述问题。作为共享库而准备代理，以二进制级与IoT中间软件(软件)建立链接。中间件部以及代理作为同一程序而执行动作。换言之，中间件部及代理分别是同一二进制的一部分。
[结构]
图1概略地表示本发明的一个实施方式所涉及的通信系统10。图1所示的通信系统10是包含基于代理的Pub/Sub系统在内的IoT系统。
通信系统10具有通信装置11、设备15以及应用程序16。在图1中，作为设备15而示出了3个设备15-1、15-2、15-3，作为应用程序16而示出了3个应用程序16-1、16-2、16-3。设备15-1、15-2、15-3分别与图5所示的设备55-1、55-2、55-3相同，应用程序16-1、16-2、16-3分别与图5所示的应用程序56-1、56-2、56-3相同。
通信装置11可以是服务器之类的计算机终端。作为硬件要素，通信装置11具有CPU(Central Processing Unit)12、作为存储部的存储器13、以及通信接口14。
CPU12是处理器的一个例子。存储器13包含主存储装置以及辅助存储装置。主存储装置是SDRAM(Synchronous Dynamic Random Access Memory)等易失性存储器，作为工作存储器而用于CPU12。辅助存储装置是硬盘驱动器(HDD)或者固态硬盘(SSD)等非易失性存储器，对IoT中间软件131等程序、为了执行程序所需的数据、由出版方发行的消息中包含的数据(例如传感器数据)、设备状态信息、订阅信息等进行存储。
通信接口14是用于与外部装置(例如设备15、应用程序16等)通信的接口。
参照图2，通信装置11具有中间件部133及代理134。中间件部133在CPU12中执行IoT中间软件131而实现。如图1所示，代理库132组装于IoT中间软件131。代理库132以二进制级与IoT中间软件131建立链接。代理库132包含提供代理134的函数。该函数由包含发送消息的函数publish()在内的多个函数构成。如果IoT中间软件131由CPU12执行，则使CPU12作为中间件部133及代理134而执行动作。
代理134是Pub/Sub系统的代理。具体而言，代理134在出版方与订阅方之间对消息进行中继。
中间件部133对由设备15上的出版方发行的消息进行管理。中间件部133通过调用函数(函数调用)而与代理134之间进行通信。例如，中间件部133在作为订阅方而执行动作时，通过设定回调函数而对代理134进行订阅。中间件部133在作为出版方执行动作时，通过调用函数而对代理134进行发行。
中间件部133以与Pub/Sub模型不同的协议与应用程序16进行通信。应用程序16安装于与通信装置11不同的计算机终端。
中间件部133订阅所有话题。在该情况下，由设备15发行的消息全部都经由代理134而向中间件部133传送。中间件部133作为回调函数而设定函数subscribe_callback()。如果代理134从设备15接收到消息，则对变量topic及payload指定消息中包含的话题信息及数据而调用回调函数。由此，中间件部133获取由设备55发行的消息。中间件部133从应用程序16接收表示要订阅的话题的话题信息。中间件部133基于从应用程序16接收到的话题信息而发布由设备15发行的消息。例如，如果中间件部133接收到通过设备15针对某个话题发行的消息，则将该消息向期望订阅该话题的应用程序16发送。中间件部133可以将由设备15发行的消息中包含的数据变换为应用程序16能够利用的形式。
设想应用程序16-1对设备15-2进行控制的情况。应用程序16-1将包含用于对设备15-2进行控制的控制指令在内的控制信号向中间件部133发送。如果中间件部133从应用程序16-1接收到控制信号，则对变量payload指定控制指令，对变量topic指定表示由设备15-2订阅的话题的话题信息，调用函数publish()。由此，代理134对设备15-2发送包含话题信息及控制指令在内的消息。设备15-2从代理134接收消息，根据接收到的消息中包含的应用程序16-1的控制指令而执行动作。
如图2所示，代理134具有消息发布部1341。消息发布部1341具有会话管理部1342以及响应部1343。作为函数而在代理库132中准备消息发布部1341、会话管理部1342以及响应部1343。
消息发布部1341利用Pub/SubAPI而从设备15接收消息。而且，消息发布部1341将从设备15接收到的消息交付至中间件部133。具体而言，消息发布部1341指定从设备15接收到的消息中包含的话题信息及数据，并调用回调函数subscribe_callback()。
消息发布部1341利用Pub/SubAPI而对设备15发送消息。具体而言，中间件部133指定话题信息及数据(例如控制指令)，并调用函数publish()。由此，将包含话题信息及数据在内的消息发送至设备15。
会话管理部1342对表示设备15的状态的设备状态信息进行管理。设备状态信息包含表示与设备15的连接状态的会话信息。具体而言，会话信息针对每个设备15而表示设备15与通信装置11之间的会话是否处于确立过程中。此外，设备状态信息可以代替会话信息或在此基础上追加包含表示设备15的死活状态(正常性)的死活信息。并且，会话管理部1342对表示各设备15订阅何种话题的订阅信息进行管理。中间件部133调用相当于会话管理部1342的函数而获取设备信息及订阅信息。
响应部1343将表示由中间件部133发行的消息是否到达设备15的信息交付至中间件部133。具体而言，响应部1343在发送由中间件部133发行的消息之后直至经过规定时间为止的期间从设备15接收到肯定响应信息的情况下，使得将消息到达设备15的情况指定为返回值的函数返回至中间件部133。另外，响应部1343在发送由中间件部133发行的消息之后直至经过规定时间为止无法从设备15接收到肯定响应信息的情况下，使得将消息未到达设备15的情况指定为返回值的函数返回至中间件部133。
中间件部133具有设备控制部1331、设备状态管理部1332以及数据保存部1333。
数据保存部1333将包含由设备15发行的话题信息及数据(例如传感器数据)在内的消息暂时保存于数据库。例如，数据保存部1333使数据与话题信息建立关联地暂时保存于数据库。如上所述，由设备15发行的消息通过对代理134设定的回调函数而从代理134向中间件部133交付。数据保存部1333从数据库读出以往保存的数据等数据。中间件部133利用非Pub/SubAPI向适当的应用程序16提供由数据保存部1333读出的数据。
中间件部133响应来自代理134的消息而将包含基于数据保存部1333对消息的保存在内的规定的处理是否成功、即是否能够正常接收到消息的情况通知给代理134。中间件部133在数据保存部1333能够保存消息的情况下，使得将处理的成功指定为返回值的函数返回至代理134。另外，中间件部133在如数据保存部1333对消息的保存失败等那样规定的处理失败的情况下，使得将处理的不成功指定为返回值的函数返回至代理134。
设备状态管理部1332从代理134获取设备状态信息及订阅信息。具体而言，设备状态管理部1332调用相当于会话管理部1342的函数，由此获取设备状态信息及订阅信息。设备状态管理部1332基于设备状态信息而判断各设备15是否处于能够通信的状态。
设备控制部1331对设备15进行控制。设备控制部1331利用非Pub/SubAPI(Application Programming Interface)，从应用程序16获取控制信号。控制信号包含表示控制对象的设备15的控制对象信息、以及用于对设备15进行控制的控制指令。如果设备控制部1331接收到控制信号，则设备状态管理部1332基于设备状态信息而判断控制对象的设备15是否处于能够通信的状态。在控制对象的设备15未处于能够通信的状态的情况下，设备控制部1331直至控制对象的设备15变为能够通信的状态为止进行等待。在控制对象的设备15处于能够通信的状态的情况下，设备控制部1331对代理134发行包含控制指令在内的消息。具体而言，设备控制部1331指定与控制对象的设备15对应的话题信息以及控制指令，并调用函数publish()。由此，将包含话题信息及控制指令在内的消息向控制对象的设备15发送。
作为Pub/Sub系统，例如可以使用MQTT(Message Queuing TelemetryTransport)。在使用MQTT的情况下，代理134与设备15之间的接口基于MQTT。代理134与中间件部133之间不依赖于MQTT，而是采用基于函数调用的接口。
[动作]
对具有上述结构的通信装置11的动作例进行说明。
图3表示中间件部133进行发行的情况下的通信装置11的处理次序的一个例子。
如图3所示，中间件部133通过函数调用而对代理134进行消息的发行(步骤S301)，代理134将该消息发送至设备15(步骤S302)。具体而言，中间件部133对变量topic指定话题信息，对变量payload指定数据，调用函数publish()。由此，将包含话题信息及数据在内的消息发送至设备15。代理134根据需要而将消息再次发送至设备15(步骤S303)。
代理134以如下方式使得将消息是否到达设备15指定为返回值的函数返回。由此，中间件部133能够确认消息是否到达设备15。
有时设备15无法接收消息。在该情况下，设备15不会将肯定响应信息发送至代理134。代理134在消息发送之后直至经过规定时间为止无法从设备15接收到肯定响应信息的情况下，判断为设备15无法接收到消息。代理134使得将消息未到达设备15的情况(timeout)指定为返回值的函数返回至中间件部133(步骤S304)。
另一方面，设备15在从代理134接收到消息并将接收到的消息保存于存储器的情况下，将肯定响应信息发送至代理134(步骤S305)。如果代理134从设备15接收到肯定响应信息，则使得将消息到达设备15的情况(success)指定为返回值的函数返回至中间件部133(步骤S306)。
由此，在中间件部133进行发行的情况下，确认是否到达中间件部133与设备15之间。
图3所示的流程与从代理134向设备15的消息的发送是MQTT的QoS1(Quality ofService 1)的情况、具体而言为使用保证消息到达设备15一次的协议的情况对应。
图4表示中间件部133进行订阅的情况下的通信装置11的处理次序的一个例子。
如图4所示，中间件部133通过回调函数的设定而对代理134进行订阅(步骤S401)。具体而言，中间件部133作为回调函数而设定函数subscribe_callback()。
然后，设备15发行消息(步骤S402)。具体而言，设备15将包含话题信息及传感器数据在内的消息发送至代理134。设备15根据需要而再次进行发行(步骤S403)。
如果代理134从设备15接收到消息，则通过调用设定的回调函数而将接收到的消息交付至中间件部133(步骤S404)。具体而言，代理134对变量topic及payload指定接收到的消息中包含的话题信息及传感器数据，并调用设定的回调函数。
中间件部133进行包含将从代理134接收到的消息保存于存储器13的处理在内的规定处理(步骤S405)。规定的处理还可以包含对消息的统计进行计算的处理。
接下来，中间件部133将规定的处理是否成功的情况指定为返回值并使得函数返回(步骤S406)。具体而言，中间件部133在规定的处理完毕的情况下使得将处理的成功指定为返回值的函数返回至代理134，否则使得将处理的不成功指定为返回值的函数返回至代理134。
代理134将与利用中间件部133返回的函数相应的信息发送至设备15(步骤S407)。具体而言，代理134在将处理的成功指定为返回值的情况下将肯定响应信息发送至设备15，在将处理的不成功指定为返回值的情况下，将否定响应(negative acknowledgement)信息发送至设备15。由此，设备15能够确认消息是否已到达中间件部133。此外，代理134可以不发送否定响应消息。在该情况下，设备15在从代理134无法接收到肯定响应信息时判断为消息未到达中间件部133。
由此，在中间件部133进行发行的情况下，确认是否到达中间件部133与设备15之间。
图4所示的流程与从代理134向设备15的消息的发送是MQTT的QoS1的情况对应。
此外，有时还不要求确保到达中间件部133与设备15之间。
[效果]
在本实施方式所涉及的通信装置11中，代理134作为库而组装于中间件部133，中间件部133与代理134之间的通信通过函数调用而进行。因此，不经由网络而进行中间件部133与代理134之间的通信。由此，能够减弱上述关联技术中产生的拥塞。并且，中间件部133与代理134之间的通信，与经由网络的通信相比，速度更快且频带更宽，能够收发更多的数据。其结果，提高了IoT系统的可靠性。
中间件部133通过对代理134设定回调函数而进行订阅。代理134在接收到利用设备15发行的消息时，通过调用该回调函数而将该消息交付至中间件部133。中间件部133对回调函数的返回值指定接收处理的结果(成功或不成功)，代理134将与返回值相应的响应发送至设备15。由此，设备15能够确认消息是否到达中间件部133。
中间件部133进行与发行对应的函数调用，并等待其返回值。代理134与来自设备15的响应的有无相应地设定返回值。由此，中间件部133能够确认消息是否到达设备15。
在代理库132中准备获取设备状态信息的函数。由此，中间件部133能够实时地获取设备状态信息，即，能够确认当前的设备55的状态。
在上述实施方式中，IoT中间软件131及代理库132等的程序由作为通用处理器的CPU而执行。作为代替方式，可以由专用的处理器执行程序。
IoT中间软件131及代理库132等的程序可以在存储于能够利用计算机读取的存储介质的状态下向通信装置11提供。在该情况下，例如，通信装置11具有从存储介质读出数据的驱动器，从存储介质获取程序。存储介质的例子包含磁盘、光盘(CD-ROM、CD-R、DVD-ROM、DVD-R等)、光磁盘(MO等)、半导体存储器。另外，可以将程序储存于通信网络上的服务器，通信装置11可以从服务器下载程序。
本发明并不限定于上述各实施方式，可以在实施阶段在未脱离其主旨的范围内，对结构要素进行变形而实现具体化。另外，可以通过上述各实施方式中公开的多个结构要素的适当的组合形成各种发明。例如，可以从各实施方式中示出的所有结构要素删除几个结构要素。并且，可以对不同的实施方式中的结构要素进行适当的组合。
标号的说明
10…通信系统
11…通信装置
12…CPU
13…存储器
14…通信接口
15…设备
16…应用程序
131…IoT中间软件
132…代理库
133…中间件部
134…代理
1331…设备控制部
1332…设备状态管理部
1333…数据保存部
1341…消息发布部
1342…会话管理部
1343…响应部
50…通信系统
51…中间件部
52…代理
55…设备
56…应用程序
511…设备控制部
512…设备状态管理部
513…数据保存部
521…消息发布部
522…会话管理部
523…响应部

Claims (7)

1.一种消息收发方法，在通信装置中执行该消息收发方法，该通信装置具有：处理器；以及存储器，其对中间软件和库进行存储，其中，所述中间软件使所述处理器作为中间件部而执行动作，在经由代理而在出版方与订阅方之间进行消息交换的发行订阅系统中，该中间件部对由所述出版方发行的消息进行管理，所述库包含使所述处理器作为所述代理而执行动作的函数，组装于所述中间软件，所述库的所述函数包含回调函数，
所述消息收发方法具有如下过程：
所述中间件部通过回调函数的设定而对所述代理进行订阅；
所述代理在接收到由第1设备发行的第1消息时，通过调用所述回调函数而将所述第1消息交付至所述中间件部；
所述中间件部响应从所述代理接收到所述第1消息而将所述第1消息发送至第2设备；
所述中间件部在调用所述回调函数时，将包含对所述第1消息的保存在内的规定的处理是否成功的情况指定为返回值并使得函数返回；以及
所述代理根据由所述中间件部返回的所述函数，将表示所述第1消息是否到达所述中间件部的信息发送至所述第1设备。
2.根据权利要求1所述的消息收发方法，其中，
所述消息收发方法还具有如下过程：
所述中间件部从第3设备接收用于控制所述第1设备的控制信息；以及
所述中间件部通过函数调用而对所述代理进行第2消息的发行，该第2消息包含所述控制信息。
3.根据权利要求2所述的消息收发方法，其中，
所述消息收发方法还具有如下过程，即，所述代理使得将所述第2消息是否到达所述第1设备的情况指定为返回值的函数返回。
4.根据权利要求1至3中任一项所述的消息收发方法，其中，
所述消息收发方法还具有如下过程，即，所述中间件部通过函数调用而从所述代理获取表示所述第1设备的状态的设备状态信息。
5.根据权利要求4所述的消息收发方法，其中，
所述设备状态信息包含表示与所述第1设备的连接状态的会话信息、以及表示所述第1设备的死活状态的死活信息中的至少一者。
6.一种存储介质，其储存有程序，其中，
所述程序使得计算机执行权利要求1至5中任一项所述的消息收发方法。
7.一种通信装置，其中，
所述通信装置具有：
处理器；以及
存储器，其对中间软件和库进行存储，
所述中间软件使所述处理器作为中间件部而执行动作，在经由代理而在出版方与订阅方之间进行消息交换的发行订阅系统中，该中间件部对由所述出版方发行的消息进行管理，
所述库包含使所述处理器作为所述代理而执行动作的函数，组装于所述中间软件，
所述库的所述函数包含回调函数，
所述中间件部通过回调函数的设定而对所述代理进行订阅，
所述代理在接收到由第1设备发行的第1消息时，通过调用所述回调函数从而将所述第1消息交付至所述中间件部，
所述中间件部响应从所述代理接收到所述第1消息而将所述第1消息发送至第2设备，
所述中间件部在调用所述回调函数时，将包含对所述第1消息的保存在内的规定的处理是否成功的情况指定为返回值并使得函数返回，
所述代理根据由所述中间件部返回的所述函数，将表示所述第1消息是否到达所述中间件部的信息发送至所述第1设备。
CN201980090465.1A 2019-01-28 2019-11-29 消息收发方法、通信装置以及程序 Active CN113412478B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2019012398 2019-01-28
JP2019-012398 2019-01-28
PCT/JP2019/046760 WO2020158154A1 (ja) 2019-01-28 2019-11-29 メッセージ送受信方法、通信装置、及びプログラム

Publications (2)

Publication Number Publication Date
CN113412478A CN113412478A (zh) 2021-09-17
CN113412478B true CN113412478B (zh) 2024-05-07

Family

ID=71840561

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980090465.1A Active CN113412478B (zh) 2019-01-28 2019-11-29 消息收发方法、通信装置以及程序

Country Status (5)

Country Link
US (1) US11582320B2 (zh)
EP (1) EP3920035B1 (zh)
JP (1) JP7030217B2 (zh)
CN (1) CN113412478B (zh)
WO (1) WO2020158154A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102384614B1 (ko) * 2020-11-30 2022-04-08 경북대학교 산학협력단 제한된 통신 환경에서 브로커 서버를 이용한 스마트 약상자 제어 시스템 및 방법
CN113878212B (zh) * 2021-09-30 2023-05-05 天津七所高科技有限公司 基于mqtt框架的电阻焊控制器设备数据集中采集系统及方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8751587B2 (en) * 2009-11-25 2014-06-10 Red Hat, Inc. Real-time web applications
US10708376B2 (en) 2015-02-20 2020-07-07 Convida Wireless, Llc Message bus service directory
US10044674B2 (en) * 2016-01-04 2018-08-07 Afero, Inc. System and method for automatic wireless network authentication in an internet of things (IOT) system
WO2017198088A1 (zh) * 2016-05-19 2017-11-23 华为技术有限公司 资源订阅方法、资源订阅装置和资源订阅系统
CN107404512B (zh) 2016-05-19 2021-03-05 华为技术有限公司 资源订阅方法、资源订阅装置和资源订阅系統
TW201804335A (zh) * 2016-07-27 2018-02-01 鴻海精密工業股份有限公司 一種連通裝置及採用該連通裝置的物聯網系統
US10645181B2 (en) 2016-12-12 2020-05-05 Sap Se Meta broker for publish-subscribe-based messaging
WO2018112327A1 (en) * 2016-12-15 2018-06-21 Convida Wireless, Llc Methods of concurrency control for block transfer in coap publish-subscribe architecture
US11010216B2 (en) * 2016-12-22 2021-05-18 Nippon Telegraph And Telephone Corporation RPC conversion processing system and RPC conversion method
CO2018005389A1 (es) * 2018-05-23 2018-11-30 Inversiones Tecnologicas De America Sa Bridge multi-biometrico iot
KR102076276B1 (ko) * 2018-05-31 2020-02-12 (주)그립 근거리 통신기술을 이용하여 사용자 단말과 직접 연동 가능한 독립형 IoT 게이트웨이
US11201937B2 (en) * 2018-11-22 2021-12-14 Jeffrey Alan Carley Message broker customization with user administered policy functions

Also Published As

Publication number Publication date
EP3920035A4 (en) 2022-11-09
US11582320B2 (en) 2023-02-14
CN113412478A (zh) 2021-09-17
WO2020158154A1 (ja) 2020-08-06
EP3920035A1 (en) 2021-12-08
JPWO2020158154A1 (ja) 2021-10-28
EP3920035B1 (en) 2023-11-15
JP7030217B2 (ja) 2022-03-04
US20220103649A1 (en) 2022-03-31

Similar Documents

Publication Publication Date Title
CN111741060B (zh) 消息推送方法、装置、计算机设备和存储介质
CN101340268B (zh) 节点间通信确认机制的实现方法和实现系统
CN111835837B (zh) 多端适配的消息推送方法及系统
CN112104620A (zh) 一种基于mqtt协议的远程指令发布方法
CN113412478B (zh) 消息收发方法、通信装置以及程序
EP3331197A1 (en) A method and system for monitoring a connection status of a device
US20100082860A1 (en) System and method for updating the status of an asynchronous, idempotent message channel
CN110413425B (zh) 第三方消息回调方法、装置、服务器和存储介质
CN111405635B (zh) 能力开放的实现方法、装置、设备及计算机可读存储介质
CN110808948A (zh) 远程过程调用方法、装置及系统
KR100884988B1 (ko) 네트워크 장치들 사이의 데이터 전송방법
CN107508916B (zh) 用于智能机器人的服务器链接管理方法
CN111555965B (zh) 一种适用于iOS客户端的消息推送方法及系统
CN113259874A (zh) 消息处理方法、电子设备及存储介质
KR101993614B1 (ko) 푸시 서비스 제공 방법, 서비스 서버 및 사용자 단말
CN113259404B (zh) 基于tcp/ip协议的工业通信中间件及其使用方法
JP3647776B2 (ja) ネットワーク上で高信頼性マルチキャストを行うシステム及び方法
WO2024052981A1 (ja) 処理装置、処理方法およびプログラム
EP3468153A1 (en) Proxy-based service processing method, device, and network element device
CN113472841B (zh) 终止远程过程调用请求的实现方法及装置
KR20140070870A (ko) 모바일 보이스 오버 인터넷 프로토콜(ｍＶｏＩＰ) 서비스에서의 푸시 알림을 이용한 통화 요청 알림 방법
KR100717239B1 (ko) 동일한 멀티캐스트 그룹에 속하는 구성원 서버들 간의신뢰성 있는 통신을 제공하기 위한 방법 및 장치
US20230017797A1 (en) Internet of things communication method and apparatus
CN101909256A (zh) 用户信息的查询方法及多媒体消息中心
KR102339661B1 (ko) Dds를 위한 게이트웨이 장치

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant