[觀念]由 Peer to Peer 觀念來看視訊會議系統

這一篇文章說明如何透過Peer to Peer來傳送視訊...
應該是蠻有幫助的。

先前說到 Peer to Peer 的連線方式
當 Peer To Peer 完成連線之後
我們來探討由 PC Cam 所取得的影像資料, 如何來實作網路視訊會議系統

A Win ClientSocket --------------------- B Win ServerSocket
A Win ServerSocket --------------------- B Win ClientSocket

話說由 PC Cam 擷取資料這個元件, 由於涉及技術面
所以原 VCL 設計者要求付費來購買此元件, 所以我花了些許美金購得此元件
在由 USB PC Cam 抓取資料後, 通常會給你的是單一點陣圖檔 BMP 格式
而大家都知道 BMP 格式動不動就要 20KBytes 以上, 這樣的速率在網路上
尤其是對撥接用戶 56K 若每五到六秒才一格畫面 甚至是十秒.. 一定非常的難受
所以在抓取到 BMP 格式的影像後, 我們透過了壓縮, 或是轉換成 JPEG 的方式來達成
我發現, 當轉換到 JPEG 後.. 影像檔可以縮小為 2~3K Bytes .. 這是多麼大的差距
2~3K Bytes 56K Modem 就可以在一秒內送出及接收
ok .. 解決了圖檔的大小 size 問題了 .. 大家不僅心中還有許多疑問
因為箇中道理繁雜, 待小弟往後再慢慢為各位回答, 今天只勾起大家的觀念, 設計潛力為
主軸, ok .. 我們往下講

而然 A Win 及 B Win 的程式上各有一個可以支援 JPEG 秀圖的 Image 元件
當任何一端的 ServerSocket 收到資料 .. 再完成檢查工作
(所謂的檢查工作就是檢查 JPEG 的檔頭及檔尾, 確定是一份完整 JPEG 圖檔)
就可以把所接收的資料不管是存在 File 也好 .. 存成 Stream 也好
秀在 Image 元件中 .. 你可以使用 Image 的函式 LoadToFile 或 LoadToStream
都可以完成秀圖 ...
然後再送出一個確認字串, 由 ClientSocket 傳送給遠端
讓另一端知道你確認收到了他的影像
為什麼要這樣做呢 ? 何不就一直接收對方的影像就好
還得送出確認封包 ?? 這是什麼道理 ??
呵呵 ... 我們大家都知道, 網路連線的環境 .. 不是非常通達的 ..
今天一值狂丟資料到對方 Socket ... 難免會有 Buffer 溢滿的情況發生
導致資料不完整或是 lost ... 而且每個 Client 連線環境都不一樣
有人使用 56K 撥接, 更有 33.6K Modem .. 及一些 ADSL 用戶, 甚至有網咖連上來的專線
使用者 ... 企業固網等等 ....
那麼你怎麼知道要抓取什麼樣的 Timer 傳送目前影像呢 ?
抓取影像的時機為何 ?
答案很簡單 .. 就是當收到對方確認封包後 !!!!
呵呵 ~~ A Win 今天抓了一個即時影像給 B Win (可能過了一秒甚至更快)
A Win 這時就等待 B Win 的命令, 抓取下一個即時影像, 所以 A Win ← 等待
而當 B Win 收到了 A Win 的影像.. 確認已經丟到了 Image 讓使用者看到對方後
即傳送確認封包給 A Win, 請 A Win 再送影像(可能過了一秒甚至更快)
而當 A Win 收到 B Win 確認的封包 (真好, B Win 已經收到囉)
就立即再抓取 PC Cam 的影像資料傳送給 B Win ... 然後 A Win ← 又等待
而當 B Win 收到了 A Win 的影像.. 確認已經丟到了 Image 讓使用者看到對方後
即傳送確認封包給 A Win, 請 A Win 再送影像(可能過了一秒甚至更快)
而當 A Win 收到 B Win 確認的封包 (真好, B Win 已經收到囉)
就立即再抓取 PC Cam 的影像資料傳送給 B Win ... 然後 A Win ← 又等待

如此 ..... 是不是就完成了整個連線, 而且連抓資料的時機都有了
不怕網路塞車所照成的 Buffer 溢滿問題
不管如何, 也都能夠確定對方收到與否 ...
這時一定有人想 .. 那若真的某個影像 B Win 沒接收到, 而 A Win 又再等待 B Win
回應的話怎麼辦 ?
所以我們要設一個 Time Out 值囉 .. 再 B Win 15 秒內若都沒收到 A Win 的影像
就是 Time Out ... 所以就再傳送一個確認封包給 A Win
A Win ← 本身不用理會是不是 Time Out .. 反正收到確認封包就再丟一個目前影像
如此也就解決了久久收不到影像的問題了
不過據本人實務經驗, Time Out 會發生的可能性超小
因為大家要知道 TCP/IP 會追蹤封包狀態, 若是有些錯誤 WinSock 都會再幕後重送封包
這部分就交給 WinSock 處理吧 ..
除非您使用的是 UDP 所謂送後不理的通訊協定
否則一般 TCP/IP 接收不到導致 Time Out 的機率視微乎其微

參考資料：
<socket> 由 Peer to Peer 觀念來看視訊會議系統