物联网中的通信式.docVIP

物联网中的通信方式 　　：物联网中的通信 - 即设备如何向网络发送和接收数据 - 可以以不同的方式处理，通信方式主要由应用层中的协议来控制。了解数据在您服务中的设备周围的流动方式可以让您了解其可能的响应以及数据在设备之间的同步速度。 　　推（push），拉（pull）和轮询（polling） 　　作为一名UX（用户体验）设计师，您需要注意的关键因素包括： 　　设备如何将消息传输到网络中：它是定期推送（push）还是满足某些条件后再推送？还是仅当客户端设备（如智能手机应用程序）或者服务请求（pull：拉）它时才会传输（即）？ 　　设备如何从网络中接收消息：消息是否是从服务或者其他设备推送过来的，还是第一个设备根据需要请求它们接收的？ 　　设备连接频率：它是不断地持续连接，还是定期连接的，还是只有当它知道它需要连接时才连接？ 　　指令或数据可能多快通过？这是一个组合的问题包括以下的问题： 　　-设备建立连接需要多长时间 　　-连接可能有多快 　　-需要发送多少数据 　　-它可以多直接地被路由（任何信息要通过Internet可能需要花更长的时间） 　　如图1的例子所示，说明了您可能会遇到的一些问题： 　　电池供电加热控制器使用ZigBee每两分钟联系其网关登记注册其状态信息并寻求新的指令。这种方式称为轮询（polling）：控制器不知道什么时候会有新的指令，但必须定期地检查更新。 　　用户使用移动应用程序来加热使温度从19°C升高到21°C。该应用程序将该指令传递给Internet服务。网关设备定期轮询（polls）Internet服务并接收指令。 （网关具有主电源供电，因此可能会相当频繁地进行轮询，也许每隔几秒钟就轮询一次。）加热控制器（polls）轮询网关并接收指令。 　　 　　图1、加热系统中的轮询和推送 　　如果用户在加热控制器面前使用移动应用程序app时，则可能会看到控制器花费长达两分钟的时间来响应来自移动设备的命令。 　　在此期间，手机UI（用户接口）和控制器显示器将显示不同的状态信息，并且可能会不同步。手机可能会说是21°C，控制器则可能显示19°C。控制器反映系统当前的真实状态。在连贯性方面，这是一个连续性问题。 　　它可以更快地将指令从Internet服务推送到网关和设备中。但这通常不太可能通过家庭路由器来实现。大多数路由器向世界呈现的是单个公共IP地址，并将本地网络上的设备地址保留为私有（这种共享一个IP地址的技术称为NAT：网络地址转换（network address translation））。因此，服务器难以推送（push）到本地家庭网络上的设备或者从本地家庭网络上的设备中拉出（pull）信息。另外，安全防火墙也可能是一个问题。 　　所以，设备必须通过轮询来检查新的指令，这可能需要更长的时间。 　　如果用户使用安装在加热控制器设备上的控制来升温，则延迟可能会较短。控制器知道系统发生了变化，并通过集线器（hub）将更新信息的消息推送（push）到Internet服务中。它知道它需要连接，所以它不会等待计划的下一个轮询。如果用户的智能手机加热控制应用程序打开，那么它可能会每30秒向服务请求新的数据。所以如果用户在同一时间看着他们的智能手机加热应用程序，他们可能仍然会观察到不连续性，但可能只是一个短暂的延时。 　　智能手机和加热控制器正在轮询互联网服务以进行更新，这是一个拉（pull）的例子。当他们知道他们有最新的信息或者命令要分享时，那么它们两者都能够推送消息。 　　智能手机和加热控制器都不会保持与网络的持续连接，因为这样会耗尽电池的电量。但手机可以比控制器更频繁地检查更新，因为它的电源受到的限制较少。 　　虽然这种安排确实会暴露偶尔的不连续性，但是对于加热系统的应用情况，这些不会是灾难性的影响。大多数时候，用户不会拿着智能手机站在加热控制器的面前。另外在大多数时候，发出加热指令和实际开启指令之间的两分钟延迟滞后并不是一个问题：加热器的工作时间是以小时为单位的而不是秒。 　　轮询时间间隔太长可能会使服务感到反应太迟钝。例如，使用If This Then That（IFTTT）， 当有电子邮件从特定收件人传递到您的Gmail帐号上时Philips Hue bulb可以配置为闪烁或者更改颜色。虽然这是一个好主意，但是IFTTT只能每15分钟轮询一次Gmail（这可能是由Gmail限制的，以避免轮询太频繁而导致其服务器过载）。这意味着在收到电子邮件后15分钟内，灯泡可能不会响应。这是一个非常不及时响应的通知系统。 　　如果您希望设备能够快速响应命令，则要么必须保持打开连接以监听推送的命令，或者更频繁地进行轮询。给消费者推送通知的一个很好的例子是Google通讯录（Google Contacts）。如果您使用Web来更