主題: 設計一個雙向溝通即時知道對方狀態的伺服器

[FIEND]

下午想了又想....想了又想....

先畫了這張圖...

我的需求是建立一個 雙向溝通的 即時知道對方狀態的伺服器

我先把想法畫成一張圖.....





1 會走向 2 也會走向 3 如果往 3 走上去 會走向 4 跟 5 .

如果停在 5 上面 則 5 跟 6 會不停的去讀取 Vector OR MAP 的內容 , 判斷要發送 TCP 給那些人.

如果都處理完了 6 就會走回 4 再走回 1,2,3,4 那二圈.

讓 5,6 會因為 使用者共同組織了一個組織 在裡頭時才會不停的把 TCP 送給 5,6 迴路的人.

讓 5,6 迴路的人可以互相即時知道對方的動態........

提供參考....


有什麼好的建議~~請多多建議~~謝謝~~

PS : 就是不想用 UDP 封包 做才想破頭... >_<" 別建議我用 UDP 做...

[netman]

icmp呢？

[FIEND]

icmp呢？

呼~不用 UDP~~

我也想偷懶~~為了這件事還和下屬吵了一架~~最後我輸了~>_<" 還是用 TCP ....

[FIEND]

有沒有 網路 專家 幫忙給點建議的......

這是我自己想出來的流程....

不採用 UDP ... 因為這些資訊很重要不能掉封包.

需要 SYN 的 ARC 來確保 資料正確性.

[FIEND]

有沒有 網路 專家 幫忙給點建議的......

這是我自己想出來的流程....

不採用 UDP ... 因為這些資訊很重要不能掉封包.

需要 SYN 的 ARC 來確保 資料正確性.

昨天實驗了一下

5,6 群組的楖念~會造成~3 , 4  被影響 .

如果想要 5,6 / 3,4 都有在做

而且 3,4 是一個由 CLIENT 個人發動個人讀取的 開關.

5,6 則是共享在一個 群組 讀取 3,4 的行為來決定要發動給這群組相關的人.

解法我能想到的只有二種~~

FORK 取用 共用 記憶體. SHM ( LINUX KERNEL 層的一個技巧 )

THREAD 共用資源 開 THREAD 出來跑~~

後來我選用 THREAD , 這樣可移值性會高一點~

[FIEND]

昨天終於把這個功能測完了.

後來還是維持 這個架構沒用 FORK 和 THREAD .

讓迴路保持通暢 , 中間放了 PROCESS 在 餵訊息給 5,6 迴路做迴路開關.

效能比預期的好很多.

我本來還擔心效能會降低.

這個迴路可以應用在 :

1. 即時多人 對戰系統
2. 即時多人 聊天系統
3. 即時多人 分享 ( 非 P2P )

伺服端負責幫 群組內的 使用者做溝通 .

實際上可以多少人在一個群組內 , 還要測試寫程式 實驗.

有更好做法的前輩 , 請給在下一點建議...

因為我也只能想出這個笨方法.

[FIEND]

我放假時 , 放空了二天 ,

今天一大早~就想起 , 以前層經看過一個開放原碼的範例 , 突然靈機一閃...

馬上狂改程式 .......... 拼命寫程式 %$@#%#%Q#QWR%@#%#.

測試看看 :




XD 可以咧 , 更簡單有力!!!!

要什麼THREAD , 還要去控制它的迴路生命週期....

寫錯了可會造成災難~~


我實在笨的可以.

我果然要放一下假 , 放空放空 腦子裝太多東西了~

@@" 前幾天白忙了 一晚.

[FIEND]

TCP 的  使用者間 雙向溝通 , 應該是這個解法最理想了.

迴路裡 直接套用 現成的 強大 CALLBACK 模組.

CALLBACK 模組本身具有記憶體和物件 生命週期管理

不用 30分就可以完成這個功能.

XD .... 又學了一招~~~~

[FIEND]

剛才寫了一支~

DOS 攻擊程式...

狂轟

接收的接口.

效能比起第一張圖 沒快上多少.....

我又改寫了 DOS 攻擊方式 , 直接在建好連線後 , 再狂轟....

效能馬上好很多!!!

果然是這個解法好.

[FIEND]

又補了一佪邏輯.

在 ACCEPT 完  , 接下去 多一個 TCP 請求端的 CLIENT 連線端口的第一次 發送請求的確認.

如果丟出去沒有人回應 , 就直接中斷 異步 IO 的單一用戶的 請求.

來防止 , 有一些自以為網路很利害的小朋友 抓了一些TCP攻擊工具 ,  丟了就跑 害 SERVER 白做工.

有點像 有人按你家門鈴 你會先確認 , 按門鈴的人有沒有站在門口 , 跟他說一句話 看看有沒有反應 , 有的話才去樓下接他.

如果是 鄰居的死小孩按完就跑 , 就不用理它.

加強 安全性 , 降低 洪水攻擊 的負擔 .

這架構 好多變化....... 真爽 ~~

樓上的 , 圖己改.

[FIEND]

又補了一佪邏輯.

在 ACCEPT 完  , 接下去 多一個 TCP 請求端的 CLIENT 連線端口的第一次 發送請求的確認.

如果丟出去沒有人回應 , 就直接中斷 異步 IO 的單一用戶的 請求.

來防止 , 有一些自以為網路很利害的小朋友 抓了一些TCP攻擊工具 ,  丟了就跑 害 SERVER 白做工.

有點像 有人按你家門鈴 你會先確認 , 按門鈴的人有沒有站在門口 , 跟他說一句話 看看有沒有反應 , 有的話才去樓下接他.

如果是 鄰居的死小孩按完就跑 , 就不用理它.

加強 安全性 , 降低 洪水攻擊 的負擔 .

這架構 好多變化....... 真爽 ~~

樓上的 , 圖己改.

自~HIGH~好久 @@"     .........

這篇文章議題應該 CLOSE 掉了.


下個 ENDING :

以前我們公司有個很會寫 網路層分位的高手 .

可惜他得了一場大病 前幾年 升天了.

以前雖然常吵架 , 但是現在好想念他....

他一定可以給我更好的建議~~

如果剛好也要做類似設計的請跳出來一起交流.....

潛水去~~等下次遇到問題再來這報到...

[FIEND]

又補了一佪邏輯.

在 ACCEPT 完  , 接下去 多一個 TCP 請求端的 CLIENT 連線端口的第一次 發送請求的確認.

如果丟出去沒有人回應 , 就直接中斷 異步 IO 的單一用戶的 請求.

來防止 , 有一些自以為網路很利害的小朋友 抓了一些TCP攻擊工具 ,  丟了就跑 害 SERVER 白做工.

有點像 有人按你家門鈴 你會先確認 , 按門鈴的人有沒有站在門口 , 跟他說一句話 看看有沒有反應 , 有的話才去樓下接他.

如果是 鄰居的死小孩按完就跑 , 就不用理它.

加強 安全性 , 降低 洪水攻擊 的負擔 .

這架構 好多變化....... 真爽 ~~

樓上的 , 圖己改.

自~HIGH~好久 @@"     .........

這篇文章議題應該 CLOSE 掉了.


下個 ENDING :

以前我們公司有個很會寫 網路層分位的高手 .

可惜他得了一場大病 前幾年 升天了.

以前雖然常吵架 , 但是現在好想念他....

他一定可以給我更好的建議~~

如果剛好也要做類似設計的請跳出來一起交流.....

潛水去~~等下次遇到問題再來這報到...

可惡還沒完!! 本來以為結案了.

我在 TRACE 封包時 , 發現一個大 BUG.

如果用戶是正常 離開 所有開放給這個用戶的異步迴路會自動被切斷.

如果用戶不是正常離開 , 但是它己經完成一開始的交易認證機制.

偶爾會讓 迴路死在裡面沒有主人 但是它還在跑.

看來還是要做一個 容器來監控每一個迴路的生命週期.

背後自己把迴路給淦掉.

[FIEND]

又補了一佪邏輯.

在 ACCEPT 完  , 接下去 多一個 TCP 請求端的 CLIENT 連線端口的第一次 發送請求的確認.

如果丟出去沒有人回應 , 就直接中斷 異步 IO 的單一用戶的 請求.

來防止 , 有一些自以為網路很利害的小朋友 抓了一些TCP攻擊工具 ,  丟了就跑 害 SERVER 白做工.

有點像 有人按你家門鈴 你會先確認 , 按門鈴的人有沒有站在門口 , 跟他說一句話 看看有沒有反應 , 有的話才去樓下接他.

如果是 鄰居的死小孩按完就跑 , 就不用理它.

加強 安全性 , 降低 洪水攻擊 的負擔 .

這架構 好多變化....... 真爽 ~~

樓上的 , 圖己改.

自~HIGH~好久 @@"     .........

這篇文章議題應該 CLOSE 掉了.


下個 ENDING :

以前我們公司有個很會寫 網路層分位的高手 .

可惜他得了一場大病 前幾年 升天了.

以前雖然常吵架 , 但是現在好想念他....

他一定可以給我更好的建議~~

如果剛好也要做類似設計的請跳出來一起交流.....

潛水去~~等下次遇到問題再來這報到...

可惡還沒完!! 本來以為結案了.

我在 TRACE 封包時 , 發現一個大 BUG.

如果用戶是正常 離開 所有開放給這個用戶的異步迴路會自動被切斷.

如果用戶不是正常離開 , 但是它己經完成一開始的交易認證機制.

偶爾會讓 迴路死在裡面沒有主人 但是它還在跑.

看來還是要做一個 容器來監控每一個迴路的生命週期.

背後自己把迴路給淦掉.

省資源 想破頭了.....

另外做了 MAP 的個開關.

http://phorum.study-area.org/index.php/topic,67607.msg332764.html#new

在使用者完成驗證後 才會同意打開 5,6 迴路.

當使用者離開或者是重覆做驗證的動作.

系統會強迫性的把 沒用到的 連線及迴路全部強制關閉.

[FIEND]

把 SOCKET 指標 存在記憶體容器後.

我發現可以自由的控制迴路何時要啟動.

何時要關閉.

假如 有使用者離開一陣子沒有操作 , 還可以放一支 THREAD 在背後檢查是不是該 清掉沒人用的迴路.

如果有使用者在連線之下 , 重新驗證登入條件 , 還可以直接把上次的登入的迴路全部淦掉.

超歡樂的.

[FIEND]

把 SOCKET 指標 存在記憶體容器後.

我發現可以自由的控制迴路何時要啟動.

何時要關閉.

假如 有使用者離開一陣子沒有操作 , 還可以放一支 THREAD 在背後檢查是不是該 清掉沒人用的迴路.

如果有使用者在連線之下 , 重新驗證登入條件 , 還可以直接把上次的登入的迴路全部淦掉.

超歡樂的.

一點都不歡樂... 抓了二天的BUG XD .

還好都解決了~~

又把這個開關做了加強的功能.....

另外開了一個 房間 楖念的 記憶體容器.

當有人進入同一個房間後 , 當任何一個人有任何的動作.

講話 , 走路 , 或是管理員群發訊息 ....

這間房間的人會由 READ 去觸發 並且透過 5,6 迴路得到 其它人的狀態 , 同時也可以發送狀態給別人.

叫下面的人做一下 3D 元件 套看看能不能組成一套 3D GAME 的底層引擎~~哈哈~

[FIEND]

把 SOCKET 指標 存在記憶體容器後.

我發現可以自由的控制迴路何時要啟動.

何時要關閉.

假如 有使用者離開一陣子沒有操作 , 還可以放一支 THREAD 在背後檢查是不是該 清掉沒人用的迴路.

如果有使用者在連線之下 , 重新驗證登入條件 , 還可以直接把上次的登入的迴路全部淦掉.

超歡樂的.

一點都不歡樂... 抓了二天的BUG XD .

還好都解決了~~

又把這個開關做了加強的功能.....

另外開了一個 房間 楖念的 記憶體容器.

當有人進入同一個房間後 , 當任何一個人有任何的動作.

講話 , 走路 , 或是管理員群發訊息 ....

這間房間的人會由 READ 去觸發 並且透過 5,6 迴路得到 其它人的狀態 , 同時也可以發送狀態給別人.

叫下面的人做一下 3D 元件 套看看能不能組成一套 3D GAME 的底層引擎~~哈哈~

今天又接到一個需求....

要我同時在一台伺服器上開二個 SERVER ....

然後

第一台伺服器做 服務 端.

第二台伺服器 做 控制 端.

控制端可以 對 服務端 做廣撥,強迫下線,踢出房問........

所以我直接把 5,6 又拆成一個 全域物件指標.

丟給控制端用 .

然後從記憶體把 SOCKET* 叫出來 , 丟到 5,6 去跑.

5,6 會把丟進來的 socket 指標  map::iterator 全部消化掉.

做成一個 異地控制台廣撥的功能.

XD .............. 好想罵人~~