10
Sep

试用WMS in Longhorn Server

分类: 技术分享   |  共有: 12,687 次浏览 , 暂无评论

 今天抽时间,仔细看了一下有关Longhorn Server 里面所包含的WMS,写了下面这些内容,希望给大家带来帮助.

 Stand版本和EnterPrise版本相比,相差了下面的服务内容:

  • Advanced Fast Start,
  • Advanced FF/RW,
  • Cache/proxy server support,
  • Custom plug-in support,
  • Event-based scripting support,
  • Fast Recovery,
  • Internet authentication method,
  • Internet Group Management Protocol version 3 support,
  • Multicast content delivery,
  • Play While Archiving,

 其实上面这些没有什么好看的,当时Windows 2003 std和Ent 的WMS相差的也是这些区别而已,在这里只是老调重提一下而已,以免有些不清楚的同学不知道.

 从上往下慢慢看,略过一些常见的内容,首先我所注意到的就是,微软在这次的介绍中,彻底把mms的协议介绍给删除了,记得在当时发布WMP11的时候,我就专门就MMS / MMST/ MMSU的协议取舍发表过一篇文章。让我们来回忆一下当时对mms协议的介绍:“The Microsoft Media Server (MMS) protocol is a proprietary streaming media protocol developed by Microsoft for earlier versions of Windows Media Services. ”现在看来,是被彻底放弃掉了。同样的,在后面的协议翻转章节我们看到了下面的话语:

Earlier players
When an earlier version of the Player, such as Windows Media Player for Windows XP, attempts to connect to the server using a URL with an mms:// prefix, the server automatically attempts to connect using the HTTP protocol, if the WMS HTTP Server Control Protocol plug-in is enabled.

 但是,我们在有关协议概述的时候,看到下面的话语:

To facilitate protocol rollover it is recommended that the URL use the generalized MMS moniker in the connection URL (for example, mms://server/publishing_point/file). That way, the Player negotiate the best protocol to use (either the RTSP or HTTP) to connect to the stream.

 这么看来MMS已经彻底沦为一个绰号了,目的就是为了让WMS服务器知道,“Hello~ 这是自己人,你看着办吧~”然后服务器可以自动分配一个最合适的连接协议给播放器,如何这样说的话,我们以后书写WMS 的链接的时候,还是尽量用MMS开头吧,虽然你也可以直接写成RTSP,都OK的~

 文档在“Sourcing from playlists, files, and encoders”这部分作了比较大的扩展,更好的说明了如何制作服务端播放列表。因为这个特性也是WMS一个不错的功能。

 在配置介绍中,我们看到了我们所期待的那部分新增章节,就是有关Cache / Proxy Setting的部分。
General:设置总体的Plug-in的状态,以及所采用的协议,可选的协议有4种,分别是(Client Protocol,HTTP,RTSPU,RTSPT)

 Cache:设置Cache的具体状态,以及一些相关设置,这些设置包括:

  • cache的存储配额大小
  • 每个流媒体文件的cache配额
  • 是否激活Freshness Chech,直接翻译新鲜度检测,意思也就是说,cache服务器当用户发起请求的时候,将会自动到源服务器上面进行数据对比,如何和本地的文件一致,则直接从本地分发数据,而不是从远程重新请求数据。当然在这里我们就必须考虑到一个有效期的问题,cac he服务器不可能保存所有的访问记录,包括前面我们也看到了cache配额限制,现在我没有找到的就是这个配额限制中的删除策略,因为暂时还无法评估说哪个文件将会被系统最先清除掉,初步判定是根据活动程度来决定的,系统将会首先清除长时间不被请求的文件 内容。
  • 是否激活播放存档功能,这个功能允许用户在发请求到服务器A,然同通过服务器A向服务器B请求数据的同时,服务器A将一并进行存档
  • cache的本地路径
  • cache的速度 – 可以选择用尽可能最快的速度,以及恒定的速率
  • cache现在的使用情况,包括清空cache

 Proxy:这里有三个选项,是描述当前WMS服务器的工作状态的

  • Proxy,标准Proxy,这里所所的Proxy服务是针对服务器而言的,而对于用户来说,这就是一台普通的服务器而已
  • Proxy Redirect,重指向Proxy,这种工作状态下,服务器将转交所有用户请求到其他服务器上,你可以在Alternate Proxy里面输入其它Proxy服务器的地址,这种情况一般用于大规模的负载均衡操作,如果你已经cache了内容,那么你可以直接分发给用户,如果你没有存储内容,那么就把用户指向到最新的proxy服务器上。
  • Reverse Proxy,反向Proxy,将用户请求直接指向到实际的请求服务器,你可以在Content Server里面输入实际的服务器名和发布点

 Prestuff:这个特性使专门针对服务器之间内容调度使用的,在前面的设置中,cache的操作仅仅发生在用户进行数据请求的时候,而Prestuff的设置是用于两个服务器知间的后台内容传输,即便没有用户请求,也会发生。

 Query:在这里你可以查询到被cache的文件内容,这些文件会被以乱码的方式保存在cache目录中,但是你可以在这里找到他们的真实面目

 大概的WMS中更新就只有这么多了,后面还有部分有关怎么部署服务的章节也都是老调重弹,没有什么好讨论的,对比起和2003的进步,不能说太令人吃惊。另外,关于cache的那个测试,我最终还没有时间去具体调试,因为现在都是在我的虚拟机上面测试的, 所以还有一些测试还没有实际成功。应该会在将来的某些时候专门写一篇有关cache和proxy的应用的文章。

 希望这篇文章能给你带来有关Windows Media Service in Longhorn 的最新资讯




在下方发表关于本文的评论...