ALLJOYN® SYSTEM DESCRIPTION

原文链接：https://allseenalliance.org/developers/learn/core/system-description

 

ALLJOYN® SYSTEM DESCRIPTION

Release history

Release version	Date	What changed
14.06	9/26/2014	Initial release
14.12	12/17/2014	Updates for new functionality added in 14.12 release: ·         UDP Transport design ·         TCP vs UDP Transport selection logic at the router ·         mDNS-based discovery for the router at the TCL ·         Updates to SLS fetch backoff design to support linear+exponential backoff ·         Router Probing mechanism to detect missing applications ·         Router logic to detect and disconnect slow reader nodes Other updates: ·         Endpoints usage by AllJoyn Transport ·         TCP Transport data plane architecture and state machine ·         AllJoyn Protocol Version mapping for different releases ·         Link timeout mechanism between routers to detect missing routers
15.04	4/29/2015	Updates In Thin Apps section related to: ·         Security and adding description of Router Selection ·         Some general clean up including fixing typos and readability and consistency changes Other changes: ·         General cleanup ·         Removed references to RSA and PIN authe mechanisms as they are not longer supported

This section describes in detailhow AllJoyn works at the system level.

System Overview

IoE overview

万物互联（IoE：Internet of Everything）是一个激动人心的远景，它将人与物，物与物之间互联起来；这将创造新的功能，更丰富的经验，和整体上使我们的生活变得更简单。IoE承诺将人，流程，数据和事物整合在一起，使网络连接比以往任何时候都更具相关性和价值的，将信息转化为行动，并使得以前想都不敢想的能力成为可能。

IoE将让家庭，办公室，汽车，街道，机场，商场等地的事物和设备都变得智能，这些设备将携手提供上下文和实时体验给用户。附近的IoE设备相互之间将形成近端IoE网络，例如，在家里，在车上，或者在一个办公室。IoE的愿景可以支持多个临近IoE网络之间的互联。

可以将今天的互联网和IoE做一个比较。今天的互联网是由数以百万计的注册顶级域名名称组成，它们统一由互联网号码分配机构（IANA）管理。这些域名的发现通过域名系统（DNS）的分层查询。在IoE网络中，将有可能高达数百亿的IoE设备。从可扩展性角度来看，这将不可能通过中央实体来管理登记所有这些设备。此外在一个IoE网络中，设备之间基于邻近性的相互作用减少了等待时间，并且不需要将每个设备都直接连接到互联网。因此，发现操作应该基于接近准则自动发生。在IoE网络中安全和隐私问题将更加重要，因为越来越多的个人和家庭设备暴露出它们的接口，用于连接和控制。

下图显示了一个IoE网络的例子，一个通过互联网相互连接的多个近端IoE网络。

Figure: IoE network example

每个IoE近端网络中的智能设备可以动态发现和通过点对点连接彼此通信。对于其中一些设备是在NAT后面的情况，他们可以通过一些基于云的发现服务来发现彼此。基于云的发现，也可用于不同IoE近端网络IoE设备间的发现和连接。整个IoE网络可以有更多的基于云的服务来提供特定的功能，例如，远程家庭自动化，远程诊断/维护，数据收集/报告等。IoE网络还可以整合现有的一些基于云的服务，例如，与Facebook和Twitter集成用于设备状态更新。

在任何IoE网络，网内和跨IoE近端网络中的设备之间的互操作性是极其重要的，这样就可以基于这些设备的应用和服务，形成一个功能丰富，可扩展的IoE生态系统。任何IoE系统都必须考虑的关键设计点包括：设备的广告和发现，移动性和动态IoE网络管理，安全性和保密性，跨多承载/ OS的互操作性，支持精简/哑设备的轻量级解决方案，可扩展性和整体可扩展性。一个IoE系统能够真正成功和适合不同情况，就必须是开放的，并且提供一种能够在不同垂直应用场景中使用的水平解决方案。

AllJoyn系统旨在解决这些关键的设计方面。它提供了一个开源软件框架，使邻近为主，对等网络，承载无关的IoE设备之间联网。AllJoyn系统提供了一种方法，让近端网络中的设备和应用程序使用点对点协议来广告和发现彼此。

AllJoyn开源软件系统提供了支持跨异构分布式系统的IoE设备间通信的框架。AllJoyn系统为分布式系统中的设备提供一个基于邻近性的，对等网络的通信平台。它不需要一个中央服务器来协调设备间的通信。 AllJoyn功能的设备上运行一个或多个AllJoyn应用，形成一个对等AllJoyn网络。AllJoyn系统是一个分布式的软件平台，为了使用这些设备提供的服务，运行在IoE设备上的应用程序通告，发现并连接到彼此。AllJoyn框架允许这些应用程序通过“可发现API”（discoverable APIs）来在网络上暴漏它们的功能，这些功能是应用程序对外的契约。

在近端AllJoyn网络，安装在IoE设备上的AllJoyn应用是对等的。一个AllJoyn的应用程序可以作为提供者，消费者或两者兼有，这取决于使用的服务模型。提供者应用程序实现服务，并在AllJoyn网络通告它的服务。对这些服务感兴趣的消费者应用程序通过AllJoyn网络发现它们。然后消费类应用连接到提供者的应用程序，根据需要使用这些服务。一个AllJoyn应用可以同时既作为提供者和也作为消费者。这意味着，该应用可以通告一组它支持的特定服务，并且还可以发现，利用由近端AllJoyn网络中的其他应用程序提供的服务。

下图显示了AllJoyn网络中的4个设备。

Figure: AllJoyn network

设备1和设备2只有提供AllJoyn服务的提供者应用程序。设备3只有消费者应用程序，它使用来自其他供应商的设备服务。装置4同时具有充当提供者和使用者的应用程序。设备4上的应用消费由设备2上的应用提供的服务，同时设备4还提供服务给设备3上的应用消费。从提供者到消费者的箭头方向说明服务的消费情况。

在AllJoyn框架为IoE设备间通信建立了一个底层总线架构。IoE设备上的AllJoyn应用程序通过AllJoyn总线连接和相互通讯。AllJoyn总线提供了一个框架给应用程序来暴露它的服务给其他AllJoyn应用。AllJoyn总线提供了一个平台和无线链路无关的传输机制给IoE设备应用来发送通知或交换数据。AllJoyn总线需要适配底层物理网络的传输机制。

每个AllJoyn应用程序都连接到本地的AllJoyn总线。可以有一个或多个应用程序连接到一个给定的本地AllJoyn总线。 AllJoyn总线可以让连接在它上面的AllJoyn应用发送广告，发现服务，并与其他设备通信。 多个设备上的AllJoyn总线之间通过底层网络技术相互通信，如Wi-Fi。

AllJoyn框架的开源实现提供了一个生态系统，各方可以通过添加新功能和增强功能到AllJoyn系统来作出贡献。它通过OS抽象层实现对操作系统无关性的支持，这就允许AllJoyn框架及其应用可以在多个操作系统平台上运行。AllJoyn框架支持大部分标准的Linux发行版，安卓2.3及更高版本，微软Windows操作系统，苹果iOS，Mac OS X中的常见版本，嵌入式操作系统（如OpenWRT），和实时操作系统（如ThreadX）。

AllJoyn框架还支持多种编程语言为为IoE设备编写应用程序和服务，这使得开发AllJoyn应用程序和服务的生态系统更广泛。AllJoyn架构目前，支持C，C ++，Java和C＃，JavaScript和Objective-C。

The AllJoyn system and D-busspecification

AllJoyn系统实现了D-Bus线协议，它兼容大多数版本，并且符合D-Bus规范中的许多命名惯例和准则。AllJoyn系统扩展和显著增强了D-Bus消息总线，以支持分布式总线方案。AllJoyn系统使用的D-Bus规范如下：

·        它使用了D-Bus的数据类型系统和D-Bus的数据编组格式。

·        它通过添加新的标志和标头（在消息格式（Message format）中详述）来实现一个增强版本的D-Bus线协议。

·        它使用的D-Bus命名规则来命名公知的名称（服务名称），接口名称，接口成员名称（方法，信号和属性）和对象的路径名。

·        它使用D-Bus定义的简单身份验证和安全层（SASL）框架，来为AllJoyn应用程序提供应用层的认证。它支持的认证机制超过D-Bus规范。

D-Bus规范可以在这里找到(http://dbus.freedesktop.org/doc/dbus-specification.html)。

AllJoyn system key concepts/ AllJoyn系统关键概念

如前所述，AllJoyn框架提供了一个底层总线架构来让应用发广告，搜索发现服务，并使用彼此的功能。为了实现这一目标，AllJoyn框架为应用之间交互提供了面向对象的软件框架。

AllJoyn router/ AllJoyn路由器

AllJoyn路由器组件为AllJoyn系统提供了核心功能，它支持的功能包括点对点的广告/发现，连接建立，广播信令和控制/数据消息的路由。AllJoyn路由器实现了软件总线的功能，连接到该总线的应用都可以享用该AllJoyn架构的核心功能。AllJoyn路由器的每个实例都有一个全局唯一标识符（GUID：globally unique identifier），它是自分配的。目前，GUID不是持久性的，所以每当AllJoyn路由器启动时，它就会被分配一个新的GUID。一个AllJoyn路由器既可以与每个应用程序捆绑在一起（捆绑模型），或者可以也可以是设备上的多个应用程序共享一个AllJoyn路由器（独立模型）如下所示。

Figure: AllJoyn bundled and standalone router examples

AllJoyn路由器有一个AllJoyn协议版本，定义它所支持的功能集。作为AllJoyn会话建立的一个步骤，当AllJoyn网络上的AllJoyn路由器之间建立连接时，它们会交换这个协议版本。

AllJoyn bus/ AllJoyn总线

AllJoyn路由器提供了软件总线的功能，一个或多个应用可以连接上它来交换消息。如下图所示，设备上的AllJoyn路由器实例形成到设备的本地逻辑AllJoyn总线，如下所示。

Figure: Logical mapping of AllJoyn router to AllJoyn bus

下面两种情况下，逻辑AllJoyn总线映射到一个单一的AllJoyn路由器：

·        只有一个应用的捆绑部署模型，如图中的UC2所示。

·        有一个或多个应用程序的独立部署模型，如图中UC3所示。

图中UC1实例的捆绑部署模型中，设备上有多个应用，每个应用捆绑一个AllJoyn路由器实例；此时逻辑AllJoyn总线映射到多个AllJoyn路由器实例。

*注： 在本文中，AllJoyn路由器和AllJoyn总线术语可互换，因为这些指同一组由AllJoyn系统提供的总线功能。

下图显示了一个简单的例子：有多个应用程序连接到两个设备上的本地AllJoyn总线。

Figure: AllJoyn bus

AllJoyn总线为连接到总线上的应用之间通信提供了媒介。 多个设备上的AllJoyn总线之间通过底层网络技术通信，如Wi-Fi。

多个设备的多个AllJoyn总线实例可以形成一个逻辑分布式AllJoyn软件总线，如下所示。

Figure: Distributed AllJoyn bus

分布式AllJoyn总线为多个设备上运行的应用隐藏了所有通信链路的细节。对于连接到AllJoyn总线的应用来说，运行在远端设备上的应用看起来就像运行在本地一样。 AllJoyn分布式总线提供了一种快速轻量级的方式将消息移动穿过分布式系统。

AllJoyn service/ AllJoyn服务

如前所述，提供者AllJoyn应用提供了AllJoyn网络中其他应用使用的服务。例如，一个电视可提供一种图像呈现服务，显示来自另一AllJoyn设备（例如，智能电话）的照片。AllJoyn服务是一个名义上的/逻辑概念，是由一个或多个AllJoyn接口（在AllJoyn interfaces中描述）定义，这些接口暴露它的服务功能给消费者。

一个AllJoyn应用可以通过同时提供服务和消费服务来同时充当提供者和消费者。

Unique name /唯一的标识符

每个AllJoyn应用程序都连接到一个AllJoyn路由器。为了能寻址每个应用，AllJoyn路由器会为每个链接的应用分配一个唯一的名称。这个唯一的标识符使用AllJoyn路由器的GUID作为前缀。它遵循以下的格式：

Unique Name = ":"<AJ router GUID>"."<Seq #>

注意：":.1"唯一的标识符总是给予AllJoyn路由器本地端点。

下图显示了一个GUID=100的AllJoyn路由器给链接到总线上的三个应用程序分配唯一标识符。

Figure: AllJoyn unique name assignment 1 (multiple apps connected tosingle AllJoyn router)

在这个例子中，一个设备上有多个AllJoyn应用，它们都连接到单个AllJoyn路由器上。据预计，大量AllJoyn功能的设备将是单一用途的设备（例如，冰箱，烤箱，灯泡等），并且将只有一个应用程在设备上，并且连接到AllJoyn总线。当然，可以有设备只有一个AllJoyn路由器实例，它支持多个应用程序，例如一台电视。

下图显示给拥有多个AllJoyn路由器实例的AllJoyn应用分配唯一标识符的例子，这个例子中，多个AllJoyn路由器实例形成AllJoyn总线。

Figure: AllJoyn unique name assignment 2 (each app has instance of AllJoynrouter)

注：唯一标识符中的GUID是不同的，它对应于所关联AllJoyn路由器的GUID。

下图显示给通过分布式AllJoyn总线连接的两个不同设备上的AllJoyn应用分配唯一标识符的例子。

Figure: AllJoyn unique name assignment 3 (AllJoyn apps on two devicesconnected over distributed AllJoyn bus)

Well-known name/公知名称

AllJoyn应用程序可以给它服务一个公知名称（well-known name）。公知名称是一种一致的方式来引用AllJoyn总线服务（或服务集合）。应用程序可以使用一个公知名称来代表它提供的所有服务，也可以多个公知名称来表示它的服务。

应用程序可以为它提供服务向AllJoyn总线请求一个或多个公知名称。如果所申请的公知名称无人使用，则授予该应用程序独占使用该公知名称。这确保公知名称表示AllJoyn总线上的唯一地址。公知名称的唯一性只在本地AllJoyn总线中保证。公知名称的全局唯一性必须通过遵循特定的命名准则和格式来实现。

AllJoyn公知名称沿用反向域名格式。分布式AllJoyn总线中可存在给定应用的多个实例，例如，在从相同品牌的两个冰箱在近端网络（一个在厨房和一个在地下室）运行相同的冰箱应用。为了区分AllJoyn总线上给定应用程序的多个实例，公知名称应该具有唯一的应用程序特定标识符作为后缀，例如，一个GUID标识该应用实例。

AllJoyn公知名称（WKN：well-known name）的命名遵循D-Bus规范准则，有以下格式：

WKN = <reverse domain style name for service/app>"."<app instance GUID>

例如，一个冰箱服务可以使用以下的公知名称：

com.alljoyn.Refrigerator.12345678

AllJoyn object/ AllJoyn对象

AllJoyn应用实现一个或多个AllJoyn对象以支持AllJoyn服务功能。这些AllJoyn对象被称为服务对象，并通过AllJoyn总线广告它们。其他AllJoyn应用程序可以从AllJoyn总线发现这些对象，并远程访问它们和消费它们所提供的服务。

一个消费者应用程序通过代理对象访问AllJoyn服务对象。代理对象是通过AllJoyn总线访问的远程服务对象的本地代表。

下图显示了AllJoyn服务对象和代理对象之间的区别。

Figure: AllJoyn service object and AllJoyn proxy object

每个AllJoyn服务对象实例都有一个对象路径来唯一标识对象实例。当一个服务对象在提供者上被创建，同时该对象的路径也被分配。代理对象需要对象路径来建立与远程服务对象的通信。对象路径的范围是一个给定的应用，所以对象路径在实现该对象的应用中必须是唯一的。因此，对象路径的命名并不需要遵循反向域命名约定，它可以是任何形式的，具体由应用程序选择。

该对象路径的命名通常也遵循D-Bus规范的命名规则。一个冰箱中实现的服务对象的对象路径可能是：

/MyApp/Refrigerator

AllJoyn interfaces/AllJoyn接口

每个AllJoyn对象通过一个或多个AllJoyn接口在AllJoyn总线上公开其功能。一AllJoyn接口定义了接口实现者和接口提供的服务的使用者之间通信的契约。AllJoyn接口是标准化的候选者，这样才可以保证支持AllJoyn的IoE设备之间的互操作性。

AllJoyn接口可以包括一个或多个以下类型的成员：

·        方法(Method)：一种方法是一个函数，通常调用它需要一组输入参数，然后使用输入进行一些处理，并通常返回一个或多个输出，来反馈处理操作的结果。注意，输入和/或输出参数不是强制要求的，也没有硬性规定方法要有一个返回值作为回馈。

·        信号(Signals)：信号是由服务生成的异步通知，它用来通知一个或多个远程对等体，事件或状态的改变。信号可以通过一个已建立的对等体的对等连接AllJoyn（AllJoyn会话）来传递，或者也可以全局广播到分布式AllJoyn总线中的所有AllJoyn对等体。信号可以是三种类型：

o    会话专用信号(Session-specific signals)：这些信号被传递到在近端网络中连接在给定AllJoyn会话的一个或多个对等体。如果指定了目的地，该信号仅被输送到连接在AllJoyn会话中的目的地节点。如果未指定目的地时，该信号被输送到连接在给定会话中，除了产生该信号的节点外的所有节点。如果会话是一个多点会话，这样的信号被多播到所有其他参与者。

o    会议广播信号(Session broadcast signals)：这些信号被传递给近端网络中所有通过任何AllJoyn会话连接的节点。

o    无会话信号(Sessionless signals)：这些信号被传递到近端网络中所有对无会话信号兴趣的节点。接收这种类型信号的节点们不需要通过一个AllJoyn会话来连接。无会话信号基本上是独立于会话的广播信号。

·        属性(Properties)：一个属性是保存值的变量，它可能是只读，读写或只写。

每个AllJoyn接口都有一个全局唯一接口名称，用来识别由该接口提供的一组方法，信号，属性。AllJoyn接口名称被定义为标准化的接口的一部分。类似于公知名称，AllJoyn接口名称也遵循反向域名格式和D-Bus规范的命名规则。

例如，冰箱可以支持以下标准AllJoyn冰箱接口。

org.alljoyn.Refrigerator

AllJoyn core library/ AllJoyn核心库

AllJoyn核心库公开AllJoyn总线功能给AllJoyn应用程序。每个应用程序链接一个AllJoyn核心库的实例，再通过它连接到AllJoyn总线。AllJoyn核心库充当应用与其它远程AllJoyn应用程序点对点通信的网关。它可以用于连接到总线上，广告服务，发现服务，建立和远程对等体的连接，消费服务，以及许多其他AllJoyn功能。应用程序向AllJoyn核心库注册对象，以便在AllJoyn总线来宣传它们。

下图显示3个应用程序通过AllJoyn核心库连接到一个给定的AllJoyn总线。

Figure: AllJoyn core library

AllJoyn核心库可以是一个标准核心库（SCL: Standard Core Library），用于开发AllJoyn标准应用，也可以是精简核心库（TCL：Thin Core Library），用于开发AllJoyn精简应用。文档中的大多数的系统设计使用标准核心库部署描述。对于精简核心库的设计细节，参见Thin Apps。

About feature

AllJoyn框架支持有关功能（About feature）作为AJ核心库的一部分。有关功能（About feature）可以让应用能够揭露它的一些关键信息有，包括应用程序名称，应用程序标识符，设备名称，设备标识，应用支持的AllJoyn接口列表等等。此功能由org.alljoyn.About对象实现的org.alljoyn.About接口提供。

应用程序通过About接口中的宣告信号（Announce signal）来广告关于它自己的关键信息。这个信号在近端AllJoyn网络中作为无会话信号来发送。有意通过AllJoyn接口发现服务的任何AllJoyn应用程序使用宣告信号来发现服务。About特性还提供了一种机制，通过直接的方法调用来获取应用程序数据。有关功能的设计细节请参阅[About HLD]。

AllJoyn endpoints

AllJoyn应用使用D-Bus格式的消息来交换数据。这些消息指定源和目的地端点（Endpoints）。AllJoyn端点代表AllJoyn通信连接的一端。Endpoints被用来将消息路由到相应的目的地。

核心库和AllJoyn路由器都维护端点以支持消息路由。核心库维护以下端点：

·        本地端点(Local Endpoint)：核心库中的本地端点代表到连接在核心库上的应用程序的连接。

·        远程端点(Remote Endpoint)：核心库中的远程端点代表到AllJoyn路由器的连接。它仅适用于AllJoyn路由器不捆绑的情况。

由AllJoyn路由器维护的端点通过唯一分配给它的唯一标识符识别。AllJoyn路由器支持以下端点：

·        本地端点(Local Endpoint)：本地端点是AllJoyn路由器本身的端点。它确认到它自己的连接，并用于在AllJoyn路由器之间交换AllJoyn控制消息。它是第一个得到分配的端点，总是使用唯一标识符":.1"

·        远程端点(Remote Endpoint)：远程端点标识应用程序和AllJoyn路由器之间的连接。目的地为应用程序的消息路由到应用程序的端点。

·        总线到总线端点(Bus-to-Bus Endpoint)：总线到总线（B2B：Bus-to-Bus）的端点是一种特殊的远程端点，它用来标识两个AllJoyn路由器之间的连接。此端点用作AllJoyn路由器之间路由信息的下一跳。

AllJoyn路由器维护一个路由表，负责将消息路由到不同类型的端点。两个AllJoyn路由器之间的控制消息（例如，AttachSession message）被路由到本地端点。两个应用程序之间AllJoyn消息被路由到应用程序的端点。这些消息将应用程序的端点作为消息中的源和目的地。两条AllJoyn路由器之间的消息（app-directed or control messages），把B2B端点作为下一跳。

下图显示AllJoyn系统中的不同端点。

Figure: AllJoyn endpoints

Introspection

AllJoyn系统支持的D-Bus定义的自我反省功能（introspection feature），它使得AllJoyn对象在运行时自省，返回描述该AllJoyn对象的自省XML。对象应该实现org.freedesktop.DBus.Introspectable接口。该接口有一个内省方法，调用它可以为对象检索内省XML。

AllJoyn entity relationship

了解上层AllJoyn实体之间如何相互关联是有用和重要的。

下图描述各种上层AllJoyn实体之间的关系，包括设备，应用，对象，接口，和接口成员。

Figure: AllJoyn entity relationship

一个支持AllJoyn功能的设备可以有一个或多个AllJoyn应用程序。每个AllJoyn应用程序可以有一个或多个实现所需应用功能的AllJoyn对象。应用程序的功能可以包括提供AllJoyn服务或消费AllJoyn服务或两者兼有。因此，由AllJoyn应用支持的对象可以是服务对象，代理对象，或两者的组合。服务对象通过一个或多个AllJoyn接口暴露它的功能。每个AllJoyn接口可以支持一个或者多个方法，信号和属性。

AllJoyn服务由一个或多个AllJoyn服务对象来实现。一个AllJoyn服务对象可以为一个或多个AllJoyn服务实现功能。因此，AllJoyn服务和AllJoyn服务对象有一个N：N关系，如下图所示。

Figure: AllJoyn service and AllJoyn service object relationship

AllJoyn services

一个AllJoyn应用程序可以支持一个或多个服务框架和一些应用层服务。

AllJoyn service framework

AllJoyn服务框架提供一些核心和基本的功能，可以基于它开发更高层的应用服务。服务框架位于AllJoyn路由器之上，并提供API给应用程序开发人员来调用它们的功能。初始AllJoyn服务框架包括配置服务框架，入职培训（Onboarding service）服务框架，通知服务框架，以及控制面板服务框架。

注：Service框架也被称为基础服务。

例如：冰箱应用可以利用入职培训服务框架将一台冰箱加入到家庭网络，并使用通知服务框架发送通知给用户设备。

Application layer service

应用层服务是由AllJoyn应用提供，用来实现期望的应用层功能。这些应用层服务可以使用服务框架来实现其功能。

例如：冰箱应用程序可以提供一个应用层服务来改变冰箱和冷冻室的温度。当设定温度超出指定范围时，该服务可利用通知服务框架发送通知给用户。

AllJoyn transport

AllJoyn传输（AllJoyn Transport）是一个抽象的概念，它可以通过AllJoyn路由器使连接建立和信息路由跨AllJoyn应用。AllJoyn传输支持在多个底层物理传输上，包括TCP传输，UDP传输和本地传输（如UNIX域套接字）传送消息。

AllJoyn传输可以基于应用的指定传输列表来逻辑递送广告和发现消息。同样，AllJoyn传输可以基于由应用作出的传输选择，支持会话建立和消息路由。AllJoyn传输所支持的底层传输方式由TransportMask指定，具体请参考 AllJoyn Transport in Networking Model。如果一个应用程序不指定任何传输方式，AllJoyn传输值默认为TRANSPORT_ANY。

参考 AllJoyn Transport 获得更多信息。

Advertisement and discovery

AllJoyn框架为应用程序广告和发现AllJoyn服务提供了方法。AllJoyn发现协议管理服务进出进来近场AllJoyn网络的动态特性，并及时通知AllJoyn应用程序状态的变化。AllJoyn框架利用底层传输机制来优化搜索发现过程。AllJoyn框架利用Wi-Fi IP组播来进行服务广告和发现。底层的技术细节对AllJoyn应用是隐藏的。

下面的章节详细介绍应用程序使用AllJoyn框架广告和发现服务的方式。

Name-based discovery

在基于名称的发现中广告和发现通常使用公知名称。在这种方法中，依照应用程序的判断发现（例如，如果一个众所周知的名字被未分配），唯一的名称也可以被用于发现过程。提供者应用在近AllJoyn网络中广告它支持公知名称，利用底层传输机制（IP多播通过Wi-Fi）。这些公知名称作为AllJoyn路由器所产生的广告消息的一部分被广告。

一个对某个公知名称感兴趣的消费者应用程序可以要求AllJoyn路由器开始发现这个名字。当提供者应用在近端网络中广告这个名字时，AllJoyn路由器接收到相应的广告。然后AllJoyn路由器为这个公知名称发送服务发现通知给消费者应用程序。

广告消息中携带返回到提供者应用的连接信息。在发现之后，消费者应用可以请求AllJoyn路由器建立与已发现的提供者应用的连接，以便来消费服务。AllJoyn路由器使用连接信息连接回提供者应用。

Announcement-based discovery

因为AllJoyn服务最终由一个或多个接口来实现，可通过发现相关的AllJoyn接口来实现服务发现。在基于公告的发现（announcement-based discovery）中，发布和发现服务使用AllJoyn接口名称。此机制用于设备来公布其功能。

提供者应用程序创建一个服务公告消息，指定由该应用程序支持的AllJoyn接口列表。该服务通告消息使用无会话信令机制（详细描述地在无会话信号Sessionless Signal）作为广播信号信息传递。

有意利用AllJoyn服务的消费者应用通过向AllJoyn路由器专门注册它兴趣接收的公告，来寻找这些广播业务的公告信息。当消费者设备处于提供者附近时，它接收包含由提供者所支持的AllJoyn接口的服务公告。

AllJoyn路由器维护连接回提供者的连接信息，这些信息包含在接收的服务公告信息中。发现服务后，消费者应用可以请求AllJoyn路由器建立与此提供者的应用的连接。AllJoyn路由器使用前面接收到的连接信息来连接回提供者应用。

Discovery enhancements in the 14.06release

AllJoyn发现功能在14.06发布版本中进行了增强，以更有效的方式来发现支持一组特定接口的设备/应用。增强的发现被称为下一代名称服务（NGNS: Next-Generation Name Service ）。NGNS支持基于多播DNS（mDNS）的发现协议，允许在一个线上发现消息中指定AllJoyn接口。此外基于mDNS的协议通过单播来提供发现响应，以提高发现协议的性能并最小化AllJoyn发现过程中产生的整体多播流量。

AllJoyn设备/应用的存在检测机制也得到了增强，这些通过添加基于mDNS的ping()消息来实现，该ping消息通过单播发送，用来确定远程端点是否仍然活着。该ping()机制通过基于应用程序逻辑的应用来驱动。

AllJoyn session

一旦客户端发现感兴趣AllJoyn服务，它必须与服务连接以消费该服务（通知服务框架除外，这完全依赖于无会话信号）。连接服务涉及到与该服务建立AllJoyn会话。会话是一个在消费者和提供者之间的流控数据连接，并且因此允许客户端与服务通信。

广告服务的提供者应用绑定与AllJoyn总线的会话端口，并监听要加入会话的客户端。绑定和侦听动作让提供者主持该会话。通常消费者和提供者应用事先都知道会话端口。在基于公告发现的情况下，会话端口通过通告消息来发现的。发现一个特定的服务之后，消费者应用程序通过指定会话端口和服务的唯一名称/众所周知的名称，请求AllJoyn路由器将远程服务加入会话，使远程服务成为一个会话加入者。在此之后，AllJoyn路由器建立消费者和提供者的应用之间的会话。

每个会话都有由提供者应用（会话主持者）分配一个唯一的会话标识符。一个AllJoyn会话可以是下列之一：

·        点至点会议（Point-to-point session）：只有两个参与者，会话主持者和会话加入者。

·        多方会话（Multi-point session）：有多个参与者，一个会话主持者和多个会话加入者。

会话建立后，用户应用程序必须创建一个代理对象与供应商的应用程序进行交互。应该使用会话ID和远程服务对象路径来初始化代理对象。一旦完成，用户的应用程序现在可以通过这个代理对象与远程服务对象进行交互。

Sessionless signals

AllJoyn框架提供了一种机制在在近端AllJoyn网络中广播信号。广播信号不需要建立任何应用层会话。这种信号被称为无会话信号，使用AllJoyn路由器支持的无会话信令机制来广播。

传送无会话信号递送有以下两个步骤。

1.     提供者设备（无会话信号发射者）广告：这里有无会话的信号接收。

2.     希望获得无会话信号的任何消费者设备将与提供者设备连接，并检索新的信号。

使用无会话信号机制，提供者的应用程序可以发送广播信号给AllJoyn路由器。AllJoyn路由器维护这些信号的缓存。无会话信号缓存的内容有版本信息。AllJoyn路由器发送一个无会话信号的通告消息，来通知其他设备：提供者设备有新的信号。无会话信号通告消息包括无会话信号特定的公知名，它指定无会话信号缓存的版本。

对收到无会话信号感兴趣的消费者应用进行发现操作，来发现无会话信号特定的公知名称。消费者的AllJoyn总线保持它已经从各提供者接收到的最新无会话信号版本。如果它检测到一个更新的无会话信号版本时，将取回新的一套无会话的信号，并提供给有兴趣的消费者应用。

Sessionless signal enhancement in the14.06 release

无会话信号功能在14.06发布版本中得到增强，消费者应用可以向支持一些期望AllJoyn接口的提供者应用请求无会话信号。无会话信号增强的部分如下所示：

·        无会话信号广告名称被增强，在无会话信号的报头中添加信息。消费者使用这些信息来只获取那些从它感兴趣的提供者发射出来的无会话信号。为无会话信号缓存中的每个唯一接口广告一个单独的无会话信号名称。

·        增加一个机制，让消费者应用表示只接受来自实施某些AllJoyn接口的应用宣布的无会话信号。

无会话信号是从那些支持所需接口的提供者哪里获取。这改善了无会话信号特征的整体性能。

Thin apps

AllJoyn精简应用程序是专为类如传感器的嵌入式设备使用。这些嵌入式设备为一组特定的功能进行了优化，并且在能量消耗，存储器和计算能力进行了限制。AllJoyn精简应用是设计用来将AllJoyn架构的好处带入嵌入式系统。精简应用被设计成具有非常小的内存占用量。

精简AllJoyn设备设备上运行轻量级的精简应用，这些精简应用使用AllJoyn精简核心库（AJTCL: AllJoyn Thin Core Library）。这些设备上不运行AllJoyn路由器，所以精简应用程序必须使用另一种AllJoyn功能设备上运行的AllJoyn路由器，借用该设备上运行的AllJoyn路由器功能。

在启动时，精简程序发现并与连上另一AllJoyn设备上运行的AllJoyn路由器。从此刻开始，精简应用将使用AllJoyn路由器实现核心AllJoyn功能，包括服务广告/发现，会话建立，信号传递等。如果精简应用是无法连接到以前发现的AllJoyn路由器，他会尝试去发现另外的AllJoyn路由器来连接。

一个AllJoyn精简应用与AllJoyn标准应用完全互操作。它采用和标准AllJoyn应用相同的一组线上协议（over-the-wire protocols）。这保证了精简应用和标准应用程序之间的兼容性。一个正在和精简应用通信的AllJoyn标准应用程序不会知道它的对端是一个精简应用程序，反之亦然。但是，基于可用的RAM大小，适用于精简应用程序的消息可能也会有大小限制。

AllJoyn protocol version

AllJoyn路由器实现的功能通过AllJoyn协议版本（AJPV：AllJoyn Protocol Version）标识版本信息。下表显示了各种AllJoyn发布版本的AJPV；除非另有说明，主版本的AJPV适用于所有补丁发布版。AllJoyn会话建立期间，AJPV作为BusHello消息的一部分在路由器之间交换，当叶节点连接到路由器时，在叶节点和路由器节点之间交换。核心库使用此字段用来识别与路由器的相容性，精简应用程序使用它来确定是否连接到一个特定的路由器或继续去寻找另一个路由器。路由器也可以使用它来确定某个功能在叶节点上是否可用（例如self-join, SessionLostWithReason等）

Table: AllJoyn Release to Protocol Version mapping

Release version	AJPV
legacy 03.04.06	9
v14.02	9
v14.06	10
v14.12	11
v15.04	12