酷!學園
技術討論區 => Network 討論版 => 主題作者是: FIEND 於 2012-08-28 19:00
-
下午想了又想....想了又想....
先畫了這張圖...
我的需求是建立一個 雙向溝通的 即時知道對方狀態的伺服器
我先把想法畫成一張圖.....
(http://bbs.ecstart.com/php_tech/arc5.jpg)
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 做...
-
icmp呢？
-
icmp呢？
呼~不用 UDP~~
我也想偷懶~~為了這件事還和下屬吵了一架~~最後我輸了~>_<" 還是用 TCP ....
-
有沒有 網路 專家 幫忙給點建議的......
這是我自己想出來的流程....
不採用 UDP ... 因為這些資訊很重要不能掉封包.
需要 SYN 的 ARC 來確保 資料正確性.
-
有沒有 網路 專家 幫忙給點建議的......
這是我自己想出來的流程....
不採用 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 , 這樣可移值性會高一點~
-
昨天終於把這個功能測完了.
後來還是維持 這個架構沒用 FORK 和 THREAD .
讓迴路保持通暢 , 中間放了 PROCESS 在 餵訊息給 5,6 迴路做迴路開關.
效能比預期的好很多.
我本來還擔心效能會降低.
這個迴路可以應用在 :
1. 即時多人 對戰系統
2. 即時多人 聊天系統
3. 即時多人 分享 ( 非 P2P )
伺服端負責幫 群組內的 使用者做溝通 .
實際上可以多少人在一個群組內 , 還要測試寫程式 實驗.
有更好做法的前輩 , 請給在下一點建議...
因為我也只能想出這個笨方法.
-
我放假時 , 放空了二天 ,
今天一大早~就想起 , 以前層經看過一個開放原碼的範例 , 突然靈機一閃...
馬上狂改程式 .......... 拼命寫程式 %$@#%#%Q#QWR%@#%#.
測試看看 :
(http://bbs.ecstart.com/php_tech/arc5_1.jpg)
XD 可以咧 , 更簡單有力!!!!
要什麼THREAD , 還要去控制它的迴路生命週期....
寫錯了可會造成災難~~
我實在笨的可以.
我果然要放一下假 , 放空放空 腦子裝太多東西了~
@@" 前幾天白忙了 一晚.
-
TCP 的 使用者間 雙向溝通 , 應該是這個解法最理想了.
迴路裡 直接套用 現成的 強大 CALLBACK 模組.
CALLBACK 模組本身具有記憶體和物件 生命週期管理
不用 30分就可以完成這個功能.
XD .... 又學了一招~~~~
-
剛才寫了一支~
DOS 攻擊程式...
狂轟
接收的接口.
效能比起第一張圖 沒快上多少.....
我又改寫了 DOS 攻擊方式 , 直接在建好連線後 , 再狂轟....
效能馬上好很多!!!
果然是這個解法好.
-
又補了一佪邏輯.
在 ACCEPT 完 , 接下去 多一個 TCP 請求端的 CLIENT 連線端口的第一次 發送請求的確認.
如果丟出去沒有人回應 , 就直接中斷 異步 IO 的單一用戶的 請求.
來防止 , 有一些自以為網路很利害的小朋友 抓了一些TCP攻擊工具 , 丟了就跑 害 SERVER 白做工.
有點像 有人按你家門鈴 你會先確認 , 按門鈴的人有沒有站在門口 , 跟他說一句話 看看有沒有反應 , 有的話才去樓下接他.
如果是 鄰居的死小孩按完就跑 , 就不用理它.
加強 安全性 , 降低 洪水攻擊 的負擔 .
這架構 好多變化....... 真爽 ~~
樓上的 , 圖己改.
-
又補了一佪邏輯.
在 ACCEPT 完 , 接下去 多一個 TCP 請求端的 CLIENT 連線端口的第一次 發送請求的確認.
如果丟出去沒有人回應 , 就直接中斷 異步 IO 的單一用戶的 請求.
來防止 , 有一些自以為網路很利害的小朋友 抓了一些TCP攻擊工具 , 丟了就跑 害 SERVER 白做工.
有點像 有人按你家門鈴 你會先確認 , 按門鈴的人有沒有站在門口 , 跟他說一句話 看看有沒有反應 , 有的話才去樓下接他.
如果是 鄰居的死小孩按完就跑 , 就不用理它.
加強 安全性 , 降低 洪水攻擊 的負擔 .
這架構 好多變化....... 真爽 ~~
樓上的 , 圖己改.
自~HIGH~好久 @@" .........
這篇文章議題應該 CLOSE 掉了.
下個 ENDING :
以前我們公司有個很會寫 網路層分位的高手 .
可惜他得了一場大病 前幾年 升天了.
以前雖然常吵架 , 但是現在好想念他....
他一定可以給我更好的建議~~
如果剛好也要做類似設計的請跳出來一起交流.....
潛水去~~等下次遇到問題再來這報到...
-
又補了一佪邏輯.
在 ACCEPT 完 , 接下去 多一個 TCP 請求端的 CLIENT 連線端口的第一次 發送請求的確認.
如果丟出去沒有人回應 , 就直接中斷 異步 IO 的單一用戶的 請求.
來防止 , 有一些自以為網路很利害的小朋友 抓了一些TCP攻擊工具 , 丟了就跑 害 SERVER 白做工.
有點像 有人按你家門鈴 你會先確認 , 按門鈴的人有沒有站在門口 , 跟他說一句話 看看有沒有反應 , 有的話才去樓下接他.
如果是 鄰居的死小孩按完就跑 , 就不用理它.
加強 安全性 , 降低 洪水攻擊 的負擔 .
這架構 好多變化....... 真爽 ~~
樓上的 , 圖己改.
自~HIGH~好久 @@" .........
這篇文章議題應該 CLOSE 掉了.
下個 ENDING :
以前我們公司有個很會寫 網路層分位的高手 .
可惜他得了一場大病 前幾年 升天了.
以前雖然常吵架 , 但是現在好想念他....
他一定可以給我更好的建議~~
如果剛好也要做類似設計的請跳出來一起交流.....
潛水去~~等下次遇到問題再來這報到...
可惡還沒完!! 本來以為結案了.
我在 TRACE 封包時 , 發現一個大 BUG.
如果用戶是正常 離開 所有開放給這個用戶的異步迴路會自動被切斷.
如果用戶不是正常離開 , 但是它己經完成一開始的交易認證機制.
偶爾會讓 迴路死在裡面沒有主人 但是它還在跑.
看來還是要做一個 容器來監控每一個迴路的生命週期.
背後自己把迴路給淦掉.
-
又補了一佪邏輯.
在 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 迴路.
當使用者離開或者是重覆做驗證的動作.
系統會強迫性的把 沒用到的 連線及迴路全部強制關閉.
-
把 SOCKET 指標 存在記憶體容器後.
我發現可以自由的控制迴路何時要啟動.
何時要關閉.
假如 有使用者離開一陣子沒有操作 , 還可以放一支 THREAD 在背後檢查是不是該 清掉沒人用的迴路.
如果有使用者在連線之下 , 重新驗證登入條件 , 還可以直接把上次的登入的迴路全部淦掉.
超歡樂的.
-
把 SOCKET 指標 存在記憶體容器後.
我發現可以自由的控制迴路何時要啟動.
何時要關閉.
假如 有使用者離開一陣子沒有操作 , 還可以放一支 THREAD 在背後檢查是不是該 清掉沒人用的迴路.
如果有使用者在連線之下 , 重新驗證登入條件 , 還可以直接把上次的登入的迴路全部淦掉.
超歡樂的.
一點都不歡樂... 抓了二天的BUG XD .
還好都解決了~~
又把這個開關做了加強的功能.....
另外開了一個 房間 楖念的 記憶體容器.
當有人進入同一個房間後 , 當任何一個人有任何的動作.
講話 , 走路 , 或是管理員群發訊息 ....
這間房間的人會由 READ 去觸發 並且透過 5,6 迴路得到 其它人的狀態 , 同時也可以發送狀態給別人.
叫下面的人做一下 3D 元件 套看看能不能組成一套 3D GAME 的底層引擎~~哈哈~
-
把 SOCKET 指標 存在記憶體容器後.
我發現可以自由的控制迴路何時要啟動.
何時要關閉.
假如 有使用者離開一陣子沒有操作 , 還可以放一支 THREAD 在背後檢查是不是該 清掉沒人用的迴路.
如果有使用者在連線之下 , 重新驗證登入條件 , 還可以直接把上次的登入的迴路全部淦掉.
超歡樂的.
一點都不歡樂... 抓了二天的BUG XD .
還好都解決了~~
又把這個開關做了加強的功能.....
另外開了一個 房間 楖念的 記憶體容器.
當有人進入同一個房間後 , 當任何一個人有任何的動作.
講話 , 走路 , 或是管理員群發訊息 ....
這間房間的人會由 READ 去觸發 並且透過 5,6 迴路得到 其它人的狀態 , 同時也可以發送狀態給別人.
叫下面的人做一下 3D 元件 套看看能不能組成一套 3D GAME 的底層引擎~~哈哈~
今天又接到一個需求....
要我同時在一台伺服器上開二個 SERVER ....
然後
第一台伺服器做 服務 端.
第二台伺服器 做 控制 端.
控制端可以 對 服務端 做廣撥,強迫下線,踢出房問........
所以我直接把 5,6 又拆成一個 全域物件指標.
丟給控制端用 .
然後從記憶體把 SOCKET* 叫出來 , 丟到 5,6 去跑.
5,6 會把丟進來的 socket 指標 map::iterator 全部消化掉.
做成一個 異地控制台廣撥的功能.
XD .............. 好想罵人~~