SSDP 简单服务发现协议

SSDP 简单服务发现协议,是应用层协议,是构成UPnP(通用即插即用)技术的核心协议之一。它为网络客户端(network client)提供了一种发现网络服务(network services)的机制,采用基于通知和发现路由的多播方式实现。

SSDP多播地址:239.255.255.250:1900(IPv4),FF0x::C(IPv6)

两种类型的SSDP请求消息会通过SSDP多播地址发送:

1. 发现请求(Discovery request 或查询请求)。SSDP客户端向此地址发送HTTP UDP 发现请求,查询某种类型的服务。SSDP服务在此地址上监听服务发现请求。当服务监听到的HTTP UDP 发现请求和它自己提供的服务匹配时,它以单播方式发送HTTP UDP 响应。

2. 存在通知(notification)。SSDP服务向此多播地址发送HTTP UDP 通知消息来宣布自己的存在。

发现结果(discovery results)和存在通知消息(presence announcements)提供的信息包括:

服务的类型URI

服务名称USN:唯一标识一种服务实例。

位置信息:发现结果和存在通知可包含一个或多个位置URI,客户端利用位置信息可以找到它需要的服务。

期限信息:客户端在自己的cache中保存此服务多长时间。如果期限过了,关于此服务的信息会被从cache中拿掉。当客户端接收到的发现结果或存在通知包含的USN和cache中的某条匹配,则更新。

客户端的服务缓存像下面这样:

【SSDP发现请求】ssdp:discover

ssdp:discover 必须包含一个ST头,客户端使用ST头来表明他们想发现的服务类型。ssdp:discover 必须包含一个带 *  的请求URI。

M-SEARCH * HTTP/1.1

S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6

Host: 239.255.255.250:1900

Man: "ssdp:discover"

ST: ge:fridge

MX: 3

各HTTP协议头的含义:

HOST:设置为协议保留多播地址和端口,必须是:239.255.255.250:1900(IPv4)或FF0x::C(IPv6)

MAN:设置协议查询的类型,必须是:ssdp:discover

MX:设置设备响应最长等待时间。设备响应在0和这个值之间随机选择响应延迟的值,这样可以为控制点响应平衡网络负载。

ST:设置服务查询的目标,它必须是下面的类型:

-ssdp:all 搜索所有设备和服务

-upnp:rootdevice 仅搜索网络中的根设备

-uuid:device-UUID 查询UUID标识的设备

-urn:schemas-upnp-org:device:device-Type:version 查询device-Type字段指定的设备类型,设备类型和版本由UPNP组织定义。

-urn:schemas-upnp-org:service:service-Type:version 查询service-Type字段指定的服务类型,服务类型和版本由UPNP组织定义。

SSDP服务发现自己的服务类型和ST中指明的服务类型匹配时,可以向ssdp:discover来自的IP地址/端口响应。响应消息应该包含服务的位置信息(Location 或AL头),ST和USN头。响应消息应该包含cache控制信息(max-age 或者 Expires头),如果两者都包含了,Expires 头优先,如果两者都缺失,那么这条服务消息不能被cache。

HTTP/1.1 200 OK

S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6

Ext:

Cache-Control: no-cache="Ext", max-age = 5000

ST: ge:fridge

USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6

AL: <blender:ixl><http://foo/bar>

各HTTP协议头的含义简介:

CACHE-CONTROL:max-age指定通知消息存活时间,如果超过此时间间隔,控制点可以认为设备不存在

DATE:指定响应生成的时间

EXT:向控制点确认MAN头域已经被设备理解

LOCATION:包含根设备描述得URL地址

SERVER:饱含操作系统名,版本,产品名和产品版本信息

ST:内容和意义与查询请求的相应字段相同

USN:表示不同服务的统一服务名,它提供了一种标识出相同类型服务的能力。

【SSDP存在通知消息】

SSDP服务通过存在通知消息来向客户端宣布自己的存在,更新期限信息,更新位置信息。

ssdp:alive 消息必须将 NT 设置成自己的服务类型,USN头设置成自己的USN。ssdp:alive 应该包括Location或者AL头,如果没有DNS支持的话,使用SSDP服务的IP地址来代表位置。ssdp:alive还应该包括cache控制信息,max-age或者Expires头。

NOTIFY * HTTP/1.1

Host: 239.255.255.250:reservedSSDPport

NT: blenderassociation:blender

NTS: ssdp:alive

USN: someunique:idscheme3

AL: <blender:ixl><http://foo/bar>

Cache-Control: max-age = 7393

ssdp:alive 没有响应消息。

SSDP服务可以发送ssdp:byebye 来宣布自己下线。ssdp:byebye 必须将NT设置成自己的服务类型,将USN头设置成自己的USN。ssdp:byebye 也没有响应消息。当客户端接收到ssdp:byebye 消息,删掉cache里面的相关条目。

NOTIFY * HTTP/1.1

Host: 239.255.255.250:reservedSSDPport

NT: someunique:idscheme3

NTS: ssdp:byebye

USN: someunique:idscheme3

【SSDP Auto-Shut-Off Algorithm】

A mechanism is needed to ensure that SSDP does not cause such a high level of traffic that it overwhelms the network it is running on.

【ssdp:all】

A mechanism is needed to enable a client to enumerate all the services available on a particular SSDP multicast channel/port.

【参考】

SSDP 协议原文:http://tools.ietf.org/html/draft-cai-ssdp-v1-03

http://www.cnblogs.com/debin/archive/2009/12/01/1614543.html

转 : http://blog.csdn.net/lilypp/article/details/6631951

时间: 2024-08-10 05:32:41

SSDP 简单服务发现协议的相关文章

Android网络服务发现(NSD)协议的使用

Android的网络服务发现协议(NSD)可以用于在小范围的网络中发现邻近设备上的某个应用.这对于一些社交网络.多人游戏类的应用会非常有帮助. Android的NSD的使用方法大致上分为四种操作: 1. 注册网络服务 2. 发现网络服务 3. 连接网络服务 4. 注销网络服务 使用NSD时一定要注意: 记得在Manifest中加入android.permission.INTERNET 权限,不然程序会崩溃. 一. 注册网络服务 注册网络服务需要两样东西: 网络服务的信息(NsdServiceIn

OcelotAPI 简单使用—服务发现、流控

我这人比较懒 直接上配置文件的图 其中serviceName是服务名称, LoadBalancer是负载均衡策略. 对于流控我为了做测试写的1s 限制5次请求. 剩下的看名字就OK了. 要使用服务发现 要有个先决条件就是consul .我这是为测试的demo ,把服务地址硬编码在consul的配置文件里了,启动consul 时指定该文件服务即注册了. 要想深入的了解Ocelot,中间件是必须要了解的. Ocelot是一个开发框架,要想用在真实的项目中我们肯定要它进行一些扩展.可以参考Ocelot

Spring Cloud官方文档中文版-服务发现:Eureka客户端

官方文档地址为:http://cloud.spring.io/spring-cloud-static/Brixton.SR7/#_spring_cloud_netflix 文中例子我做了一些测试在:http://git.oschina.net/dreamingodd/spring-cloud-preparation Spring Cloud Netflix This project provides Netflix OSS integrations for Spring Boot apps th

微服务架构下的服务发现

编者的话]这是关于使用微服务架构创建应用系列的第四篇文章.第一篇介绍了微服务架构的模式,讨论了使用微服务架构的优缺点.第二和第三篇描述了微服务架构内部的通讯机制.这篇文章中,我们将会探讨服务发现相关问题. 为什么要使用服务发现? 我们设想一下当正在写代码时,使用了提供REST API或者Thrift API的服务,为了完成一次服务请求,代码需要知道服务实例的网络位置(IP地址和端口).传统应用都运行在物理硬件上,服务实例的网络位置都是相对固定的.例如,代码可以从一个经常变更的配置文件中读取网络位

服务发现之美:Consul集群搭建

近几年随着Docker容器技术.微服务等架构的兴起,人们开始意识到服务发现的必要性.微服务架构简单来说,是一种以一些微服务来替代开发单个大而全应用的方法, 每一个小服务运行在自己的进程里,并以轻量级的机制来通信, 通常是 HTTP RESTful API.微服务强调小快灵, 任何一个相对独立的功能服务不再是一个模块, 而是一个独立的服务.那么,当我们需要访问这个服务时,如何确定它的地址呢?这时就需要服务发现了. Consul 是 HashiCorp 公司推出的开源工具,用于实现分布式系统的服务发

服务发现:Zookeeper vs etcd vs Consul

摘自:http://dockone.io/article/667 [编者的话]本文对比了Zookeeper.etcd和Consul三种服务发现工具,探讨了最佳的服务发现解决方案,仅供参考. 如果使用预定义的端口,服务越多,发生冲突的可能性越大,毕竟,不可能有两个服务监听同一个端口.管理一个拥挤的比方说被几百个服务所使用的所有端口的列表,本身就是一个挑战,添加到该列表后,这些服务需要的数据库和数量会日益增多.因此我们应该部署无需指定端口的服务,并且让Docker为我们分配一个随机的端口.唯一的问题

服务发现系统consul

1. 什么是consul? 是一个服务管理软件. 支持多数据中心下,分布式高可用的,服务发现和配置共享. consul支持健康检查,允许存储键值对. 一致性协议采用 Raft 算法,用来保证服务的高可用. 成员管理和消息广播 采用GOSSIP协议,支持ACL访问控制. ACL技术在路由器中被广泛采用,它是一种基于包过滤的流控制技术.控制列表通过把源地址.目的地址及端口号作为数据包检查的基本元素,并可以规定符合条件的数据包是否允许通过. gossip就是p2p协议.他主要要做的事情是,去中心化.

服务发现之 Etcd VS Consul

抄自这里 ************************************************************************************************ 网上找来找去都是zk和etcd的比较,和consul的比较很少,这个感觉还算靠谱,也在别的地方看到过对consul的吐槽,记录下 ***********************************************************************************

etcd:用于服务发现的键值存储系统

etcd是一个高可用的键值存储系统,主要用于共享配置和服务发现.etcd是由CoreOS开发并维护的,灵感来自于 ZooKeeper 和 Doozer,它使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性.Raft是一个来自Stanford的新的一致性算法,适用于分布式系统的日志复制,Raft通过选举的方式来实现一致性,在Raft中,任何一个节点都可能成为Leader.Google的容器集群管理系统Kubernetes.开源PaaS平台Cloud Foundry和CoreOS的