CN105187387A - 一种服务发现方法及终端 - Google Patents

Abstract

本发明公开了一种服务发现方法及终端。本发明方法包括：终端使用第一发现协议向路由器发送服务查询请求消息，并启动对路由器广播消息的监听；若终端在第一预设时长内未接收到路由器对所述服务查询请求消息的广播消息，则判断路由器不支持所述第一发现协议，使用第二发现协议再次发送服务查询请求消息；若在第一预设时长内接收到所述广播消息，则判断路由器支持所述第一发现协议，所述终端继续等待第二预设时长；若在第二预设时长内接收到组播组成员对所述广播消息的响应消息，则与所述组播组成员建立连接，若在第二预设时长内未收到所述响应消息，则判断组播组内无可提供服务的成员。本发明可实现更加快速的检测和切换，提高服务发现的效率。

Description

一种服务发现方法及终端

技术领域

本发明涉及通信领域，尤其涉及了一种服务发现方法及终端。

背景技术

多屏互动随着智能设备的发展，得到了越来越广泛的应用。

多屏互动是指，基于DLNA(DigitalLivingNetworkAlliance，数字生活网络联盟)、AirPlay(苹果公司制定的无线通讯技术)等协议或者私有协议，通过无线局域网络连接，在不同的多媒体终端上，进行多媒体(如音频、视频、图片等)内容的传输、展示等操作。

其中，提供服务发现功能的发现协议是非常重要的一部分，其主要功能是发现本地网络中提供多屏互动服务的智能设备的地址，从而与所发现的智能设备建立连接，接受该智能设备提供的多屏互动服务。

发现协议基本都是基于网络组播原理实现的，即通过本地网络路由器实现数据包在组成员之间广播。目前，几乎所有发现协议都基于客户端默认认为路由器支持组播，没有有效的措施去检测路由器是否支持组播。因而导致在无法连接提供多屏互动服务的设备时，无法定位连接失败的原因，进而无法采取相应措施来解决问题。

不仅智能设备的多屏互动服务的实现过程存在上述问题，其他场景下的其他类型服务的实现过程也存在类似问题，比如物联网场景下的服务实现过程。

发明内容

为了解决上述问题，本发明实施例提供一种服务发现方法及终端。

本发明的一个实施例提供的服务发现方法，包括：

终端使用第一发现协议向路由器发送服务查询请求消息，并启动对所述路由器的广播消息的监听；

若所述终端在第一预设时长内未接收到所述路由器对所述服务查询请求消息的广播消息，则判断所述路由器不支持所述第一发现协议，使用第二发现协议再次发送服务查询请求消息；

若所述终端在所述第一预设时长内接收到所述路由器对所述服务查询请求消息的广播消息，则判断所述路由器支持所述第一发现协议，所述终端继续等待第二预设时长；

若所述终端在第二预设时长内接收到组播组成员对所述路由器发送的广播消息的响应消息，则与所述组播组成员建立连接，若在所述第二预设时长内未收到组播组成员对所述路由器发送的广播消息的响应消息，则判断所述组播组内无可提供服务的成员。

本发明的一个实施例提供的终端，包括：

发送模块，用于使用第一发现协议发送服务查询请求消息，并启动对路由器的广播消息的监听；

接收模块，用于接收路由器对所述服务查询请求消息的广播消息和/或组播组成员对所述路由器发送的广播消息的响应消息；

判断模块，用于在第一预设时长内所述接收模块未接收到所述路由器对所述服务查询请求消息的广播消息的情况下，判断所述路由器不支持所述第一发现协议，并指示所述发送模块使用第二发现协议再次发送服务查询请求消息；以及用于在所述第一预设时长内所述接收模块接收到所述路由器对所述服务查询请求消息的广播消息的情况下，判断所述路由器支持所述第一发现协议，继续等待第二预设时长；还用于在第二预设时长内所述接收模块接收到组播组成员对所述路由器发送的广播消息的响应消息时，指示连接建立模块与所述组播组成员建立连接；如果在所述第二预设时长内所述接收模块未接收到组播组成员对所述路由器发送的广播消息的响应消息，则判断所述组播组内无可提供服务的成员；

连接建立模块，用于根据所述判断模块的指示与所述组播组成员建立连接。

本发明的上述实施例中，由于路由器在支持发现协议的情况下，能够对终端发送的服务查询请求消息在相应组播组内发送广播消息，因此如果终端在发送服务查询请求消息后能够接收到路由器对该服务查询请求消息的广播消息，则可确认该路由器支持相应的发现协议，否则可确认该路由器不支持相应的发现协议。根据以上原理，本发明的上述实施例中，终端使用第一发现协议发送服务查询请求消息后，在第一预设时长内检测是否接收到路由器对所述服务查询请求消息的广播消息，如果没有，则使用第二发现协议再次发送服务查询请求消息；如果所述终端在所述第一预设时长内接收到路由器对所述服务查询请求消息的广播消息，并在第二预设时长内接收到组播组成员对所述路由器发送的广播消息的响应消息，则与所述组播组成员建立连接。可以看出，本发明实施例实现了在服务发现过程中对路由器是否支持组播功能的自动检测，并可在检测到路由器不支持组播功能时使用另一发现协议再次发送服务查询请求消息，以便发现能够提供服务的组播组成员。由于所述终端使用第一发现协议发送服务查询请求消息后若在第一预设时长内未接收到路由器对该服务查询请求消息的广播消息，即可确认该路由器不支持第一次发现协议，进而快速切换到第二发现协议再次发送服务查询请求消息，而不必等到第二预设时长到达，从而实现了快速的检测和切换，提高了服务发现的效率。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的网络结构示意图；

图2为本发明实施例提供的服务发现流程示意图；

图3为本发明实施例在多屏互动中正常工作场景下示意图；

图4为本发明实施例在多屏互动中无服务组员或组员关机场景下示意图；

图5为本发明实施例在多屏互动中路由器不支持组播或组播功能被关闭场景下的示意图；

图6为本发明实施例提供的终端的结构示意图。

具体实施方式

为了使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述，显然，所描述的实施例仅仅是本发明一部份实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

图1示例性地示出了一种可应用本发明实施例提供的服务发现方案的典型网络架构。

如图1所示，该网络架构中包括可提供服务的智能设备、能够使用服务的终端和实现设备间通信的路由器。

智能设备的数量可以是多个，智能设备的类型可以有多种，比如，所述智能设备可以包括能够提供多屏互动的电视设备。终端的数量可以是多个，终端的种类也可以有多种，比如，所述终端可以包括手机、平板电脑等。当然，图1中的智能设备也可由其他能够提供服务的电子设备代替，本发明实施例不再对该种能够提供服务的设备一一列举。

智能设备与终端之间可通过路由器进行信息交互，所述路由器可以是无线路由器。

为实现服务发现，可将能够提供服务的智能设备和能够使用服务的终端配置到组播组中。所配置的组播组的数量可以是多个，一个组播组可对应一种发现协议，不同的组播组所包含的组成员可以相同也可以不同。

图1中，路由器可以是支持组播功能的路由器，也可以是不支持组播功能的路由器。如果路由器是支持组播功能的路由器，则进一步地还可以支持多种发现协议。对于支持组播功能的路由器来说，其组播功能可由生成厂商默认配置，也可在出厂后允许用户自行修改，比如，可在路由器上配置多种发现协议，并开启其中的所有或部分发现协议。

不同的发现协议对应的组播组是不同的，表征为不同的发现协议对应不同的组播地址。例如mDNS发现协议(multicastDNS，组播DNS)对应于组播地址为224.0.0.251：5353的组播组，SSDP发现协议(SimpleServiceDiscoveryProtocol，简单服务发现协议)对应于组播地址为239.255.255.250:1900的组播组。当服务请求者与服务提供者同时处于同一个组播组时，通过本组播组地址对应的发现协议，两者间就可以实现交互，同时组播组外成员不能获得本组播组服务或者向本组播组内成员提供服务。

在服务发现过程中，首先由终端使用某种发现协议发起服务查询请求消息，在路由器支持所述发现协议的情况下，所述路由器对所述服务查询请求消息在组播组内发送广播消息，组播组中能够提供所请求的服务的成员对所述路由器发送的广播消息进行响应，所述终端根据该响应与能够提供服务的组播组成员建立连接，从而从该组播组成员获得所请求的服务。

通过上述服务发现过程可以看出，采用组播技术的发现协议依赖路由器对组播的支持。如果路由器不具有支持组播的功能或者该功能未开启，则会导致服务发现过程受阻，从而使得终端不能及时发现并获得服务，因此，为了解决现有技术中的不足，本发明实施例在此网络架构基础上提供了一种新的服务发现方法，以提高服务发现效率。

参见图2，为本发明实施例提供的服务发现流程示意图，该流程可包括如下步骤：

步骤201：终端使用第一发现协议向路由器发送服务查询请求消息，并启动对所述路由器的广播消息的监听。

该服务查询请求消息的内容和格式根据具体发现协议的不同而不同。一般地，该服务查询请求消息中包含所请求的服务的名称等信息，该服务查询请求消息的源地址为该终端的地址，目的地址为该第一发现协议对应的组播地址，目的端口号为该第一发现协议对应的组播端口号。

步骤202：若终端在第一预设时长内未接收到路由器对所述服务查询请求消息的广播消息，则转入步骤203，否则转入步骤204。

其中，终端在步骤201中所发送的服务查询请求消息被发送到路由器。如果路由器支持第一发现协议，比如，路由器上配置有第一发现协议且该发现协议被启动，则路由器可对该服务查询请求消息在对应的组播组内发送广播消息，路由器对该服务查询请求消息的广播消息的源IP地址为该终端的IP地址、源端口号为第一发现协议对应的组播端口号，这样，终端可接收到路由器对该服务查询请求消息的广播消息，这种情况下转入步骤204。

如果路由器不支持第一发现协议，比如，路由器上没有配置有第一发现协议或者该发现协议未被启动，则路由器丢弃接收到的该服务查询请求消息，这样，终端接收不到路由器对该服务查询请求消息的广播消息，这种情况下转入步骤203。

其中，一般情况下，终端通过检测接收到的消息中所包含的IP地址和端口号来判断该消息是否为路由器对所述服务查询请求消息的广播消息，如果消息中包含的源IP地址与自己的IP地址相同，且源端口号与组播端口号相同，则判断本消息即为路由器对所述服务查询请求消息的广播消息。

步骤203：终端判断所述路由器不支持所述第一发现协议，使用第二发现协议再次发送服务查询请求消息。

可选地，启用第二发现协议时，终端返回步骤201，重新向路由器发送使用第二发现协议的服务查询请求，并提示用户本次使用第二协议发送服务查询请求。

步骤204：若所述终端在所述第一预设时长内接收到所述路由器对所述服务查询请求消息的广播消息，则判断所述路由器支持所述第一发现协议，所述终端继续等待第二预设时长。

步骤205：若所述终端在第二预设时长内接收到组播组成员对所述路由器发送的广播消息的响应消息，则转入步骤206，否则判断所述组播组内无可提供服务的成员。

如果路由器支持第一发现协议，则路由器对该服务查询请求消息在对应的组播组发送广播消息。如果该组播组内有成员能够提供终端所请求的服务，则该组播组成员对所述路由器发送的广播消息返回响应消息，所述响应消息中携带提供服务的地址，包括监听的地址和端口号，终端将与此地址和端口号建立连接。

步骤206：终端与所述组播组成员建立连接。

上述流程中的第一发现协议和第二发现协议可以是以下发现协议中的一种：如SSDP发现协议(SimpleServiceDiscoveryProtocol，简单服务发现协议)，mDNS发现协议(multicastDNS，组播DNS)等。

上述流程中，第一预设时长的取值可根据网络拓扑、网络性能、路由器性能等因素来设置，在网络规模较大或者终端与路由器之间的通信时延较大时，可将第一预设时长的取值设置的大一些。通常，第一预设时长的取值可根据终端与路由器之间的通信时延、路由器的消息处理时延来设置，比如，第一预设时长的取值可以是1-2秒。

上述流程中，在终端在第一预设时长内接收到广播消息的情况下，终端继续等待第二预设时长。

第二预设时长的取值可以是一个固定时间长度，可根据网络拓扑、网络性能、路由器性能、智能设备的性能等因素来设置该第二预设时长，在网络规模较大或者终端与路由器、路由器与智能设备之间的通信时延较大时，可将第二预设时长的取值设置的大一些。通常，上述对第二预设时长的设置可根据终端与路由器之间的通信时延、路由器与智能设备之间的通信时延、路由器和智能设备的消息处理时延来设置。

所述第二预设时长的取值可以根据所述路由器对所述服务查询请求消息的广播消息被接收的时刻距离第一预设时长的时间起点，以及一个固定时长计算得到。例如，将上述固定时长记为T，T的取值大于所述第一预设时长，将第一预设时长的时间起点记为t0，将所述广播消息被接收的时刻记为t1，则所述预设第二时长的表达式为：T－(t1－t0)。

上述流程的步骤203中，终端使用第二发现协议再次发送服务查询请求消息之后，其处理过程与该终端使用第一发现协议发送服务查询请求消息之后的处理流程类似，在此不再赘述。

进一步地，如果终端使用第二发现协议再次发送服务查询请求消息之后，在第一预设时长内没有接收到路由器对该第二发现协议下的服务查询请求消息的广播消息，则可以使用另一种发现协议再次发送服务查询请求消息，以此类推，直到满足结束条件为止时才停止切换发现协议来发送服务查询请求消息。所述结束条件可包括但不限于以下之一或组合：

-终端在发送服务查询请求消息后，在第二预设时长内接收到组播组成员对所述路由器发送的广播消息的响应消息；

-终端已经切换完成其所支持的发现协议；

-终端切换发现协议的次数已经达到规定的最大次数；

-终端切换发现协议的过程所耗费的时间长度已经达到规定的最大时间长度。

上述本发明实施例的流程步骤中，优选地，终端发送服务查询请求消息之前，可根据预先设置的发现协议的使用顺序，确定服务查询请求消息需要使用的发现协议。发现协议的排序情况可根据需要来设置，比如可根据发现协议的效率的高低或者根据发现协议的通用性来设置。一种优选的实施例中，排列在前的发现协议的效率高于排列在后的发现协议的效率，从而使得按照从前到后的顺序，发现协议的效率呈降低趋势。由于预先设置发现协议的切换顺序，可以使得终端在需要切换协议更快的寻找到有效的发现协议。

上述流程中，可通过定时器来实现对第一预设时长进行计时。

具体地，在上述流程步骤201中，终端使用第一发现协议发送服务查询请求消息之后，启动定时器，定时器的计时长度为第一预设时长。若定时器到达第一预设时长，而终端在第一预设时长内未接收到路由器对所述服务查询请求消息的广播消息，则停止定时器，进一步地，使用第二发现协议再次发送服务查询请求消息时，可以再次启动所述定时器。若定时器到达第一预设时长，终端在第一预设时长内接收到路由器对所述服务查询请求消息的广播消息，则使用所述第二预设时长对所述定时器重置。由于终端通过设置定时器实现了对服务发现流程中时间的控制，而且第一预设时长设置的时间范围一般较短，从而使得终端在第一定时器预设时长内无法获得路由器对所述服务查询请求消息的广播消息时，迅速的切换到下一备选协议，重新发送新协议下的服务查询请求消息，提高整个服务发现流程的效率。

优选地，在上述流程步骤202中，若终端在第一预设时长内未接收到路由器对服务查询请求消息的广播消息，则输出路由器不支持第一发现协议的提示信息。其中，输出提示信息的方式包括但不限于文字提示、语音提示等。

优选地，在上述步骤205中，若终端在在第二预设时长内未接收到组播组成员对所述路由器发送的广播消息返回的响应消息，则输出路由器支持所述第一发现协议但组播组内没有成员能够提供所请求的服务的提示信息。其中，输出提示信息的方式包括但不限于文字提示、语音提示等。

通过在终端显示关于服务未发现或路由器不支持组播的具体情况的信息，使得服务发现流程对于用户更加透明化，使得用户可以在服务发现失败的情况下，区分失败的原因，进而采用相应的措施，提高了用户体验。

通过以上描述可以看出，本发明实施例可以快速自动实现服务发现，该方法允许多发现协议并存，且自适配，根据服务发现需要进行自动切换，还可以通过预先设置服务发现协议顺序来提高服务发现效率。本发明实施例利用多定时器实现了对服务发现流程的快速检测，尤其是在多发现协议的情况下，能够有效地提高服务发现效率。

为了更清楚地理解上述流程，下面基于图2所示的流程，以多屏互动服务为例，分别针对以下正常工作场景、无服务组员或者组成员关机场景、路由器不支持组播或组播功能关闭场景，描述本发明实施例的具体实现过程。

图3示出了正常工作场景下的服务发现过程。如图所示，终端发送服务查询请求消息，由于路由器支持组播，则路由器在组播组内对该服务查询请求消息发送广播消息，该终端在第一预设时长内收到路由器对该服务查询请求消息的广播消息；由于该组播组内的电视2能够提供服务，则该组播组成员对所述路由器发送的广播消息返回响应消息。终端在第二预设时长内收到该响应消息，并根据接收到的响应消息获取服务地址，与电视2建立连接，进行多屏互动。

图4示出了无服务组员或者组成员关机场景下的服务发现过程。如图所示，终端发送服务查询请求消息，由于路由器支持组播，则路由器在组播组内对服务查询请求消息发送广播消息，该终端在第一预设时长内收到路由器对该服务查询请求消息的广播消息；由于该组播组内的组员在接收到路由器对该服务查询请求消息的广播消息后均不能够提供服务，则不能向终端返回响应消息。终端在第二预设时长内收不到响应消息，因而无法获取服务地址，不能进行多屏互动。

图5示出了路由器不支持组播或组播功能关闭场景下的服务发现过程。如图所示，终端发送服务查询请求消息，由于路由器不支持该服务发现协议，则无法在组播组内对该服务查询请求消息发送广播消息，该终端在第一预设时长内不能收到路由器对服务查询请求消息的广播消息。因此，终端在第一预设长度到时判断路由器不支持该服务发现协议，在有备选发现协议的情况下，切换到下一发现协议，重新发送新发现协议下的服务查询请求。

通过上述流程可以看出，在本发明的实施例场景中，所述第一预设时长到时，对路由器组播功能的检测已经完成。由于路由器若支持组播功能，则在收到服务查询请求消息后后会立即发送广播消息，如果路由器不支持组播，本次服务发现过程结束，进入下一发现协议，整个过程耗时仅为第一预设时长。对于多个发现协议，如果路由器都不支持，则在多个第一预设时长内即可完成全部检测。而如果路由器支持组播，发现服务的耗时不会因为终端检测组播功能的引入而增加时间。

基于相同的技术构思，本发明实施例还提供了一种终端。

参见图6，为本发明实施例提供的终端的结构示意图，该终端可包括：发送模块601、接收模块602、判断模块603，连接建立模块604，其中：

发送模块601，用于使用第一发现协议发送服务查询请求消息，并启动对路由器的广播消息的监听；

接收模块602，用于接收路由器对所述服务查询请求消息的广播消息和/或组播组成员对所述路由器发送的广播消息的响应消息；

判断模块603，用于在第一预设时长内所述接收模块602未接收到路由器对所述服务查询请求消息的广播消息的情况下，判断所述路由器不支持所述第一发现协议，并指示所述发送模块601使用第二发现协议再次发送服务查询请求消息；以及用于在所述第一预设时长内所述接收模块接收到所述路由器对所述服务查询请求消息的广播消息的情况下，判断所述路由器支持所述第一发现协议，所述终端继续等待第二预设时长；还用于在第二预设时长内所述接收模块接收到组播组成员对所述路由器发送的广播消息的响应消息时，指示连接建立模块604与该发送响应消息的组播组成员建立连接；若在所述第二预设时长内所述接收模块未接收到组播组成员对所述路由器发送的广播消息的响应消息，则判断所述组播组内无可提供服务的成员；

连接建立模块604，用于根据所述判断模块603的指示与所述组播组成员建立连接；

进一步地，发送模块601还用于：在使用第一发现协议发送服务查询请求消息以及使用第二发现协议发送服务查询请求消息之前，根据预先设置的发现协议的使用顺序，确定服务查询请求消息需要使用的发现协议；其中，排列在前的发现协议的效率高于排列在后的发现协议的效率。

具体地，判断模块603还具有：在所述发送模块601使用第一发现协议发送服务查询请求消息之后，启动定时器，所述定时器的计时长度为第一预设时长。若所述接收模块602在所述定时器计时的第一预设时长内，未接收到路由器对所述服务查询请求消息的广播消息，则停止所述定时器，进一步地，指示所述发送模块601使用第二发现协议再次发送服务查询请求消息时，可以再次启动所述定时器。若所述接收模块602在所述定时器计时的第一预设时长内接收到所述路由器对所述服务查询请求消息的广播消息，则使用所述第二预设时长对所述定时器重置。

进一步地，判断模块603还用于：在判断所述路由器不支持所述第一发现协议时，输出所述路由器不支持所述第一发现协议的提示信息。

判断模块603还用于：在判断所述组播组内无可提供服务的成员时，输出所述路由器支持所述第一发现协议但组播组内没有成员能够提供所请求的服务的提示信息。

综上所述，由于路由器在支持组播发现协议的情况下，能够对终端发送的服务查询请求消息发送广播消息，因此如果终端在发送服务查询请求消息后接收到路由器对该服务查询请求消息的广播消息，则可确认该路由器支持相应的组播发现协议，否则可确认该路由器不支持相应的组播发现协议。根据以上原理，本发明的上述实施例中，终端使用第一发现协议发送服务查询请求消息后，在第一预设时长内检测是否接收到路由器对所述服务查询请求消息的广播消息，如果没有，则使用第二发现协议再次发送服务查询请求消息；如果所述终端在所述第一时间长度内接收到路由器对所述服务查询请求消息的广播消息，并在第二预设时长内接收到组播组成员对所述路由器发送的广播消息的响应消息，则与发送所述响应消息的组播组成员建立连接。可以看出，本发明实施例实现了在服务发现过程中对路由器是否支持组播功能进行自动检测，并可在检测到路由器不支持组播功能时使用另一发现协议再次发送服务查询请求消息，以便发现能够提供所请求服务的组播成员。由于所述终端使用第一发现协议发送服务查询请求消息后若在第一预设时长内未接收到路由器对该服务查询请求消息的广播消息，即可确认该路由器不支持第一次发现协议，进而可快速切换到第二发现协议再次发送服务查询请求消息，而不必等到第二预设时长到达，从而实现了更加快速的检测和切换，提高了服务发现的效率。

结合本发明实施例所公开的方法的步骤可以直接体现为软件模块组合执行完成。这些软件模块可以具体实现这里描述的功能。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。存储器单元可以在处理器内或者在处理器外实现。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种服务发现方法，其特征在于，包括：

终端使用第一发现协议向路由器发送服务查询请求消息，并启动对所述路由器的广播消息的监听；

若所述终端在第一预设时长内未接收到所述路由器对所述服务查询请求消息的广播消息，则判断所述路由器不支持所述第一发现协议，使用第二发现协议再次发送服务查询请求消息；

若所述终端在所述第一预设时长内接收到所述路由器对所述服务查询请求消息的广播消息，则判断所述路由器支持所述第一发现协议，所述终端继续等待第二预设时长；

若所述终端在第二预设时长内接收到组播组成员对所述路由器发送的广播消息的响应消息，则与所述组播组成员建立连接，若在所述第二预设时长内未收到组播组成员对所述路由器发送的广播消息的响应消息，则判断所述组播组内无可提供服务的成员。

2.如权利要求1所述的方法，其特征在于，还包括：

若所述终端判断所述路由器不支持所述第一发现协议，则输出所述路由器不支持所述第一发现协议的提示信息。

3.如权利要求1所述的方法，其特征在于，还包括：

若所述终端判断所述组播组内无可提供服务的成员，则输出所述路由器支持所述第一发现协议但组播组内没有可提供服务的成员的提示信息。

4.如权利要求1所述的方法，其特征在于，所述终端使用第一发现协议发送服务查询请求消息时，还包括：启动定时器，所述定时器的计时长度为第一预设时长；

若所述终端在所述定时器计时的第一预设时长内未接收到路由器对所述服务查询请求消息的广播消息，则还包括：停止所述定时器；

若所述终端在所述定时器计时的所述第一预设时长内接收到所述路由器对所述服务查询请求消息的广播消息，则还包括：使用所述第二预设时长对所述定时器重置。

5.如权利要求1至4中任一项所述的方法，其特征在于，所述终端使用第一发现协议发送服务查询请求消息以及使用第二发现协议发送服务查询请求消息之前，还包括：

根据预先设置的发现协议的使用顺序，确定服务查询请求消息需要使用的发现协议；其中，排列在前的发现协议的效率高于排列在后的发现协议的效率。

6.一种终端，其特征在于，包括：

发送模块，用于使用第一发现协议发送服务查询请求消息，并启动对路由器的广播消息的监听；

接收模块，用于接收路由器对所述服务查询请求消息的广播消息和/或组播组成员对所述路由器发送的广播消息的响应消息；

判断模块，用于在第一预设时长内所述接收模块未接收到所述路由器对所述服务查询请求消息的广播消息的情况下，判断所述路由器不支持所述第一发现协议，并指示所述发送模块使用第二发现协议再次发送服务查询请求消息；以及用于在所述第一预设时长内所述接收模块接收到所述路由器对所述服务查询请求消息的广播消息的情况下，判断所述路由器支持所述第一发现协议，继续等待第二预设时长；还用于在第二预设时长内所述接收模块接收到组播组成员对所述路由器发送的广播消息的响应消息时，指示连接建立模块与所述组播组成员建立连接；如果在所述第二预设时长内所述接收模块未接收到组播组成员对所述路由器发送的广播消息的响应消息，则判断所述组播组内无可提供服务的成员；

连接建立模块，用于根据所述判断模块的指示与所述组播组成员建立连接。

7.如权利要求6所述的终端，其特征在于，所述判断模块还用于：

若判断所述路由器不支持所述第一发现协议，则输出所述路由器不支持所述第一发现协议的提示信息。

8.如权利要求6所述的终端，其特征在于，所述判断模块还用于：

若判断所述组播组内无可提供服务的成员，则输出所述路由器支持所述第一发现协议但组播组内没有可提供服务的成员的提示信息。

9.如权利要求6所述的终端，其特征在于，所述判断模块还用于：

在所述发送模块使用第一发现协议发送服务查询请求消息时，启动定时器，所述定时器的计时长度为第一预设时长；

所述判断模块具体用于：

若判断所述路由器不支持所述第一发现协议，则还包括：停止所述定时器；

若判断路由器支持所述第一发现协议，则还包括：使用所述第二预设时长对所述定时器重置。

10.如权利要求6至9中任一项所述的终端，其特征在于，所述发送模块还用于：

在使用第一发现协议发送服务查询请求消息以及使用第二发现协议发送服务查询请求消息之前，根据预先设置的发现协议的使用顺序，确定服务查询请求消息需要使用的发现协议；其中，排列在前的发现协议的使用频率高于排列在后的发现协议的使用频率。