试用WMS in Longhorn Server

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

　今天抽时间，仔细看了一下有关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 的最新资讯

---