2.3.1. Những nhƣợc điểm của mạng IP với dịch vụ cố gắng tối đa (best effort)
Giao thức tầng mạng IP cung cấp dịch vụ cố gắng tối đa. Có nghĩa mạng sẽ cô gắng tối đa để chuyển mỗi datagram từ nguồn tới đích, không phân biệt các gói tin với nhau. Tuy nhiên, dịch vụ cố gắng tối đa không đảm bảo độ trễ của gói tin, cũng như là jitter và sự mất mát gói tin trong luồng gói tin. Trong khi đó các ứng dung mạng đa phương tiện tương tác thời gian thực như: điện thoại Internet, video conferencing thời gian thực lại rât nhạy cảm với độ trễ, jitter và sự mất gói tin. Thật may mắn, những người thiết kế ứng dụng đã đưa ra các cơ chế làm tăng chât lượng của dịch vụ audio/video . Chúng ta sẽ tìm hiểu những cơ chế này ở phần tiếp theo.
2.3.2. Sử dụng giao thức UDP ở tầng giao vận
Các ứng dụng mạng đa phương tiện đều sử dụng giao thức UDP ở tầng giao vận để đóng gói các dữ liệu đa phương tiện như audio/video. Như chúng ta
51 đều biết, tầng giao vận trong mô hình mạng 7 tầng OSI có 2 giao thức giao vận chính là UDP và TCP. UDP là giao thức không hướng kết nối, không tin cậy, là giao thức giao vận hết sức đơn giản. UDP chỉ cung cấp dịch vụ dồn kênh/phân kênh và phát hiện lỗi đơn giản. Các cơ chế truyền tin cậy đều do các dịch vụ ở tầng trên xử lý. Ngược lại với UDP, TCP là giao thức giao vận hướng kết nối và truyền dữ liệu tin cậy. Để truyền gói tin, TCP phải có giai đoạn thiết lập kết nối. TCP có cơ chế truyền lại khi gói tin bị mất, cơ chế kiểm soát tắc nghẽn (hạn chế tốc độ bên gửi khi xảy ra tắc nghẽn mạng). Chính vì có các cơ chế này mà TCP sẽ làm tăng thời gian trễ của gói tin, làm tăng jitter trong luồng gói tin. Đây là điều không thể chấp nhận được đối với các ứng dụng mạng thời gian thực như video conference, điện thoại Internet. Mặt khác TCP không hỗ trợ truyền multicast trong khi UDP thì có. Đây là điều rất quan trọng vì nhiều ứng dụng mạng đa phương tiện như video conference có thể có nhiều bên tham gia và có thể cần có cơ chế truyền multicast.
2.3.3. Cơ chế loại bỏ jitter ở phía nhận
Xét một ứng dụng mạng đa phương tiện tương tác thời gian thực, chẳng hạn điện thoại Internet. Người nói chuyện trong điện thoại internet tạo ra một tín hiệu audio gồm lúc nói lúc ngừng. Để đảm bảo băng thông, ứng dụng sẽ chỉ tạo ra gói tin trong thời gian nói. Trong thời gian nói, người gửi tạo ra những byte với tốc độ là 8KBps, cứ 20 ms người gửi nhóm các byte vào thành một đoạn. Số lượng byte trong một đoạn là 20ms*8KB/s = 160B. Một hearder đặc biệt được thêm vào mỗi đoạn. Mỗi đoạn cùng với header được đóng gói trong một UDP segment, rồi được gửi tới giao diện socket. Trong thời gian nói, cứ 20ms có một UDP segment được gửi.
Nếu mỗi gói tin (packet) tới được phía nhận (không xảy ra mất mát gói tin), và có độ trễ không đổi, các packet sẽ tới phía nhận một cách định kỳ 20ms, trong thời gian nói. Trong điều kiện này, phía nhận có thể nghe mỗi đoạn ngay khi tới. Nhưng không may mắn là vài packet có thể bị mất và hầu hết các packet không có độ trễ không đổi (thậm chí là ngay cả khi không có tắc nghẽn trên Internet) tức là jitter mạng. Nếu chạy ngay những gói tin ngay khi nó
52 tới phía nhận thì chất lượng audio thu được sẽ rất tồi. Vì vậy, phía nhận phải có các cơ chế để loại bỏ jitter tại phía nhận: phía nhận cố gắng cung cấp khả năng chạy đồng bộ các đoạn (chunk) khi có jitter. Điều này có thể được thực hiện bằng cách kết hợp các cơ chế:
• Chèn một số tuần tự (sequence number) vào mỗi đoạn, phía gửi sẽ tăng số tuần tự lên 1 khi có một gói tin được tạo ra;
• Sử dụng một nhãn (timestamp) cho mỗi đoạn, phía gửi sẽ gán nhãn cho mỗi đoạn chính là thời điểm mà đoạn đó được tạo ra;
• Làm trễ việc chơi (play) ở phía nhận. Thời gian làm trễ phải đủ lâu để các gói tin phải được nhận trước khi tới lượt (thứ tự) chúng được lập lịch chạy. Việc làm trễ có thể theo khoảng thời gian cố định hoặc thay đổi. Các gói tin không tới được phía nhận trước thứ tự chạy của chúng được xem như là bị mất.
Có hai phương pháp làm trễ việc chơi ở phía nhận.
2.3.3.1. Làm trễ việc chơi với thời gian cố định (fixed playout delay)
Phía nhận cố gắng thực hiện chạy mỗi đoạn đúng q ms sau khi đoạn đó được tạo ra. Nếu timestamp của một đoạn là t, phía nhận sẽ chạy đoạn đó tại thời điểm t + q (giả sử đoạn tới phía nhận trước thời điểm theo thứ tự nó được chạy), nếu nó tới sau thời điểm đó, nó bị coi như đã mất.
Chú ý rằng, số tuần tự là không cần cho chiến thuật này. Chúng ta quan tâm tới giá trị q. Đâu là sự lựa chọn tốt với q. Nếu q nhỏ hơn nhiều so với 400 ms, rất nhiều gói tin có thể bị coi như là bị mất do jitter. Nếu độ trễ end-to- end lớn thì dùng q lớn, nếu độ trễ nhỏ và sự biến thiên độ trễ là nhỏ thì dùng q nhỏ chẳng hạn < 150 ms. Hình dưới đây minh họa mối quan hệ giữa thời gian làm trễ và sự mất mát gói tin (gói tin coi là mất khi nó tới phía nhận sau thời điểm được
53 chạy theo lịch).
Hình 2.12: Sự phụ thuộc giữa tỉ lệ mất gói tin với thời gian làm trễ việc chạy q.
Hình vẽ thể hiện thời gian mà tại đó gói tin được tạo và được chạy. Hai lựa chọn khác nhau về thời gian tạm dừng được xét. Phía gửi tạo gói tin cứ 20 ms một lần. gói tin đầu tiên tới phía nhận tại thời điểm r. Theo chiến lược tạm ngưng đầu tiên, thời gian tạm ngưng là p –r, gói tin thứ 4 không tới phía nhận trước thời gian được lập lịch nên bị coi là mất. trong khi đó ở chiến lược tạm ngưng thứ 2, thời gian tạm ngưng là p’-r, toàn bộ các gói tin đều tới phía nhận trước thời gian lập lịch và coi như không có sự mất gói tin.
2.3.3.2. Làm trễ thời gian thích nghi (adaptive playout delay)
Với chiến lược làm trễ việc thích nghi thời gian cố định, nếu thiết lập thời gian tạm ngưng lớn, các gói tin hầu như sẽ tới phía nhận trước thời gian chạy
54 trong lịch nên không có mất mát gói tin. Tuy nhiên, với các ứng dụng tương tác thời gian thực như điện thoại internet, độ trễ lớn quá có thể khiến chất lượng không chấp nhận được. Vậy ta phải giảm thời gian tạm ngưng tới giá trị cực tiểu với ràng buộc là sự mất mát gói tin chỉ là vài phần trăm mà thôi. Một cách rất tự nhiên để giải quyết vấn đề này là đánh giá độ trễ mạng và sự biến thiên độ trễ (jitter), theo đó điều chỉnh thời gian làm trễ tại lúc bắt đầu mỗi cuộc hội thoại. Chúng ta sẽ mô tả thuật toán mà phía nhận thay đổi thời gian làm trễ (playout delay)
Gọi ti là timestamp (thời điểm gói tin được tạo ra tại phía gửi) của gói tin thứ i, ri là thời điểm gói tin thứ i tới phía nhận, pi là thời điểm gói tin thứ i được chơi ở phía nhận. Khi đó, độ trễ end-to-end của gói tin thứ i là ri – ti. Tùy theo jitter, độ trễ này thay đổi khác nhau đối với mỗi gói tin. Gọi di là độ trễ trung bình cho tới gói tin thứ i. Ta có di = (1-u) di-1 + u (ri - ti) với u là hằng số nào đó (ví dụ u = 0.1).
Gọi vi là độ lệch trung bình cho tới gói tin thứ i giữa độ trễ của gói tin thứ i và
độ trễ trung bình di.
vi = (1-u) vi-1 + u | ri - ti - di |
Các giá trị di, vi được tính cho mỗi gói tin nhận được tại phía nhận, để từ đó tính thời điểm chơi cho gói tin đầu tiên của mỗi đoạn thoại.
Sau khi tính các giá trị trên, giả sử gói tin thứ i là gói tin đầu tiên của đoạn thoại nào đó, thời điểm chơi của nó tại phía nhận sẽ là pi = ti + di + Kvi, trong đó K là hằng số dương (ví dụ K = 4). Kvi được thêm vào để cho thời điểm chơi gói tin đủ lâu để các gói tin bị coi như bị mất là rất ít. Thời điểm chơi của các gói tin tiếp theo trong cùng đoạn thoại với gói tin đầu tiên sẽ là pj = tj + qi với qi = pi -ti , là thời gian từ khi gói tin đầu tiên được tạo ra (bên gửi) cho tới khi nó được chạy (bên nhận). Trong thuật toán trên điều quan trọng là phải xác định đâu
55 là đoạn đầu tiên của đoạn thoại. Nếu không có sự mất gói tin, phía nhận có thể xác định được điều này bằng cách so sánh timestamp của gói tin thứ i với timestamp của gói tin thứ i-1. Nếu, ti - ti-1 > 20ms, thì phía nhận sẽ biết rằng gói tin thứ i là gói tin đầu tiên của đoạn hội thoại. Nhưng khi việc mất gói tin xảy ra, thì khi ti - ti-1 > 20ms chưa chắc i đã là gói tin đầu tiên của đoạn thoại. Trong trường hợp này, 2 gói tin nhận được cũng có hiệu 2 timestamp >
20ms. Vì thế, số tuần tự trong trường hợp này được sử dụng. Phía nhận có thể dùng số tuần tự để xác định trường hợp nào là gói tin đầu tiên, trường hợp nào là mất mát gói tin.
2.3.4. Khôi phục các gói tin bị mất tại phía nhận
Như đã nói ở phần trên chúng ta quan niệm rằng: gói tin bị coi là mất nếu nó không tới phía nhận hoặc tới sau thời gian mà nó được thực hiện tại phía nhận (theo lịch). Việc truyền lại gói tin bị mất là không phù hợp với ứng dụng thời gian thực. Vì thế ta sử dụng lược đồ khôi phục gói tin bị mất tại phía nhận. Có 2 kiều lược đồ là : FEC (forward error correction) và xen kẽ (interleaving).
2.3.4.1. FEC
Ý tưởng của FEC là thêm các thông tin bổ sung vào gói tin ban đầu. các thông tin này có thể được dùng để khôi phục các gói tin bị mất. Chúng ta xét 2 cơ chế FEC.
• Cơ chế thứ nhất: gửi một đoạn chứa thông tin bổ sung sau n đoạn. Đoạn chứa thông tin bổ sung đó được tạo bằng cách thực hiện phép XOR n đoạn ban đầu. Nếu một gói tin nào đó trong n + 1 gói tin bị mất, phía nhận có thể khôi phục lại gói tin đó. Nhưng nếu có nhiều gói tin bị mất, phía nhận sẽ không thể tái tạo lại được. Nếu để cỡ của khối là (n + 1) nhỏ, một phần lớn của các gói tin bị mất có thể được khôi phục. Lược đồ này cũng làm tăng độ trễ bởi vì phía nhận phải nhận toàn bộ khối gói tin xong mới có thể thực hiện chúng được.
• Cơ chế FEC thứ hai là gửi một luồng thông tin bổ sung chính là luồng âm thanh ban đầu có chất lượng thấp hơn. Chẳng hạn, phía gửi tạo một luồng bình thường và một luồng tốc độ bit thấp (ví dụ: luồng bình thường là mã hóa PCM tại tốc độ 64Kbps, luồng tốc độ bit thấp là mã hóa GSM tại tốc độ 13
56 Kbps. Luồng tốc độ bit thấp được xem như là thông tin bổ xung. Phía gửi sẽ tạo ra gói tin thứ n bằng cách lấy đoạn thứ n của luồng bình thường chèn vào đó và đoạn thứ n-1 của luồng bổ xung như hình vẽ. Khi có sự mất gói tin không liên tục, phía nhận có thể chạy đoạn mã hóa tốc độ bit thấp trong gói tin kế tiếp. Đoạn tốc độ bit thấp cho chất lượng âm thanh thấp hơn đoạn bình thường, nhưng trên tổng thể thì ảnh hưởng không đáng kể. Trong lược đồ này, phía nhận chỉ phải nhận 2 gói tin trước khi thực hiện chạy chúng, vì thế độ trễ là nhỏ. Nếu mã hóa tốc độ bit thấp chiếm tỉ lệ kích thước không đáng kể so với mã hóa bình thường, tốc độ truyền tăng lên không đáng kể.
Hình 2.13: Chèn thêm thông tin bổ xung là các gói tin tốc độ bit thấp vào gói tin bình thường.
Để xử lý với sự mất gói tin liên tục, một biến thể của cơ chế trên được sử dụng. Thay vì chèn đoạn tốc độ bit thấp thứ n -1 vào đoạn bình thường thứ n, phía gửi sẽ chèn đoạn tốc độ bit thấp thứ n-1 và n-2 , hoặc chèn đoạn tốc độ bít thấp thứ n-1 và thứ n-3. Việc chèn càng nhiều đoạn bổ xung vào thì càng làm tăng băng thông và độ trễ.
2.3.4.2. Cơ chế xen kẽ (interleaving)
Phía gửi sẽ xếp các dữ liệu âm thanh trước khi truyền, các phần tử sát nhau sẽ được xếp cách nhau một khoảng nào đó trong luồng truyền đi. Điều này sẽ làm giảm ảnh hưởng của việc mất gói tin. Ví dụ: mỗi phần tử dài 5 ms,
57 một đoạn dài 20 ms ( chứa 4 phần tử). Đoạn đầu tiên chứa các phần tử thứ: 1,5,9,13. đoạn thứ 2 chứa phần tử thứ: 2,6,10,14 …. Việc mất gói tin sẽ chỉ làm cho mỗi đoạn nhận được sau khi được khôi phục lại giảm chất lượng đi chút ít.
Hình 2.14: Cơ chế khôi phục gói tin bị mất theo kiểu xen kẽ. Cơ chế trên có thể nâng cao chất lượng luồng nhận được. Bất lợi dễ thấy là tăng độ trễ. Đây là hạn chế với các ứng dụng tương tác thời gian thực như điện thoại Internet, mặc dầu không ảnh hưởng lắm tới ứng dụng truyền âm thanh được lưu trữ trên server. Thuận lợi là không làm tăng yêu cầu băng thông.
2.3.4.3. Cơ chế khôi phục gói tin bị mất chỉ dựa trên phía nhận (receiver- based) based)
Lược đồ khôi phục gói tin bị mất kiểu này sẽ cố gắng tạo ra một gói tin thay thế cho gói tin bị mất làm sao cho gói tin thay thế sẽ thật giống gói tin bị mất nếu có thể. Kĩ thuật này tương đối hiệu quả khi tỉ lệ mất gói tin là nhỏ (< 15%) và kích thước gói tin nhỏ (ví dụ chỉ chứa dữ liệu mã hoá 4-40 ms âm thanh).
• Dạng đơn giản nhất của lược đồ này là lặp lại gói tin. Khi một gói tin bị mất, phía nhận sẽ tạo ra một bản sao của gói tin nhận được ngay trước gói tin bị mất để thay thế cho gói tin bị mất. Điều này có ưu điểm là yêu cầu khả năng tính toán thấp tại phía nhận.
58 • Dạng thứ hai của lược đồ này là sử dụng phép nội suy. Khi một gói tin bị mất, phía nhận sẽ sử dụng gói tin tới trước và sau gói tin bị mất để nội suy ra một gói tin mới thay thế cho gói tin bị mất. Dạng này cho chất lượng tốt hơn dạng thứ nhất nhưng yêu cầu khả năng tính toán tại phía nhận cao hơn.
59
CHƢƠNG III: XÂY DỰNG ỨNG DỤNG 3.1. Phân tích thiết kế chƣơng trình
3.1.1 Giới thiệu bài toán
Xã hội ngày càng phát triển, nhu cầu học tập của nhân dân ngày càng lớn, hệ thống trường lớp tuy đã được đầu tư phát triển vượt bậc cả về số lượng và chất lượng song cũng không thể đáp ứng được nhu cầu học tập đa dạng của người học. Từ định hướng trên, Ngành GD&ĐT đã xây dựng chiến lược phát triển giáo dục đến năm 2010, trong đó nhấn mạnh "Phát triển giáo dục không chính quy như là một hình thức huy động tiềm năng của cộng đồng, để xây dựng xã hội học tập, tạo cơ hội cho mọi người ở mọi trình độ, mọi lứa tuổi, mọi nơi có thể học tập suốt đời, phù hợp với hoàn cảnh và điều kiện của mỗi cá nhân, góp phần nâng cao dân trí và
chất lượng nguồn nhân lực". Dạy học trực tuyến là một trong những phương thức
đào tạo góp phần thực hiện mục tiêu trên.Có nhiều đổi mới và tiến bộ so với các hình thức học truyền thống, học trực tuyến hứa hẹn cung cấp cho học viên sự kết hợp hoàn hảo của Nghe, Nhìn và Sự chủ động. Dạy học trực tuyến giúp cho việc đào tạo hiệu quả tới được nhiều đối tượng học viên khác nhau, cắt giảm được chi