本文作者J.Walker 先生，英国NDS公司成员；O.J. Morries先生，英国Philips公司成员；B.Marusic先生，斯洛文尼亚Lijubljana大学成员。原文刊登于《IBC 2003论文集》，版权归IBC所有。孙松林先生译。
五 端到端的结构
在分析完系统设计要求后，我们需要设计端到端的系统体系结构。为此，首先定义一个分层模型，分析现有的候选技术，并将他们映射到以前确定的各个层，为了更好地选择硬件，需要再一步步细化各种选择，并确定解决方案之间存在的差距，进而开发新技术或修改已有的技术。
从最终系统结构的最高层来看如图5所示。
图5 系统结构图
1. 系统概念和标识符
很多对等网络的核心思想，就是将拥有相似喜好的对等组或对等团体集中起来。在Share it！中，这一思想仍然有效，但是我们将其扩展到用户组上。用户组具有三个属性，它们定义了用户如何在该用户组中和其他用户之间进行交互。这些属性分别是：
●成员资格—受限的或不受限的；
●发布权限—有节制的和无节制的；
●可见性—隐藏或可见。
这些属性的各种不同组合产生了不同的组类型，例如：
●不受限、无节制的可见组，例如，法拉利爱好组就是一个简单的自管理组，组成员对一个既定的主题感兴趣。所有的组成员都可以说明组关心的内容；
●不受限、有节制的可见组，例如，BBC EastEnders栏目组，一个简单实体(如BBC)就能表明组成员都感兴趣的公共内容；
●受限、无节制的隐藏组，例如，家庭组本身就对非组成员不可见，任何组成员都可以在组内发布内容。
在Share it！里，我们需要支持一系列内容共享的模型，如广播内容和家庭制作的内容。他们存在不同的可见性要求，比如，家庭制作的内容可能会有一些隐私要求，而对于广播内容就不需要。到此为止，我们已经定义了公共内容和私有内容——用户可以随意观看公共内容，而私有内容则不可以(注意：即使你可以看到公共或私有内容，你也有可能不具有获取、消费或共享它的权限)。
公共内容可以从任何一种用户组中访问，然而私有内容只对有限的拥有成员资格的用户组开放。一般而言，广播内容可以公开；但家庭制作的内容既可能是私有的，也可能是公开的。原则上讲，私有内容可能被用作非法传播的一种途径(就像今天不受限的对等网络那样)，所以需要一个检查跟踪机制以指明私有内容的网络出处。
该系统还需要用很多标识符来表示各种不同的实体，比如用户、设备、内容等，特别是内容标识最容易出问题。在证实系统中，我们采用TV-Anytime内容参考标识符(CRID)，但是这却把CRID的范围延伸到原本希望的运用之外了。当用在对等内容中时，CRID就存在缺陷；最初它只是用在受限实体上，用在广播网而不是用在分布式网络中的实体上。
2. 对等协议，发现和搜索内容
在测试阶段，该项目确定了一些候选对等协议，包括JXTA、UPnP和Gnutella。虽然UPnP是家庭内部网络结构中常用的协议，但由于不具有可扩展性，所以限制了它在这种家庭到家庭网络结构中的应用。Gnutella协议比JXTA更基本，因而我们最初想扩展Gnutella来支持所需的功能，或者使用更完善但是较“笨重”的解决方案—JXTA。最终，我们选择JXTA，是因为它是一个公开的对等协议，并由Sun微系统公司初创。
JXTA提供一个用于分布应用的平台，互联的对等端可以在对等系统中互相定位、参加团体活动并相互提供服务。JXTA是与编程语言、系统和网络平台无关的协议。
对等组是JXTA底层结构的核心，一个对等组是全局内所有对等成员的一个子集。单个参加者可以同时属于多个组。JXTA提供协议核以实现对等成员的发现、资格认证和监控。JXTA使用异步方式、单向通信通道、呼叫管道来发送和接收消息。所有数据交互在JXTA中都是以XML格式文档形式进行的。JXTA提供很多Share it！对等功能，还包括JXTA对等组和Share it！用户组之间的直接映射。我们已经开发了一个位于JXTA协议之上的软件层并为Share it！定义一个新的JXTA对等成员和对等组服务。
●发布、搜索、建议和通知服务(位于JXTA解析服务之上使用TVA支持的应用消息格式)；
●用户组成员资格服务(包括集中式和分布式)；
●权限交涉服务；
●带有地址簿功能的聊天服务；
●隐藏用户组推荐服务。
Share it！按照TV-Anytime规范定义了查询和应答的格式，并将其封装到JXTA格式中，因此我们就可以借用JXTA机制在网络中承载这些格式。
对于每个对等网络，性能扩展性是很关键的问题，当考虑一个拥有很多对等用户设备的潜在的大网络时，就更要注意这个问题了。JXTA结构包括两种具有可扩展性的解决方案：除了前面提到的组概念，还有一种是超对等用户覆盖网，称为聚集对等用户，它能提供一种有效的方法来缓存和转发系统消息。虽然用户还需要知道去查哪个对等用户组，但JXTA对等组机制的应用为用户搜索结果提供了附加价值。更重要的是，为对等用户提供了一种有效的机制以生成查询范围，这些用户往往拥有相关的内容。尽管在保证扩展性上更加有效，但由于JXTA提供的搜索中心本身具有集中特性，所以我们并没有考虑它们。
当考虑目前典型机顶盒产品中的资源时，完整的JXTA实现参考的确有很大的影响，并且我们将继续考察如何改变这个影响，使它更加适用于该项目的STB设备。
3. 内容传送
在很多著名的IP内容传送协议中，我们选择HTTP作为内容下载协议以及RTP/RTSP协议作为实时流协议。如果当前内部网和宽带网的带宽给定，媒体流很可能只在内部网和网络服务器到内部网的连接上得以应用(正如大多数宽带网络的上行速率比下行速率低)。
然而原则上在Share it！系统中，如MPEG-2、MPEG-4的第二部分、MPEG-4第十部分，都可以支持多个视频编解码器。我们的样品主要使用MPEG-2视频，因为它是目前DVB唯一支持的标准。很显然，基于盒式的转码比不编解码和/或更低比特率效率要高，并可以在速率受限的链路上更快地传输。我们的系统支持这一技术，但这不是我们实现的重点。
我们定义的“内容集”允许多个媒体元素作为一个文件来传送。这样的元素包括MHP Xlet、静止图像等。
4. 元数据和元数据管理
在Share it！项目中，我们已经尽可能地使用TV-Anytime作为元数据的标准。TV-Anytime的元数据形成了JXTA内容广告的集成，广告是用来发布和搜索对等网络上的内容的。同时，我们也实现了兼容TV-Anytime SP006的元数据服务器以支持Share it！机顶盒的查询及返回广播元数据。
5. 权限管理和安全性
DRM是非常复杂的领域，有很多标准小组都在研究它。Share it！的重点是设计一个合适的模型支持家庭到家庭的共享，并扩展当前广播权限模型。
至此，我们定义了两种适合不同条件的应用，即：松接触和紧接触方法。
在松接触模型中，权限协商和确认都是直接在互相信任的对等用户间进行的。一般地，对等请求方已经具有所需内容的使用权限，同时它也要满足对等服务方相应的权限要求才能获得该内容。
在紧接触模型中，权限协商包括一个受信任的第三方作权限代理角色。一般来说，对等请求方不具有所需内容的使用权限，而需要通过这个第三方代理才能达到对等服务方相应的权限要求，并获得该内容。
在系统内部，我们定义了使用和共享准则。使用准则管理每个对等用户使用内容的能力，而共享准则决定对等用户和其他对等用户分享内容的能力。这个系统的目标就是支持合理的全部内容的分布模型，包括从优质电影到家庭制作的内容。紧接触方法使复杂交织的业务模型变得重要，并提供了一个收费的途径。应用于给定内容的具体模型，将由该内容授权的用户定义。对等用户内容共享权利的管理，可能是未来内容提供商的一种新的的分销方式。
该项目样品实现了DRM协议，采用简单的XML和JXTA业务，但是原则上DRM数据可以封装到不同的权限描述语言中。
虽然我们的重点在于DRM，而不是安全性，但是我们也关注安全性和隐私问题(特别是对内容的保护和DRM方案对应攻击的鲁棒性)，而且该平台正在加进入侵分析部分。
在系统结构中，我们假设每个内部网络的Internet连接由网关保护，那么对等用户和内容传输协议必须支持网关和网络地址解析(NAT)。
构建管理权限的安全平台的一个关键问题就是信任。管理和维护值得信任的设备，是实现内容共享受限的先决条件。在典型的垂直电视平台中，平台运行商和安全技术提供商可以清晰地进行信任度管理。在水平市场上就不可能如此清晰地进行类似管理，然而可能有新办法来提供这种服务。
6. APIs
在Share it！机顶盒的实现中，定义了很多Java API，使交互应用程序员可以利用Share it！的系统功能。这些扩展的MHP栈及支持的功能包括：
●TVAnytime位置解析；
●内容访问、控制和获取；
●元数据查询(本地数据库、对等用户和TVA SP006服务器)；
●Share it！用户组访问(注意：对于应用不是暴露JXTA的完整实现，而是简化抽象的版本)；
●地址簿和用户间的消息。
六 搜索、获取内容及权限——一个示例
讨论完系统结构的几个问题之后，我们给出一个搜索、获取内容及权限的示例(如图6)。这个例子说明了从另一个对等端搜索、获取内容及权限所要采取的步骤。例中，机顶盒A的用户在搜索机顶盒B上的内容。
七 结论
该项目研究了很多关于设计和应用的问题，涉及以电视为中心、连接家庭的对等网络等比较广的范围。本文首先提出了有潜在的应用方案集，然后优化使用模型，设计并修改P2P内容共享协议、DRM协议和APIs来访问这些新功能。我们正在开发一系列基于这些使用方案的测试应用，用于评价这个新业务思想和基本技术的价值。
康佳平板电视
创维平板电视
LG平板电视
海信平板电视
WAP手机版
建议反馈
官方微博
微信扫一扫
PjTime