CN101651863B - 基于软件总线扩展的消息发送方法 - Google Patents

Abstract

本发明公开了一种基于软件总线扩展的消息发送方法，包括如下步骤，发送端建立发送通道；发送端通过固定通道向接收端发送携带有发送通道名以及拟接收端名的第一消息；发送端接收接收端通过发送通道发送的第二消息，第二消息中携带有接收端建立的接收通道的接收通道名，其中，接收端在拟接收端名与其本身的名称一致的情况下建立接收通道；发送端获取接收通道名，并在接收通道上向接收端发送消息。本发明通过在发送端和接收端建立唯一的通信通道以及增加了鉴别接收端的身份等技术手段，避免了消息被非法接收端获取，保证了通信的安全性和可靠性。

Description

基于软件总线扩展的消息发送方法

技术领域

本发明涉及通信领域，尤其涉及基于软件总线扩展的手机终端发送消息的方法。

背景技术

QCOP是一种手机终端应用开发中常采用的通信协议，用于不同的客户在同一地址空间内部或者不同的进程之间进行通信，通过QCOP，便于用户实现不同进程对象间的任意参数传递。这种协议的通信方式属于软件总线的范畴。

QCOP消息机制是一个比较复杂的进程间通讯机制，如图1所示，服务器在server进程维护了消息通道名称与消息客户进程的映射表qcopServerMap，(通道名称1，客户进程表1)、(通道名称2，客户进程表2)......(通道名称n，客户进程表n)，并且每个通道都会建立一个socket连接，连接到客户进程，图1中示出了客户进程1和客户进程2，其中，客户进程2在消息通道1上向客户进程1发送消息。具体地，在客户进程1中维护了消息通道名称与通道对象表的映射表qcopClientMap，(通道名称1，通道对象表1)、(通道名称2、通道对象表2)......(通道名称n、通道对象表n)，例如，通道对象表1对应于通道对象11、通道对象12、通道对象13......通道对象1i。

图2示出了客户端之间的通信过程，如图2所示，包括如下处理：

步骤201，客户端1把本身所属通道的通道名与消息数据一起发送给服务器端；

步骤202，服务进程在映射表中找到通道名，取出其对应的客户端对象集；

步骤203，服务器通过socket连接机制发送消息到客户端2；

步骤204，服务器通过socket连接机制发送消息到查询结果集的其他客户端，例如，客户端3。

为了实现这种通信机制，QT提供了QCopChannel和QCopEnvelope类来封装底层发送和接收消息的具体细节。QCopChannel类提供了send()、isRegistered()等静态函数，该静态函数可以在脱离对象的情况下使用，QCopEnvelope类对发送QCOP消息的过程进行了封装，用户只需调用该类中的相关函数即可方便地实现进程之间的通信过程。

QCOP提供的上述通信方式无疑具有使用简单方便的优点，但是，这种开放式的消息传递方式也不可避免地存在一些缺点，例如，一方面这样就会造成效率低、响应速度慢的问题；另一方面，当用户发送消息时，所有的通道都会监听该消息，接收通道名一般都是固定的或可知的，容易被窃取，如果非法接收类也建立了这个名的通道，就可以响应这个消息，从而获得信息，因此，这种通信方式的安全性不高；另外，发送客户端在消息发送后将不再进行其他处理，因此消息传递可靠性不高。

发明内容

考虑到相关技术领域中存在的上述问题而提出本发明。为此，本发明的目的在于提供一种基于软件总线扩展的消息发送方法，以解决现有技术中存在的上述问题之一。

根据本发明，提供了一种基于软件总线扩展的消息发送方法，包括如下步骤：发送端建立发送通道；发送端通过固定通道向接收端发送携带有发送通道名以及拟接收端名的第一消息；发送端接收接收端通过发送通道发送的第二消息，第二消息中携带有接收端建立的接收通道的接收通道名，其中，接收端在拟接收端名与其本身的名称一致的情况下建立接收通道；发送端获取接收通道名，并在接收通道上向接收端发送消息。

优选地，发送端建立发送通道具体包括：动态生成特定字符串作为通道名；根据通道名建立发送通道。

优选地，在发送端发送第一消息之后，方法还包括：接收端接收第一消息，并获取第一消息中的发送通道名以及拟接收端名称；接收端将拟接收端名称与自身名称进行比较，在二者一致的情况下，接收端建立接收通道；接收端通过发送通道将携带有接收通道名称的第二消息发送给发送端。

优选地，接收端建立接收通道具体包括：动态生成特定字符串作为通道名；根据通道名建立接收通道。

优选地，在接收通道上向接收端发送消息之后，方法还包括：发送端接收来自接收端的反馈信号。

优选地，发送端接收来自接收端的反馈信号具体包括：发送端在发送消息之后启动预先设置的定时器；在定时器到时之前接收到接收端的反馈信号的情况下，判断消息达到接收端，并关闭定时器；在定时器到时之前没有接收到接收端的反馈信号的情况下，进行重传操作。

优选地，发送端为发送客户端类，接收端为接收客户端类。

优选地，发送端为发送客户端类，接收端为接收客户端类的全部或部分对象。

优选地，设置第一计数器和第二计数器，其中，第一计数器用于表示允许接收消息的对象的数量，第二计数器用于表示当前通信的对象的数量，初始值设置为0；

在第一计数器表示允许向部分对象发送消息的情况下，在接收到来自一个对象的反馈信号后，将第二计数器的计数值加1，并判断第二计数器的计数值是否大于第一计数器的值，在判断结果为否的情况下，执行向下一个对象发送消息的操作。

优选地，设置计数器并将计数器的初始值设置为0，其中，计数器用于表示当前通信的对象的数量，计数器的计数阈值为允许接收消息的对象的数量；在接收到来自一个对象的反馈信号后，将计数器的计数值加1；判断计数器的计数值是否大于计数阈值，在判断结果为否的情况下，执行向下一个对象发送消息的操作。

通过本发明的上述至少一个技术方案，通过在发送端和接收端建立唯一的通信通道以及增加了鉴别接收端的身份等技术手段，由于发送通道和接收通道都是唯一的、不为其他客户所知且不可猜测的，从而避免了消息被非法接收端获取，保证了通信的安全性。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是根据现有技术的QCOP的消息机制的示意图；

图2是根据现有技术的QCOP的消息机制的通信流程图；

图3A是根据本发明实施例的基于软件总线扩展的消息发送方法的流程图；

图3B是根据本发明实施例的方法中接收端的处理的流程图；

图4是根据本发明实施例的实例一的流程图；

图5是根据本发明实施例的反馈机制的一种实现过程的流程图；

图6是根据本发明实施例的实例三的流程图；

图7是根据本发明实施例的实例三的另一流程图。

具体实施方式

功能概述

考虑到目前的QCOP消息机制存在的传输效率、安全性及可靠性等问题，本发明实施例提供了一种新的QCOP消息机制，其中，对QT提供的QCopChannel和QCopEnvelope类进行封装，并通过相关机制确保通信会话过程中的消息安全及可靠传递，具体地，在发送端和接收端建立唯一的通信通道，并且采用两个通信阶段来完成，第一阶段的通信用于鉴别接收端的身份，第二阶段在鉴权成功的情况下传递消息。

以下结合附图对本发明的实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

根据本发明的实施例，提供了一种基于软件总线扩展的手机终端发送消息的方法。

其中，图3A是根据本发明的方法由发送端向接收端发送消息的流程，如图3A所示，包括如下步骤，

步骤S302A：发送端(sendClient，也可以称为发送客户端)建立发送通道(sendChannel)。

在该步骤中，发送端建立该发送通道可以采用如下方式，首先，动态产生特定字符串作为通道名，然后，建立以该通道名命名的通道。在这里，作为通道名的特定字符串是唯一的，每次创建发送通道时产生的字符串都不相同，其可以通过随机函数生成，也可以取当前时间的毫秒数来生成，当然，本发明不限于此，根据实施的需要也可以采用其他方式，只要能够动态产生唯一的字符串即可(“动态产生”是指用户每次创建发送通道时产生的字符串都不相同)。由于通道名是唯一的，所以其对应的发送通道也是唯一的。

步骤S304A：发送端通过固定通道向接收端(receive Client，也可以称为接收客户端)发送携带有发送通道名(即，上述的特定字符串)以及拟接收端名的第一消息。此处的“固定通道”是相对前述的“动态产生”的通道而言，指用户每次创建的通道，名称都是相同的。

步骤S306A：发送端接收来自接收端的通过发送通道发送的第二消息，第二消息中携带有接收端建立的接收通道(receiveChannel)的接收通道名，其中，接收端在“拟接收端名”与其本身的名称一致的情况下建立上述的接收通道。

步骤S308A：发送端获取接收通道名，并在接收通道上向接收端发送消息。

通过上述方法，实际上实现了对接收端的鉴权过程，发送端在鉴权成功的情况下才会在步骤S308A中发送消息，从而保证了消息传输的安全性。另一方面，在接收端进行的相关处理在图3B中示出，如图3B所示，包括如下操作：

步骤S302B：接收端使用固定通道监听总线上的所有消息，接收到第一消息后，获取第一消息中的发送通道名以及拟接收端名称。

步骤S304B：接收端将拟接收端名称与自身名称进行比较，在二者一致的情况下，建立接收通道；相反，在二者不一致的情况下，终止后续操作，通信结束。这里接收端建立接收通道的过程与发送端类似，即，首先动态生成特定字符串作为通道名，再根据通道名建立接收通道，所建立的接收通道也是唯一的，在此不再赘述。

步骤S306B：接收端通过发送通道将携带有接收通道名称的第二消息发送给发送端。如上所述，由于发送通道是唯一的，因此当接收端反馈第二消息时，能保证只有发送端接收到该消息。

需要说明的是，由于发送端发送第一消息时使用的是固定通道，因此，企图窃取消息的非法接收端也可以接收发送端发送消息(只要建立一个以固定通道名为名称的通道即可)，但是由于此时发送端发送的消息仅仅是发送通道名和“拟接收端名”的第一消息，并不包含真实信息，所以这些信息即使被窃取，也不会对后续真实信息的传输带来影响。因为窃取对象一般只是接收消息并对消息进行处理，而不会有进一步操作，因此其过程到此结束，后续发送端发送的真实消息不会被窃取对象获得。

通过本发明实施例提供的技术方案，通过在发送端和接收端建立唯一的通信通道的技术手段，采用三次通信：第一次在固定通道上发送用于鉴别接收端的身份的第一消息的信息，第二次在发送通道上发送第二消息，即包含接收通道名的消息，第三次在接收通道上传递发送消息，此次的消息为“真实消息”。通过这三个步骤，避免了消息被非法接收端窃取，提高了通信的安全性；

另一方面，由于在发送端与接收端之间建立了一对一的接收真实消息的通道，避免了接收端长时间在总线上监听消息，从而提高了响应速度和传输效率。

本发明提供的上述消息发送方法可以有多种实现方式。例如，对于上文中的发送端和接收端，发送端可以为发送客户端类，接收端可以为接收客户端类，或者，接收端也可以为接收客户端类的全部或部分对象。以下分别针对上述两种情况来进一步描述本发明。

实例一：发送端为发送客户端类，接收端为接收客户端类

图4示出了实例一的处理流程图，如图4所示，包括如下处理：

步骤S402：发送客户端(以下简称sendClient)取当前时间的毫秒数作为发送通道sendChannel的通道名，并建立发送通道sendChannel。

步骤S404：sendClient发送sendChannel名和“拟接收客户端类名”的第一消息到固定通道。

步骤S406：receiveClient使用固定通道监听总线上的所有消息，在监听到第一消息时，判断其自身类名是否是“拟接收客户端类名”，如果是，则继续执行后面的操作；否则，终止后续操作，通信结束。

步骤S408：用当前时间的毫秒数作为接收通道receiveChannel名，并建立该接收通道。

步骤S410：receiveClient通过sendChannel发送携带有接收通道名的第二消息给sendClient，通知sendClient可以根据接收通道名发送真实消息给receiveClient。

此时，用户可能创建了多个发送客户端sendClient对象，但由于使用了动态产生的唯一通道名，因此能保证本消息不会发送到其他发送客户端对象的通道。

步骤S412：sendClient发送第三消息，即真实消息到接收通道receiveChannel。由于receiveChannel的唯一性，保证了消息不会被其他非接收客户端窃取。

步骤S414：receiveClient在receiveChannel上接收真实消息，结束本次通信会话。

通过本实施例，可以实现给指定接收客户端类的所有对象发送消息，当用户创建了多个接收对象时，则每个接收对象都可以接收到该消息。

当发送端为发送客户端类，接收端为接收客户端类的对象时，其处理机制与前述情况相类似。

实例二：发送端为发送客户端类，接收端为接收客户端类的部分对象。

在该实例中，由于是向有限个对象而非全部对象发送消息，因此需要与每个对象分别建立通道进行上述处理，其他处理机制与实例一类似，在此不再赘述。

另外需要说明的是，在发送端发送消息后，并不能确保接收端一定能收到该消息，为了实现消息可靠到达接收端，可以在发送端在接收通道上发送消息之后，调用消息反馈机制。该机制需要在发送端设置一个定时器，在发送端在接收通道上发送消息之后启动预先设置好的该定时器，如果在上述定时器到时之前发送端收到了接收端发送的反馈信号，则可以确定接收到收到了消息，并关闭(杀死)定时器，如果在定时器到时之前没有收到接收端传来的反馈信号，则进行重传或其他操作。

具体地，为实现上述反馈机制，可以在发送客户端增加一个用于标识发送结果的成员属性，即可以通过成员属性的值来区分发送的成功与否，以决定是否要进行重新发送的操作。图5给出了该实现过程，如图5所示，包括以下处理：

步骤S502：在发送端增加用于标记发送结果的成员属性m_ack，令m_ack＝0；

步骤S504：在发送端设置定时器QTimer；

步骤S506：通过前述接收通道端发送消息给接收端；

步骤S508：启动定时器QTimer；

步骤S510：如果接收端收到消息，则发送反馈信号给发送端；

步骤S512：如果发送端接收到上述反馈信号，则设置m_ack＝1，此时，能确定消息可靠到达接收端，关闭定时器QTimer，过程结束。

如果发送端没有接收到反馈信号，QTimer超时，则进行其他相关处理(比如继续等待反馈或重新发送消息等操作)，过程结束。

通过本发明实施例提供的上述技术方案，通过在发送端增加用于标记发送结果的成员属性m_ack以及设置定时器QTimer等技术手段，实现了消息的可靠传递；另一方面，通过查看m_ack的状态，本实施例还可以实现查询当前有多少个接收客户端对象或判断有多少个接收线程在运行等功能。

在实际通信业务中，有时会有这样的需求，即，发送客户端类需要向接收客户端类中一定数量的有限个对象发送消息。在前述的实例二中，仅仅是向接收客户端类的部分对象发送消息，至于每一个对象是否真正接收到了消息，发送端不能确定，例如，发送客户端类向接收客户端类的五个对象发送消息，而实际上，由于通信过程中的一些其他原因，导致其中有一个对象并未收到消息，因此只有四个对象收到了消息，这与向五个对象发送消息的初始目标是不符的，因此，优选地，本发明在实例二的基础上引入前述的反馈机制，以下结合实例三来进行描述。

实例三

图6给出了该引入反馈机制后的处理流程，如图6所示，包括以下处理：

步骤S600：在发送客户端类中设置第一计数器counter1和第二计数器counter2，其中，第一计数器counter1用于表示允许接收消息的对象的数量，第二计数器counter2用于表示当前通信的对象的数量，初始值设置为0；

步骤S602：发送客户端类收到接收客户端类的某一对象发送的反馈信号；

步骤S604：第二计数器counter2的计数值加1；

步骤S606：判断第二计数器counter2的计数值是否大于或者等于第一计数器counter1的计数值；

步骤S608：如果判断结果为否，则发送客户端类执行向下一个接收客户端类的对象发送消息的操作；其中，如果判断结果为是，证明已经达到了允许接收消息的对象的数量，则不再发送消息，处理结束。

通过上述本发明实施例提供的技术方案，通过在发送客户端类中设置用于表示允许接收消息的对象的数量的第一计数器counter1和用于表示当前通信的对象的数量的第二计数器counter2等技术手段，可以实现可靠地向指定接收客户端类的一部分对象发送消息的功能。

容易想到上述实施例的一种等同的实施方式，在这种实施方式中，仅仅在发送客户端设置一个计数器counter，该计数器的初始值为0，并且为该计数器设置一个计数阈值，该阈值用于表示允许接收消息的对象的数量，同样地，在接收客户端接收到来自某个对象的反馈信号后，将计数器counter的值加1，判断计数器counter的计数值是否大于阈值，在判断结果为否的情况下，执行向下一个对象发送消息的操作，否则不再发送消息，处理结束。或者，将计数器的初识值设置为上述阈值，每接收到一次反馈信号，计数值减1，在减小到0的情况下，不再发送消息。

对于上述的计数器可以通过增加一用于表示数量的属性来实现，图7给出了通过属性m_contTimes实现的处理：

步骤S700：在发送客户端类中增加用于表示当前通信的对象的数量m_contTimes，其初始值为允许接收消息的对象的数量；

步骤S702：发送客户端类收到接收客户端类的某一对象发送的反馈信号；

步骤S704：将成员属性当前通信的对象的数量m_contTimes减1；

步骤S706：判断成员属性当前通信的对象的数量m_contTimes是否大于零；

步骤S708：如果m_contTimes大于零，则发送客户端类向接收客户端的下一个对象发送消息。

本发明实施例借助于在发送客户端类中增加表示当前通信的对象的数量m_contTimes等技术手段，可以实现可靠地向指定接收客户端一部分对象发送消息的功能。

综上，在本发明中：

1.针对目前的QCOP消息机制存在安全性问题，对QT提供的QCopChannel和QCopEnvelope类进行封装，在发送端和接收端建立唯一的通信通道，通过增加鉴别接收端的身份这一过程来传送消息，由于发送通道和接收通道都是唯一的、不为其他客户所知且不可猜测的，从而避免了消息被非法接收端获取，保证了通信的安全性。

2.针对现有技术中无法确定消息是否可靠发送的问题，在发送客户端发送消息之后增加了反馈机制，弥补了现有技术中消息传递可靠性不高的缺陷。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种基于软件总线扩展的消息发送方法，其特征在于，包括如下步骤，

发送端建立发送通道；

所述发送端通过固定通道向接收端发送携带有发送通道名以及拟接收端名的第一消息，所述第一消息不包含真实信息；

所述发送端接收所述接收端通过所述发送通道发送的第二消息，所述第二消息中携带有所述接收端建立的接收通道的接收通道名，其中，所述接收端在所述拟接收端名与其本身的名称一致的情况下建立所述接收通道；

所述发送端获取所述接收通道名，并在所述接收通道上向所述接收端发送消息。

2.根据权利要求1所述的方法，其特征在于，所述发送端建立发送通道具体包括：

动态生成特定字符串作为通道名；

根据所述通道名建立所述发送通道。

3.根据权利要求1所述的方法，其特征在于，在所述发送端发送所述第一消息之后，所述方法还包括：

所述接收端接收所述第一消息，并获取所述第一消息中的所述发送通道名以及所述拟接收端名称；

所述接收端将所述拟接收端名称与自身名称进行比较，在二者一致的情况下，所述接收端建立接收通道；

所述接收端通过所述发送通道将携带有接收通道名称的第二消息发送给所述发送端。

4.根据权利要求3所述的方法，其特征在于，所述接收端建立接收通道具体包括：

动态生成特定字符串作为通道名；

根据所述通道名建立所述接收通道。

5.根据权利要求1所述的方法，其特征在于，在所述接收通道上向所述接收端发送消息之后，所述方法还包括：

所述发送端接收来自所述接收端的反馈信号。

6.根据权利要求5所述的方法，其特征在于，所述发送端接收来自所述接收端的反馈信号具体包括：

所述发送端在发送所述消息之后启动预先设置的定时器；

在所述定时器到时之前接收到所述接收端的所述反馈信号的情况下，判断所述消息达到接收端，并关闭所述定时器；

在所述定时器到时之前没有接收到所述接收端的所述反馈信号的情况下，进行重传操作。

7.根据权利要求1至6中任一项所述的发送消息的方法，其特征在于，所述发送端为发送客户端类，所述接收端为接收客户端类。

8.根据权利要求1至4中任一项所述的发送消息的方法，其特征在于，所述发送端为发送客户端类，所述接收端为接收客户端类的全部或部分对象。

9.根据权利要求5或6所述的发送消息的方法，其特征在于，所述发送端为发送客户端类，所述接收端为接收客户端类的全部或部分对象。

10.根据权利要求9所述的发送消息的方法，其特征在于，

设置第一计数器和第二计数器，其中，所述第一计数器用于表示允许接收消息的对象的数量，所述第二计数器用于表示当前通信的对象的数量，初始值设置为0；

在所述第一计数器表示允许向部分对象发送消息的情况下，在接收到来自一个对象的反馈信号后，将所述第二计数器的计数值加1，并判断所述第二计数器的计数值是否大于所述第一计数器的值，在判断结果为否的情况下，执行向下一个对象发送消息的操作。

11.根据权利要求9所述的发送消息的方法，其特征在于，

设置计数器并将所述计数器的初始值设置为0，其中，所述计数器用于表示当前通信的对象的数量，所述计数器的计数阈值为允许接收消息的对象的数量；

在接收到来自一个对象的反馈信号后，将所述计数器的计数值加1；

判断所述计数器的计数值是否大于所述计数阈值，在判断结果为否的情况下，执行向下一个对象发送消息的操作。

Images