Windows Media Server

**AHN** · 23-07-08 22:05

Nghĩ đến Windows Media server đôi khi nghe có vẽ vượt ngoài khả năng ít ra là đối với một số bạn mới bước vào lỉnh vực IT, tuy nhiên nếu ta tiến xa hơn một bước tìm hiểu và thử nghiệm thế nào là streaming và có cần thiết phải thiết lập Windows Media server hay không và tại sao không thể stream từ web server? Và nếu có thể thì trong trường hợp nào cần thiết để thiết lập Windows Media server? Để trả lời những thắc mắc này các bạn có thể lược sơ qua vài tính chất giữa hai dạng server.

Streaming from a Windows Media server VS. Web server
Thật ra nếu chỉ để streaming một bản nhạc, một đọan phim thì Web server cũng có thể đảm nhiệm việc streaming này bằng giao thức ứng dụng trong Windows Media server là mms:// hay giao thức chuẩn RTSP:// mà không cần phải xây dựng hay thiết lập Windows Media server. Tuy nhiên, Windows Media server được thiết kế đặt biệt và chuyện dụng dành cho streaming các dạng Windows Media files trong khi các Web server thông thường không được thiết lập để hổ trợ các tính năng chuyên dụng này dành cho streaming. Nếu chúng ta quyết định dùng Web server như là cách để streaming, thì nên nhận thức các sự khác biệt sau đây có thể làm ảnh hướng đến chất lượng playback của media contents.
Phương pháp gởi dử liệu sẽ khá khác biệt giữa Web server và Windows Media server. Web server được thiết kế để gởi dử liệu cànng nhiều càng nhanh càng tốt. Đây là phương pháp tối ưu cho việc gởi các hình ảnh tĩnh và text hoặc scripts phục vụ cho việc thể hiện trang web càng nhanh càng tốt, trong khi phương pháp này sẽ hoàn toàn không phù hợp trong môi trường streaming media contents là vì đối với việc streaming, điều tối cần thiết là các dử liệu phải được gởi đi ở dạng "real time" có nghĩa là phải sống động chứ không cần nhận một lần với một số lượng dử liệu khổng lồ trong khi player không kịp giải quyết.

Với việc sử dụng Windows Media server trong việc streaming các Windows Media contents, những ưu điểm có thể nhận được đó là nó sẽ tự điều chỉnh các gói thông tin chuyển đi căn cứ trên các thông tin nó nhận ngược lại hay gọi là "Feedback information" trong quá trình gởi dử liệu tới player và căn cứ vào sự thiết lập một vài nét đặc trưng như Fast Start hay Fast Cache. Khi player nhận được các gói thông tin theo cách này, thì sự trình bày hay việc thể hiện lại các media files sẽ liên tục cũng như sẽ êm ái hơn và có thể tránh các hình ảnh bị méo và nhảy ngược. Một ưu điểm khác trong việc ứng dụng Windows Media server thay vì web server đó là sự hổ trợ nhiều users cùng truy cập một lúc trong khi vẫn giữ được độ ổn định hay hạn chế việc interuptions và vẫn có thể tiết kiệm được băng thông rất nhiều so với dùng Web server, vì sao? Chúng ta cũng đã biết băng thông luôn là ưu và khuyết điểm quan trọng quyết định trong việc cung cấp các dịch vụ trên internet.

Một khác biệt nữa trong việc sử dụng Web server và Windows Media server cho streaming là Web server không hổ trợ Multiple-bit-rate (MBR) video. Khi stream một file từ Web server, chất lượng dử liệu gởi đi hoàn toàn không được quản lý và theo dõi vì vậy nó không thể điều chỉnh bit rate cho phù hợp điều này sẽ làm ảnh hưởng đến chất lượng playback trong suốt quá trình và thời gian streaming và sẽ tạo ra những khó khăn cho các users.

Thêm vào đó Web server không sử dụng giao thức thích hợp thường dùng cho việc streaming media đó là giao thức UDP (User Datagram Protocol), vì vậy quá trình streaming sẽ phần nhiều bị gián đoạn bởi những khoảnh khắc im lặng trong lúc chờ đợi player buffer dử liệu.

Tất cả những gì vừa đề cập ở trên sẽ được biết đến như là live streaming hay multicast streaming mà Web server không hề hổ trợ.

Một lợi thế khác của Windows Media server là hổ trợ indexed Windows Media files (Indexing hổ trợ users các tính năng như fast-forwarding và rewinding những file đang streaming.
Giao thức trong Windows Media server
Sẳn đây chúng ta cũng nên sơ lược qua về các giao thức căn bản được hổ trợ bởi Windows Media server trước khi tiến hành việc thiết lập Windows Media server.
Giao thức truyền tải dử liệu là một dạng format chuẩn dùng để truyền dử liệu giữa hai thiết bị. Dạng giao thức nào được sử dụng là dùng để quyết định việc kiểm tra và xác định các giá trị thay đổi hay giá trị biến, phương pháp nén dử liệu và end-of-file acknowledgements. Nếu tất cả network được xây dựng theo một chuẩn đồng nhất cũng như tất cả các phần mềm về mạng hay thiết bị phần cứng đều đối xử tương xứng nhau thì chúng ta chỉ cần một giao thức là đủ để phục vụ việc chuyển tải dử liệu. Tuy nhiên trong thực tế, internet lại gồm hàng triệu network khác nhau chạy trên các phần cứng và phần mềm khác nhau. Từ chổ đó, khả năng streaming digital media content một cách ổn định tới clients phụ thuộc rất nhiều vào một vài giao thức chuẩn gọi là well-engineered protocols. Trong đó giao thức dùng để stream Windows Media-based content là:
HTTP - Hypertext Transfer Protocol

MMS - Microsoft Media Server, trong đó bao gồm
- MMST - Microsoft Media Server TCP
- MMSU -Microsoft Media Server UDP

RTSP - Real Time Streaming Protocol
- RTSPT - Real Time Streaming Protocol TCP
- RTSPU - Real Time Streaming Protocol UDP
Windows Media Services sẽ sử dụng các giao thức này bằng bộ điều khiển giao thức tích hợp trong Windows Media server, đó là những WMS MMS Control Protocol plug-in, WMS RTSP Control Protocol plug-in, và WMS HTTP Control Protocol plug-in.
Sẳn dịp đề cập đến các giao thức sử dụng trong Windows Media server cũng nên tìm hiểu cách truyển tải dử liệu theo Multicast Stream. Clients khi nhận media theo dạng multicast sẽ không sử dụng giao thức kết nối bình thường. Thay vào đó, các clients sẽ nhận các dử liệu media bằng cách gia nhập vào một nhóm multicast. Các thông tin cần thiết để client có thể xác định được vị trí cần gia nhập nhóm multicast nằm trong tập dử liệu thông tin ở dạng .nsc. Trước hết client sẽ mở tậm tin từ trên web server hay từ bất kì một link nào đó hay email và sau đó sử dụng tập tin chứa các thông tin cần thiết về vị trí nhóm multicast từ đây client sẽ gia nhập nhóm multicast này.
Giao thức MMS
Giao thức MMS (Windows Media Server) được phát triển bởi Microsoft cho các thế hệ củ của Windows Media Services. Bạn có thể sử dụng giao thức MMS khi truyền tải các media file theo dạng Unicast stream. Giao thức này hổ trợ các chức năng như chạy tới, trả lại, tạm ngưng, bắt đầu hoặc ngừng stream media file.
Lưu ý: Một vài ISA clients có thể gặp một số trục trặc khi kết nối tới port 1755. Để giải quyết lỗi này bạn cần tạo file gọi là Wspcfg.ini và save vào folder sau đây %systemroot%\Windows\System32\Windows Media\Server. Trong tập tin này bạn cần viết một script như sau đây
[WMServer]
LocalBindTcpPorts=1755
LocalBindUdpPorts=1755
Giao thức RTSP
Cũng như MMS, RTSP ngày nay được xem là giao thức chuẩn trong kỉ nghệ multimedia streaming, RTSP là dạng application-level protocol, giao thức này làm việc bằng cách bẻ nhỏ các gói dử liệu tùy theo tốc độ băng thông cho phép giữa client và server. Khi mà client đã nhận vừa đủ lượng dử liệu thì player sẽ giải nén, play gói dử liệu đầu rồi sau đó tiếp tục download gói dử liệu tiếp theo và tiếp tục play gói dử liệu kế tiế và cứ tiếp tục như vậy. Giao thức RTSP giờ đây đã được thế giới hóa và áp dụng trong hầu hết các ứng dụng streaming. RTSP cũng có những đặt điểm như MMS là hổ trợ các tính năng như fast-forwarding, rewinding, pause, start hay stop. Đối với một số media file không thể streaming bằng giao thức chuẩn của Microsoft Media Server chẳng hạn như các dạng digital media content như MPEG-4, MPEG hay AVI, RTSP sẽ giúp bạn giải quyết vấn đề này.
Giao thức HTTP
Ngoài 2 giao thức kể trên bạn cũng có thể stream media file bằng giao thức phổ thông HTTP, trước khi bạn streaming bằng giao thức này thì bạn cũng nên enable WMS HTTP Server Control Protocol plug-in, bộ điều khiển giao thức này sẽ bind vào cổng (port) 80.

**AHN** · 23-07-08 22:12

Các dạng streaming
Có lẽ chúng ta cũng thường hay thắc mắc? Vậy Windows Media server stream như thế nào? Cách nào sẽ hửu hiệu nhất? Thông thường có 3 phương pháp streaming căn bản là Broadcast, Unicast và Multicast, ngày nay có thêm một dạng gọi là Anycast, Anycast này tạm thời chúng ta không nói đến nhiều vì nó giống như Multicast làm việc trong môi trường IPv6.

Broadcast

Nghĩ đến broadcast có lẽ trong chúng ta không ai không một lần nghe đến trong cuộc sống hàng ngày, trong kỉ thuật phát thanh, truyền hình...v.v. Tuy nhiên từ broadcast ấy trong network có một phần khác biệt, trong thế giới mạng broadcast ta có thể hiểu rằng một thiết bị phát tán các gói dử liệu đến tất cả các host nằm trong cùng subnet của nó. Broadcast là dạng non-routable cho nên nó chỉ phù hợp trong môi trường LAN. Chúng ta thường nhận biết điều này trong mạng ngang hàng là các computer hostname thường chỉ sử dụng được trong LAN, nếu nó khác mạng với nhau thì bạn không thể truy cập bằng computer name, đó là một bất lợi của broadcast, một bất lợi khác của broadcast là tất cả các host trong cùng subnet sẽ phải sử lý các gói dử liệu do broadcast gởi đến cho dù nó thích hay không thích thú với các gói dử liệu ấy và vì vậy tỉ lệ sử dụng CPU của các host trong subnet sẽ gia tăng đáng kể cũng như từ đây nó sẽ tạo các vấn đề va chạm hay nghẽn mạch còn gọi là collision domain. Xem hình dưới đây bạn sẽ thấy broadcast không chỉ có thể họat động trong mạng LAN hoặc cùng subnet.

Unicast

Phần lớn các lượng traffic truyền tải và sử lý trên internet ngày trước cũng như hiện nay là dạng unicast. Phương pháp làm việc của unicast là client yêu cầu server sẽ cung cấp dử liệu, nếu cùng một lúc 10 client yêu cầu cùng một gói dử liệu thì server sẽ gởi ra 10 gói dử liệu giống nhau ấy đến 10 clients, điều này sẽ tạo ra các vấn đề quá tải cho server cũng như phí phạm băng thông vì trong cùng một lúc phải cung cấp một lượng lớn dử liệu giống nhau cho nhiều host khác nhau. Tuy nhiên kỉ thuật này được ứng dụng rộng rải ở phần lớn các kết nối mạng với nhau hiện nay.
Một khoảng thời gian khá dài người ta cho rằng unicast có lẽ đã đủ phục vụ thế giới internet. Tuy nhiên với đà phát triển và nhu cầu đòi hỏi chất lượng truyền phát tới client ngày càng cao cũng như phát xuất từ một nhu cầu rất cao về streaming digital media content thì những ứng dụng trên đã không còn đủ hửu hiệu để đáp ứng từ đó sẽ làm giảm chất lượng và tạo các phiền phức cho clients khi cần sử lý các dử liệu dạng real time như video conferencing, video on-demand, và các dạng multimedia khác. Từ những đòi hỏi thiết thực này người ta đã giới thiệu một dạng truyền dử liệu mới được giới thiệu vào khoảng thập niên 90' hay chính xác là vào khoảng 1993 đó là dạng Multicast.

Multicast

Từ những bất lợi của Broadcast là làm nghẽn mạch và phát tán các dử liệu tới tất cảcác hosts ngay cả những host không có nhu cầu hay Unicast sẽ tạo ra sự hoan phí băng thông vì số lượng users sẽ tỉ lệ nghịch với băng thông đường truyền, lượng users tham gia càng đông thì băng thông càng hẹp dần. Xem ra Multicast là giải pháp tốt nhất loại bỏ 2 nhược điểm trên của Broadcast và Unicast.
Phương pháp làm việc của Multicast là lợi dụng các ưu điểm của Broadcast và Unicast là chỉ phát ra những gói dử liệu một lần liên tục và tất cả những clients hay users nào có nhu cầu sẽ tham gia vào nhóm được gọi là Multcast group thông qua class D IP address là 224.0.0.0 to 239.255.255.255. Bạn hãy tưởng tượng Multicast như là một đài phát thanh hay truyền hình phát liên tục suốt ngày chỉ có những users có cùng sở thích sẽ tham gia vào nhóm này cũng như có người thích nghe nhạc nhẹ, người thích nhạc rock hay nhạc pop, từng nhóm người có cùng sở thích ấy sẽ mở chương trình phát thanh ở tầng số nhất định nào đó dành cho chương trình ấy, những ai không thích sẽ không cần phải bị làm phiền.
Lưu ý: Để có thể Multicast stream thì đòi hỏi các router phải hổ trợ IP Multicast enable, có nghĩa là router có khả năng routing các class D IP address và bạn cần một tập tin đặc biệt bao gồm các thông tin về multicast dưới dạng .nsc sẽ nói ở phần sau. Xem hình dưới đây cách so sánh giữa Unicast Vs. Multicast để thấy ưu điểm của Multicast

Thật ra để có thể thiết lập một Windows Media server, quản trị và phát huy hết các tính năng của nó có lẽ chúng ta sẽ tốn nhiều thơi gian và đào sâu kiến thức về các giao thức cũng như cấu trúc của nó. Tuy nhiên trong bài này chúng ta chỉ sơ lược một vài khái niệm căn bản và một vài tính năng của Windows Media server hầu có thể bước đầu xây dựng một Windows Media server cơ bản. Sau khi thiết lập thành công phần còn lại là sự tìm hiểu cũng mỗi người hầu phát triển kiến thức cũng như kinh nghiệm của mình đối với lỉnh vực streaming media.

Publishing Points

Trước khi bắt tay setup Windows Media server, bạn cũng cần hiểu "Publishing Point" là gì. Publishing points chỉ là điểm cung cấp dịch vụ streaming từ server đến clients cũng như nơi chứa các media files, vì điều đó bạn có thể tao bất kì publishing point nào tới bất kì folder hoặc drive nào trong computer của bạn. Windows Media server có hai dạng publishing points, On-demand (Unicast) và Broadcast, nói chung cả 2 rất giống nhau về rất nhiều mặc. Tuy nhiên nếu bạn muốn cho phép clients được quyền điều khiển chế độ playback theo ý muốn như chạy tới, trả lại, tạm dừng, ngừng hay bắt đầu thì bạn nên thiết lập "On-demand". Đối với broadcast thì client không thể điều khiển playback mà chỉ có thể điều khiển các tính năng này tại server, vì sao? Bạn hãy tưởng tượng broadcast như một chương trình truyền hình đang phát sóng...
Live stream từ Encoder (Vd: radio, webcam, tivi, hay máy quay phim)
Playlist (Một tổng hợp gồm nhiều media files)
Một file, thường dùng cho broadcast
Digital media file, chẳng hạn như một bản nhạc, một đoạn phim (Sử dụng với On-Demand publishing points)

Chủ đề: Windows Media Server

Công cụ bài viết

Hiển thị

Windows Media Server

Thông tin chủ đề

Users Browsing this Thread

Quyền viết bài