AllJoyn™ Transport

 

 

https://allseenalliance.org/framework/documentation/learn/core/system-description/alljoyn-transport

 

AllJoyn™ Transport

Overview

AllJoyn传输是AllJoyn应用间传输AllJoyn消息的具体机制的抽象，传输的AllJoyn消息包括：方法调用，方法的回复，属性获取/设置，或者信号。

AllJoyn传输提供了如下基本的功能：

·        创建和销毁AllJoyn应用程序之间的连接（通过AllJoyn路由器），以及AllJoyn应用和路由器之间连接的能力。

·        在AllJoyn应用程序和路由器之间可靠地发送和接收AllJoyn消息的能力。

·        可选项，提供适合底层网络技术的广播和发现服务。

AllJoyn传输支持在多种底层物理传输层上的连接建立和消息传输，包括TCP，UDP和本地UNIX传输。AllJoyn传输支持的底层传输方式的完整列表参见AllJoynTransportMask中的定义（AllJoynTransportMask definition）。应用程序可以指定使用何种传输方式来用于连接建立和消息传送。

基于连接端点的类型，AllJoyn传输功能可以分为以下几种：

·        本地AllJoyn传输(Local AllJoyn Transports)：本地AllJoyn传输旨在提供核心库和对应的AllJoyn路由器之间的通信。这支持应用与路由器之间的连接建立和消息路由。本地传输的详细信息请参见LocalAllJoyn Transports。

·        总线到总线AllJoyn传输(Bus-to-Bus AllJoyn Transports)：它提供路由器和路由器之间连接建立和消息路由。总线到总线传输的详细信息请参见 Bus-to-BusAllJoyn Transports。

Endpoints usage in AllJoyn Transports

正如在AllJoyn的终端（AllJoynendpoints）中提到的，AllJoyn传输使用端点来建立跨应用和路由器的连接和路由消息。AllJoyn端点类似于socket编程中的socket端点。一个AllJoyn端点是一个AllJoyn通信链路的其中一端。AllJoyn通信链路可能是一个应用程序和一个AllJoyn路由器之间的，也可能是两个AllJoyn路由器之间的。

AllJoyn系统中的端点分类如下所示：

·        本地端点(LocalEndpoint)：本地端点表示到自己的连接。在核心库中，它被用来提供到应用程序本身的连接；在AllJoyn路由器中，它提供到路由器本身的连接。本地端点表示一个在同一进程中的连接。

·        远程端点(RemoteEndpoint)：远程端点表示应用程序和AllJoyn路由器之间的连接。到应用程序的消息被路由到它的远程端点。一种特殊类型的远程端点是“总线到总线”端点，它代表两个AllJoyn路由器之间的连接。远程端点代表两个进程之间的连接。

下图显示本地和远程端点的概念。

Figure: Localand remote endpoints

该图显示AllJoyn应用程序和预装路由器之间的假想连接。AllJoyn应用和核心库交谈，核心库提供通往更大的AllJoyn分布式总线的网关。

核心库有两个主要的连接：到应用程序的连接，它通过所谓的本地端点提供；到路由器的连接，这是由一个远程端点来提供。

AllJoyn路由器也有相应的远程端点来表示与核心库的通信链路的端点，用于路由消息。AllJoyn路由器中的本地端点表示到路由器的连接，用于路由目的地为路由器的控制消息。

在分布式总线结构中多个应用程序可以连接到一个AllJoyn路由器。如下图所示，AllJoyn路由器都维护到每个连接的应用程序的远程端点（有多个远程端点的AllJoyn路由器）。

Figure: AllJoynrouter with multiple remote endpoints

虽然核心库和路由器都维护远程端点，但是他们在消息路由功能方面有所不同。AllJoyn路由器可以在远程端点之间移动（路由）消息，而核心库只能在一个本地端点和一个远程端点之间移动信息。

AllJoyn系统支持一个完整的分布式总线配置，路由器与其他路由器利用进行通信，它们将各自的总线分段成加入到一个分布式AllJoyn总线中，如下图所示。

Figure: AllJoyndistributed bus with bus-to-bus endpoints

在该图中，包括一个AllJoyn路由器和两个应用的一个总线分段显示在上半部分。另一总线分段也包括一个AllJoyn路由器和两个应用，显示在图片的下半部。

这两个总线分段通过被称为总线到总线的远程端点连接在一起。每个路由器都为它连接到其它所有路由器维护着一个总路到总线的端点。在图中，一个总线到总线端点表示到图中上面路由器节点的连接；另一个总线到总线端点表示到下面路由节点的连接。

作为AllJoyn传输的一部分，远程端点都搭配一个基底层通信机制。例如，总线到总线端点在路由节点可能由TCP传输或UDP的传输来管理，它们同时负责处理将消息从连接的一端移动到另一端。

对于连接核心库到AllJoyn路由器的远程端点来说，底层的通讯机制会随着所在主机的不同而不同。例如，在Linux系统上使用UNIX域套接字实现，而Windows系统上使用TCP实现。

Thin Core Library Endpoints

精简核心库（TCL：ThinCore Library）使用TCP传输，但是它的实现不同于核心库和AllJoyn路由器之间的正规TCP传输连接。

在TCL上，没有明确地划分出远程端点和本地端点。对于连接和并与Alljoyn路由器(在另一个设备上)上的TCP远端端点通信所需要的功能，TCL提供了一个最小的实现。

On the Routing Nodeside, a Thin Library device connects as if it was any local Core Libraryconnecting using a local TCP loopback connection. 在路由节点侧，精简库设备认为路由节点好像是任何一个本地核心库一样去连接它，和本地核心库的连接使用一个本地回环TCP连接。(这段没理解透……)

NOTE: Thisis how Bus Attachments connect to Routing Nodes in the Windows environment. TheTCP transport is used for the connection, but the data does not actually travelacross the network; but rather is "looped back" and sent back up thenetworking stack before being sent out on a connected IP network. 注意：这就是在在Windows环境中总线连接时如何连接到路由节点的。TCP传输用于连接，但数据实际上并不穿越网络；而是“环回”，在被送到了一个连接的IP网络上之前发送回网络堆栈。

精简库端点描述如下图。

Figure: ThinCore Library Endpoint

AllJoyn Transport in Networking Model

虽然AllJoyn传输的首要任务是输送，或者将AllJoyn消息从一个端点移动到另一个端点，但是还是要把它和ISO/OSI7层模型中传输层（4层）区分开。

下图显示了AllJoyn传输在7层ISO/OSI模型中的位置。

Figure: AllJoyntransport in the ISO/OSI 7-layer model

基于应用逻辑，这里存在一个AllJoyn消息层，它负责封装和解封装AllJoyn消息（信号和方法调用）。这一层看做位于ISO/OSI模型中的表示层（6层，presentationlayer）。

AllJoyn传输层将这些AllJoyn消息路由到它们预期的目的地。由于AllJoyn传输层管理整个网络中应用程序和AllJoyn路由器之间的连接，它可以被认为对应于ISO/OSI模型中的会话层（5层：sessionlayer）。AllJoyn传输层利用4层中的传输如TCP或UDP来管理各种网络实体之间的AllJoyn消息的实际运动。

由于AllJoyn传输封装了移动数据序列，建立连接，发布和发现等功能，对应于底层不同的传输机制，有不同的AllJoyn传输与之对应，如下所示。

·        AllJoyn TCP传输使用TCP/IP机制来移动数据。

·        AllJoyn UDP传输使用UDP/IP机制来移动数据。

·        AllJoyn蓝牙（BT）传输使用蓝牙连接。

·        AllJoyn本地传输使用UNIX域套接字。

AllJoyn传输方式的名称通常附和底层OSI第4层中使用的方法。

AllJoyn应用程序可以通过调用AllJoynAPI时指定一个或多个TransportMask位来选择采用的AllJoyn传输方式。目前定义的TransportMask位如下表所示。

AllJoyn TransportMask definition

Transport name	Value	Description
TRANSPORT_NONE	0x0000	No transport.
TRANSPORT_LOCAL	0x0001	The local transport. 本地传输
TRANSPORT_BLUETOOTH	0x0002	Bluetooth transport. 蓝牙传输
TRANSPORT_WLAN	0x0004	Wireless local area network transport. 无线局域网
TRANSPORT_WWAN	0x0008	Wireless wide area network transport (not currently supported).无线广域网(目前不支持)
TRANSPORT_LAN	0x0010	Wired local area network transport.有线局域网
TRANSPORT_ICE	0x0020	ICE (Interactive Connectivity Establishment) transport (not supported).交互式连接建立 NAT穿越技术（目前不支持）
TRANSPORT_WFD	0x0080	Wi-Fi Direct transport (not currently supported).WIFI直连传输(目前不支持)
TRANSPORT_ANY	0xFFFF & ~TRANSPORT_WFD	Any transport except Wi-Fi Direct. 除WIFI直连传输外的其他传输方式

注：目前，AllJoyn系统的WWAN，WLAN和LAN传输都是通过一个底层TCP传输来实现的。

如果AllJoyn应用希望只有使用TCP作为4层传输机制，它可以通过在广告，发现和会话加入和绑定中指定TRANSPORT_TCP。如果应用程序希望仅使用基于IP的传输机制，它可以指定TRANSPORT_IP，让AllJoyn系统自己在TCP和UDP之间做选择。

传输层建立和维护连接的通畅都基于底层支持的物理传输。根据底层物理传输的类型，AllJoyn网络的两个节点之间的实际连接可以是单跳的也可以是多跳的。AllJoyn分布式总线的网络拓扑并不一定直接映射到底层网络的拓扑结构。如果应用程序没有特别的偏好，它可以提供指定TRANSPORT_ANY，让AllJoyn系统自己决定采用何种底层传输方式。

Local AllJoyn Transports

AllJoyn本地传输是AllJoyn包含多种AllJoyn传输方式，它被设计用来提供核心库和其相关的AllJoyn路由器之间的通信。以下是用在AllJoyn系统中的本地传输方式：

·        Null Transport/空传输

·        UNIX Domain Socket Transport/UNIX域套接字传输

·        TCP Transport/TCP传输

Null Transport

本地传输中最简单的是空传输（Null Transport）。此传输的目的是提供一个核心库和一个捆绑路由器之间的连接，它们两个都位于同一个进程。在空传输的一个端点通过函数调用直接连接到另一侧。此时核心库和路由器之间的通信路径上不存在真正意义上的传输，通过直接的函数调用接口将它们连接在一起。

UNIX Domain Sockets Transport

在POSIX系统中使用的是UNIX域套接字传输，它提供核心库和预装AllJoyn路由器之间的进程间连接（IPC: inter-processconnection）。由于这是本地传输，所以不要求支持多个端点，或广告和发现。这种本地传输的实现被分割到核心库和AllJoyn路由器中。

TCP Transport

在Windows系统中采用的是TCP传输，它同样也提供核心库和预装AllJoyn路由器之间的进程间连接。由于不要求支持多个端点，也不要求广告和发现，相对于总线到总线版本的TCP传输，这里的TCP传输的实现大大简化了。有关TCP传输的细节的讨论，请参阅TCP传输机制(TCPTransport mechanism)。

Bus-to-Bus AllJoyn Transports

总线到总线AllJoyn传输完成AllJoyn路由器之间的连接建立和消息路由。AllJoyn系统中最常用的总线到总线的传输使用底层基于IP的传输机制，包括TCP传输和UDP传输

如前所述，应用程序可以指定使用何种AllJoyn传输来进行连接建立和消息传送。如果应用程序未指定的话，AllJoyn路由器选择一种方式来使用。TCP传输和UDP传输都是有效的AllJoyn传输。当在二者之间作出选择时，有许多权衡可以加以考虑。一般来说，人们更倾向于使用TCP。

下表是对于某些系统准则的AllJoyn TCP传输和AllJoynUDP传输的性能对比总结。

Performance of AllJoyn TCP Transport versus UDP Transport

System Criteria	TCP Transport	UDP Transport	Description
Number of Connections Supported	Low to medium	High	Due to high file descriptor usage, TCP Transport cannot support a very large number of simultaneous connections. UDP Transport uses only a single file descriptor for multiple connections, so it can support large number of simultaneous connections without reaching file descriptors system limit.
Memory Usage	Moderate	High	Since UDP Transport has to provide the reliability support, it requires much higher memory usage.
TTL-based Message Expiration	Not possible	Supported	UDP Transport uses the AllJoyn Reliable Datagram Protocol (ARDP), which supports TTL-based message expiration.
Types of Data Transfer	Performs best for bulk data transfer	Performs best for intermittent short data transfer	Default socket buffers for Layer 4 TCP connections are typically much larger than those for UDP connections. As a result, TCP performs much better for bulk data transfer.

下表列出一些TCP传输和UDP传输之间选择的用例场景，它基于上面的性能权衡对比。

AllJoyn use cases showing TCP vs UDP Transport selection

Use Cases	TCP Transport	UDP Transport
Dominant traffic is method calls 主流量是方法调用	X
Dominant traffic is bulk data transfer 主流量是大块数据传输	X
AllJoyn messages have TTL associated AllJoyn TTL相关消息	X
Large number of simultaneous sessions with intermittent RPC calls 大量间歇性RPC调用的并发会话	X
Very dirty RF conditions 非常噪杂的无线环境	X

AllJoyn TCP传输和UDP传输的细节在下面章节中描述。

TCP Transport mechanism

如前面提到的，AllJoyn TCP传输的名字来源于它使用TCP/IP 4层传输机制。由于TCP提供了一种可靠的数据流的保证，TCP传输只需要提供足够的机制来实现AllJoyn消息和字节流之间的转换。

TCP Transport data plane architecture

每个使用TCP传输的连接都有一个相关联的TCP端点（TCPEndpoint,），TCP流（TCPStream），TCP套接字（TCPsocket），如图所示。

Figure: TCPtransport data plane internal architecture

路由节点的路由功能连接到TCP端点，它代表TCP传输连接的远程端点。TCP端点使用TCP流组件，完成AllJoyn信息和字节流之间的转换。TCP流接收和发送流过TCP套接字的数据。

TCP endpoint lifecycle/TCP端点的生命周期

在端点的整个生命周期中，TCP端点经过多个状态。下面为TCP端点的状态转换图。

Figure: TCPendpoint lifecycle states

当主动发起连接请求时，或被动收到一个连接传入时，TCP端点都会被创建。TCP端点维护发生的事件是主动还是被动的连接信息。

TCP端点遵循一个AllJoyn线程的基本生命周期。首先在INITIALIZED状态下被创建。在被AllJoyn系统使用前，TCP端点必须进行认证。

认证是一个单独的步骤，在TCPEndpoint authentication phase中讨论。如果认证成功，TCP端点线程被要求开始运行，此时它进入STARTING状态。如果验证失败，TCP端点过渡到FAILED状态，然后准备被清理。

一旦被要求去支持一个新创建和验证通过的TCP端点的线程开始运行，端点进入STARTED状态。在这种状态下，TCP端点注册到路由器，这样数据就可以通过端点被转移。一旦不再需要连接，端点的stop()方法被调用，端点进入STOPPING状态。一旦运行在端点的所有线程都退出，端点进入JOINING状态，此时任何端点关联的线程都被Joined（采用POSIX线程的join概念，等待被回收资源）。然后端点从AllJoyn路由器中注销。当端点中线程相关的资源被清理晚，端点进入DONE状态，此时它可以从系统中删除。

TCP Endpoint authentication phase

如上所述，在消息被允许通过端点传送前，TCP端点必须完成认证阶段。认证阶段由一个单独的线程来处理，并下图所示。当TCP端点进入INTIALIZED状态，认证过程开始。

Figure: TCPendpoint authentication states

TCP端点验证使用简单身份验证和安全层（SASL：SimpleAuthentication and Security Layer）框架“匿名”的机制。在实际的AUTHENTICATING状态下，TCP流运行在字符串传输模式，以传输SASL盘问和响应（SASL challengesand responses）。如果SASL交换失败，认证进入到到FAILED状态，进而驱动TCP端点状态更改为FAILED。

如果SASL交换成功，认证转换到SUCCEEDED状态，进而又推动TCP端点过渡到STARTING状态。当TCP端点转变为STARTED状态，TCP流将切换模式，从之前的文本字符串切换到开始发送和接收AllJoyn消息。

一旦认证判定失败或成功，以及端点采取对应的生命周期动作，端点验证线程就退出，认证状态机过渡到DONE。

UDP Transport mechanism

顾名思义，AllJoyn UDP传输使用UDP/ IP协议来将AllJoynUDP传输从一台主机移动到另一个主机。由于UDP本身不提供可靠的保证，所以AllJoynUDP传输必须额外提供某种机制来提供可靠的消息传递。AllJoynUDP传输使用AllJoyn可靠数据报协议（ARDP：AllJoynReliable Datagram Protocol）来提供可靠的消息传递。ARDP大致基于可靠数据协议（RDP：ReliableData Protocol），RDP协议定义在RFC908（版本1）和RFC1151（版本2）。

UDP Transport data plane architecture

结构上，UDP传输可以分成两个大部件：连接到UDP端点的路由节点的路由功能，通过ARDP访问的UDP传输的网络功能。

UDP端点是路由节点和UDP传输之间的主要数据平面接口。从路由节点的角度来看，每个UDP传输连接由一个UDP端点表示。每个UDP端点有一个关联的ARDP流(ARDPstream)，ARDP流负责将AllJoyn消息转换成ARDP数据报。 UDP传输数据平面架构如下图所示。

Figure: UDPtransport data plane internal architecture

ARDP将消息流转换成数据报流，进而再和一个ARDP连接交谈。ARDP连接提供建立可靠性保证所需的端至端的状态信息，并和一个UDP套接字会谈， UDP传输管理的各种ARDP连接之间共享这个UDP套接字。

UDP Endpoint lifecycle

UDP端点的生命周期如下图所示。

Figure: UDPendpoint lifecycle

无论是主动还是被动连接请求构建时端点都被创建。类似于TCP的概念，主动连接是由本地发出的连接请求。被动连接是由远端发起的连接请求。类似于由RDP和TCP，ARDP协议也有一个三次握手过程。发出SYN请求的实体进入ACTIVE状态，回应SYN +ACK的实体进入PASSIVE状态。

不同于TCP和RDP，在SYN和SYN+ACK中，ARDP提供了额外的信息作为数据。在SYN，SYN+ACK，ACK交换（发生在ACTIVE和PASSIVE状态）过程中，所涉及的端点向它的远程同伴认证和识别。一旦这个阶段完成，端点进入STARTED状态，终端注册到路由节点。STARTED状态时可以发送和接收AllJoyn消息。

最终，当收到本地或远程的断开事件，连接会被停止。断开连接通过路由功能发起一个stop()调用到UDP端点来启动。这会导致状态从STARTED到STOPPING。对于本地断开事件，立即转移到WAITING状态。WAITING状态允许ARDP断开被执行前所有还在排队和传输中的消息可以被发送到远端。

注：与TCP不同，在ARDP中没有四次结束握手，在UDP传输状态机中这是由会话层来处理的。

一旦所有数据被传输和确认，就转移回STOPPING状态。在STOPPING状态下，各个线程被通知端点正在关闭。一旦线程被验证已经关闭，端点过渡到JOINING状态。这时资源被释放，被已被关联到端点的任何线程被joined（Posix线程中的join操作概念）。资源管理的最后一部分是从路由节点注销端点。当完成时，端点进入DONE状态，并准备好被终端管理功能删除。

ARDP state machine

ARDP是RDP的近亲，RDP被记录在RFC-908（第1版）和RFC-1151（第2版）。ARDP的核心是ARDP连接状态机。类似于TCP状态机，但ARDP状态机更简单，仅需要六个状态，如图中所示。

Figure: ARDPstate machine

如TCP一样，连接可能会主动或被动地开始。

本地主动发出的连接首先创建一个UDP端点，状态机转换到ACTIVE状态。端点提供了一个“介绍信”消息（"introduction"Message），并把它传递给ARDP，ARDP响应它，并建立一个连接，添加“介绍信”到SYN包并发送出去。发送完SYN报文后，本地ARDP连接进入SYN-SENT状态。远程ARDP处于LISTEN状态，它接收SYN和回调到UDP传输，给出“介绍信”，并通知已接收到一个连接请求。如果UDP传输确定该连接不应进行，就通知ARDP，然后ARDP发送一个RST包中止连接。

如果UDP传输确定该连接可以接受，它创建一个新的处于PASSIVE状态的UDP端点，并使用ARDP的“介绍信响应”（"introductionresponse"）回调来响应ARDP。被动方随后进入UDP端点PASSIVE状态，ARDP在SYN+ACK报文中发送“介绍信响应”给主动侧。当主动方收到SYN-ACK信息包，该ARDP状态机发送最后的ACK包，转换为OPEN状态，并通知UDP端点转换到STARTED状态。主动方然后准备发送和接收数据。当被动侧接收的最后分组的ACK，其三次握手过程完成。

它过渡到OPEN状态，并通知UDP端点过渡到STARTED状态。此时，双方都准备好发送和接收数据。

由于在本地UDP端点，本地ARDP，远程ARDP和远程UDP端点之间的交换可能会发生错误，双方都有看门狗定时器，如果未及时完成，看门狗就会中止该过程。

如上所述，ARDP连接还没有一个有序的关闭，继续在UDP端点状态机中完成它。通过接收或发送RST包来让ARDP转出OPEN状态。为了避免ARDP端口复用带来的问题，引入类似TCP的CLOSE_WAIT状态。

ARDP packet format

ARDP数据包的格式细节可以在RFC908和RFC1151中获得。这里扩展它，以支持AllJoyn消息粒度（替代UDP数据报）的，同时也基于TTL到期丢弃正在传输中的消息，这些扩展需要改变SYN和DATA包格式。

下表显示ARDP SYN分组格式。增加延迟ACK超时以支持类似TCP的延迟ACK功能。可变长度的数据和对应的数据长度字段也被加入。SYN+ ACK包以这种格式返回，但ACK位被设置。

ARDP SYN Packet Format

Fields
FLAGS (8 bits) / Header Length (8 bits)
Source Port (16 bits)
Destination Port (16 bits)
Data Length (16 bits)
Initial Sequence (32 bits)
Acknowledgement (32 bits)
Local Receive Window Size (16 bits)
Maximum Size of Receivable Datagram (16 bits)
Delayed ACK Timeout (32 bits)
Data (variable length)

下表显示ARDP数据分组（ARDPDATA packet）格式。的格式基本上类似于RFC908和RFC1151中描述的，但是添加了几个字段以支持新的功能。因为ARDP被设计为支持发送和接收AllJoyn消息，其可以跨越三个65535字节的UDP数据报，所以添加了一个消息分段（Messagefragment）的概念。这需要增加一个片段计数字段和消息开始序列号来识别该数据报对应于第一UDP数据报在一个AllJoyn消息的序列号。Time-to-Live被添加来支持AllJoyn消息到期超时功能（AllJoyn消息具有有限的生存时间）；消息超时后可能会被重传，为了协调消息超时，添加Acknowledge-Next字段。

ARDP data packet format

Fields
FLAGS (8 bits) / Header Length (8 bits)
Source Port (16 bits)
Destination Port (16 bits)
Data Length (16 bits)
Sequence Number of Current Segment (32 bits)
Acknowledge Number of Last In-Sequence Segment (32 bits)
Time to Live (32 bits)
Last Consumed Sequence Number (32 bits)
Acknowledge-Next (32 bits)
Start-of-Message Sequence (32 bits)
Fragment Count (16 bits)
Extended ACK Bitmask (variable length)
Data (variable length)

UDP transport configuration

ARDP是一个灵活的协议，因此有许多可配置参数。这些参数都可以通过AllJoyn路由器配置文件来设置。

Parameter name	Description	Default value
udp_connect_timeout	When an initial ARDP connection is attempted, the precipitating SYN packet may be lost. If, after some time, the foreign host does not respond, the connection must be attempted again. This value is the time period that ARDP waits before attempting to resend the SYN packet.	1000 msec
udp_connect_retries	When an initial ARDP connection is attempted, the precipitating SYN packet may be lost. If, after some time, the foreign host does not respond, the connection must be attempted again. This value is the number of times that ARDP will try to resent SYN packet before giving up.	10
udp_initial_data_timeout	When a data ARDP segment is sent, an RTO timer is started that determines when to resend the segment if an acknowledgment is not received. ARDP performs adaptive SRTT and RTO estimation using the TCP algorithm from RFC 6298. This parameter defines an initial RTO value which is used for a data segment only when no RTT estimates are available.	1000 msec
udp_total_data_retry_timeout	The overall time period for which a data segment should be retried before giving up and disconnecting the associated ARDP connection.	10000 msec
udp_min_data_retries	The minimum number of times a given ARDP data segment will be retransmitted. A data segment might be transmitted for more number of times than this value over the udp_total_data_retry_period.	5
udp_persist_interval	When the advertised window size on the foreign host goes to zero, it stops the (local) sender from transmitting data until the window becomes nonzero. Since ARDP does not reliably send ACK packets, it is possible to lose an ACK packet that reopens the window. In that case, the local and foreign sides could deadlock: the foreign side to receive data and the sender waiting for an ACK with a new window size. ARDP supports sending zero window probes (NUL packet) if it does not get update to the window after receiving a zero window ACK. The zero window probes are sent following an exponential backoff schedule. This parameter defines initial persist interval used as first timeout for the zero window schedule.	1000 msec
udp_total_app_timeout	The overall time period for which zero window probes should be sent before the associated ARDP connection is declared broken.	30000 msec
udp_link_timeout	ARDP is very interested in quickly determining when a link has gone down, idle or not. The idea is to guarantee that some data is present on the link at least once over a given interval. This may be data, ACK for that data, or a special NUL keep-alive packet.This parameter provides the default overall timeout period during which a broken link for a connection must be detected. A link timeout is used to compute the keep-alive interval for sending periodic keep-alive probes. This value is used only if the link timeout was not set by the app, otherwise the link timeout from the app is used.	30000 msec
udp_keepalive_retries	Provides the total number of times keep-alive probes will be sent before declaring the link as broken and terminating the ARDP connection.	5
udp_fast_retransmit_ack_counter	Similar to TCP, ARDP supports fast retransmission of segments based on the out-or-order EACKs (Enhanced ACKs) received. This value defines how many out-of-order EACKs should be received before ARDP performs the retransmission. A segment is fast retransmitted only once.	1
udp_timewait_timer	Amount of time that a connection should remain in the RDP Close_Wait state, to ensure that all outstanding packets that might be wandering around the network have died out for that connection. This behavior ensures that the port pair defining the ARDP connection cannot be reused for twice the expected lifetime of a datagram and therefore datagrams from an earlier incarnation of a connection cannot interfere with a current connection.	1000 msec
udp_segbmax	Maximum size of an ARDP segment as negotiated during connection setup. Since ARDP runs on top of UDP, this is determined based on the max UDP packet size. Since the maximum datagram size in UDP is 65535 bytes, the most efficient / maximum ARDP message size is the maximum size of UDP packet. Larger-sized AllJoyn messages are fragmented into the multiple segments required to carry those messages.	65507
udp_segmax	Maximum number of outstanding ARDP segments the receiver is willing to accept as negotiated during connection setup. This value governs how many segments can be in the flight and hence impacts the overall achieved throughput. The SEGMAX unit is ARDP segments. ARDP supports flow control through dynamic windowing in the message header. When data is received by ARDP and "checked in" to the ARDP receive queue, it is immediately acknowledged, but the receive window is decremented by 1. It is only when a datagram is delivered to the app, that the datagram is removed from the receive buffer and the receive window is incremented by 1.	50

Name Service usage by the AllJoyn Transport

TCP传输和UDP传输都提供相同的广告和发现能力。这两个传输都使用基于IP组播的名称服务作为他们的广告和发现机制。名称服务使用的底层IP（UDP）多播来实现广播和发现功能。名称服务在路由节点实现为一个独例，并同时由TCP传输和UDP传输通过各自控制平面访问。 [广告和探索] [广告发现]描述在AllJoyn系统的广告和发现中使用的传统名称服务和下一代名称服务（NGNS：Next-GenerationName Service）的细节，

Transport selection at the AllJoyn Router

对于发现来说，如果一个应用选择特定的传输（TCP传输或UDP传输），则FoundAdvertisedName()回调只发送给该传输方式。此外，如前面提到的，一个应用程序可以指定使用哪种传输方式来建立一个会话，AllJoyn路由器将尝试仅使用指定的AllJoyn传输来执行会话建立。

如果一个应用程序为指定使用何种AllJoyn传输来进行发现或会话建立，则AllJoyn路由器优先选择UDP传输。此行为主要是出于UDP传输需要更小的文件描述符资源，随着TCP传输作为连接的数量增长，这会是一个问题。

对于发现，如果一个应用程序不指示特定AllJoyn传输（即指定TRANSPORT_ANY），则FoundAdvertisedName()回调被同时发送给UDP传输和TCP传输，与UDP传输的回调首先发送。同样对于会话建立，如果应用程序指定采用TRANSPORT_ANY，如果连接的两个端点都允许UDP的话，AllJoyn路由器将使用UDP传输建立会话。如果UDP传输不可用，则会话将使用TCP传输。