自從上次的final presentation後, 就苦惱於detail tuning
因為是三組螢幕也就是六部電腦，外加一部主控電腦
寫起來跟寫on-line game是差不多的架構，這個算小事情
反正這類架構要tune，要不就是砸硬體，要不就是做distributed server-side
CAVE就麻煩在..同一組螢幕的兩部電腦必須是critical-synchronized..
同步需求遠比on-line game中的兩個client node大得多
工研院的東西根本沒做到time-critical程度的互動，當然沒這問題，灌封包再去比對heartbeat就解決
再看到彥良弄的director+multiuser server的lag狀況也知道那不是個好的solution
但是要做interaction，效率是很重要的
然而一來我不可能砸硬體..二來我也沒有多餘的computing power....
就是這七部....那到底怎樣的topology適合這樣的架構?
目前採用的client-server架構就會出現的同組螢幕的同步不佳的問題
畫面在同步訊號來的時候會閃動
這跟director+multiuser server是一樣的狀況
這也表示這樣的架構較適合大型的架構來用(cross-domain, massive multi-user)
即便我把架構倒過來用，讓server灌封包，client都乖乖閉嘴，希望提高效能
但是server要管數個input thread外加七個socket thread(6 client+1 server)....太累了
更何況這台server運算效能跟client幾乎沒什麼差
而在之前寫的調整focal length的程式是採用peer-to-peer的架構
同步相當迅速，幾乎看不出來閃動的情況（當然這也有可能是OpenGL比Flash繪圖效率高的原因）
但這樣的話，server還是得管input thread外加數個peer thread....loading並沒比較輕
broadcast呢?別提了，上次用UDP就已經碰到要開個檔有人忘了開就知道所謂的unreliable有多麼不可靠了
TCP跟UDP混用?像線上廣播或是ShoutCAST那種
不好，架構變複雜，未來作extension頗麻煩，而且data走的是UDP....-____-|||
multicast的話不像broadcast那麼不可靠又可以做一對多點的廣播
很值得考慮，但是沒有實測過不知道有多讚，需要多找一些資料，而且系統要換的話要重新規劃
目前想用的是hybrid的型態，server跟client間用client-server topology，client跟client間跑peer-to-peer
好處..server的client thread少掉一半，而讓擔任peer host的client分擔一部份的工作，運算資源分配比較均勻
而且同步訊號會比較準確也比較快，client-client的同步當然比client-server-client快
壞處..省掉的thread computing是否可以賺回來？如果賺不回來就變成做白工了..還不如花時間去tune現在的架構就好
網路程式有夠複雜....真是....好玩啊....f-_-
(我大概是變態吧...T-T)
再提醒自己一下別玩物喪志，現在想的東西已經都太偏CS囉，千萬別lost focus
重點要放在
.: multi-modal interaction
.: more media supported (powerpoint, quicktimeVR, image, mpeg, opengl, ....more)
.: more input device supported (bluetooth mobile device, IrDA sensor, notebook, pda, gesture, ....more)
Fire! CAVE as Crit-Space!
(嗯....燒掉就沒了說....)
No comments:
Post a Comment