顯示文章

這裡允許您檢視這個會員的所有文章。請注意, 您只能看見您有權限閱讀的文章。


文章 - FIEND

頁: 1 2 [3] 4 5 ... 24
61
IE8 會先載入 ELEMENT 才可以 在 JS 上 認的出 你指定的 OBJECT ID

很王八蛋的設計. ( SORRY 我是超級排軟派 )

解法 :

1. 在 MINE TYPE 上 下 :
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

2. 直接把 JS 放在 ELEMENT 下面

<BODY>

ELEMENT .......


JS : GET Object id.

</BODY>


62
又補了一佪邏輯.

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

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

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

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

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

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

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

樓上的 , 圖己改.

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

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


下個 ENDING :

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

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

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

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

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

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

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

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

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

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

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

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

背後自己把迴路給淦掉.




63
小弟是在一間小的線上遊戲公司~~包山包海一人MIS
這樣可以學到許多東西,摸到很多人碰不到的機器,可喜可賀!

這樣就可以取得很多伺服器端,架設很少人連線的私服,可喜可賀!?

我之前的公司有一千二百台正在運作的伺服器.....

每天搬機器搬來搬去 三不五時還要被我罵.

一點都不覺得MIS過的很開心 @@"


64
Linux 討論版 / Re: openvpn ping
« 於: 2012-09-05 08:28 »
感謝netman & scc_james 前輩們的熱心回應,
小弟測試後的結果還是不行,
scc_james我有照你的全貼, 跟我自己寫那一行的結果是一樣的,

我server.conf的設定如下
port 1194
proto udp
dev tun
ca xxx.crt
cert xxx.crt
key xxx.key  # This file should be kept secret
dh dh2048.pem
server 10.5.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.5.0.0 255.255.255.0"
push "redirect-gateway"
keepalive 10 120
tls-auth xxx.key 0 # This file is secret
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

請高人指點^^

比較快的方式是 直接監控 UDP 封包的交易情況.

1. tcpdump -i eth0 udp port 1194
2. tcpdump -i tun0

由 CLIENT 端發送 ICMP.

在~SERVER 端監控封包有沒有流入.

如果有流量

再看 SERVER 端的封包有沒有流出.

從中間觀查真正的原因.

很快你就可以測出實際的狀況.

實際一點 TRACE 你的封包的交易情況.

不要用猜的 , 這樣做事會很沒效率.



##############

有可能造成這種現像的情況有幾種 :

CASE 1.

加密 KEY 有問題 :

    openvpn --genkey --secret key
    openvpn --test-crypto --secret key


CASE 2.

IPTABLE 沒有設定好 :

iptables -A INPUT -i tun+ -j ACCEPT    <<< 開放了沒?
iptables -A INPUT -i tap+ -j ACCEPT     <<  你是使用 TUN 看你要不要開放


CASE3.

區網防火牆 或 SWITCH 有 下 ACL 阻止 這台 120.105.1.10 UDP 封包.

CASE{N}....................



65
軟體研發和開發..

角色是 -

不停的罵人的討厭鬼.

最高計錄同時罵哭六個人 同時趴在桌上哭.

每年至少把 幾個新人 搞到精神漰潰 逃到廁所哭.

最大的作用是 員工們的 私底下 總是有話題可以罵我.

讓員工的向心力變大.




66
我用自己的程式 java -jar s.jar & 打开了一个端口9001
处于listen状态
代碼: [選擇]
[root@localhost server]# netstat -tlan | grep 9001
tcp        0      0 :::9001                     :::*                        LISTEN 

[root@localhost server]# jobs
[1]+  Running                 java -jar s.jar &

如果客户端在使用这个端口,就OK,
如果客户端没有使用这个端口,好像就会直接关闭这个端口,这是为什么啊。命令要怎么用才能让这个端口一直开启啊。谢谢

你是做 同步 IO ? 異步 IO?  ACCEPT 底下有迴路在跑嗎?

假設你使用 同步或異步 , 而且你知道 ACCEPT 底下要做 迴路.

我想這應該是常識 , 樓主應該觀念沒差到這種程度.

假設你都懂 那這問題 就跟 FORK 或 THREAD 沒有太大的關係.


#####


好久沒用 JAVA 了.... @@ 老實說 我討厭 JAVA 在網路層的執行效能和處理速度.

大多我都用在 應用層和展示層 , 比較底層的應用 , 我通常都拒絕使用它.

利用 Socket.setSoTimeout(expiredTime) 搭配 Socket.setKeepAlive(true)

再試看看吧.

1. setKeepAlive :
http://docs.oracle.com/javase/1.4.2/docs/api/java/net/Socket.html#getKeepAlive%28%29

2. setSoTimeout :
http://docs.oracle.com/javase/1.4.2/docs/api/java/net/Socket.html#getSoTimeout%28%29

3. connect :   ( 第二個參數 )
http://docs.oracle.com/javase/1.4.2/docs/api/java/net/Socket.html#connect%28java.net.SocketAddress,%20int%29



如果試了還有問題 , 再試試 物件裡 其它 參數.

http://docs.oracle.com/javase/1.4.2/docs/api/java/net/Socket.html


PS :

這問題非常直覺得看完 API 手冊就可以試出問題了.

JAVA 的 API 手冊 要常看 , 常用 , 常實驗 , JAVA 的物件庫很強大 , 慣壞很多人......

但是它的開發速度真的很省時....

要常玩玩 API 手冊裡每一個 物件裡的參數 使用上會有什麼效果.




67
又補了一佪邏輯.

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

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

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

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

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

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

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

樓上的 , 圖己改.

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

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


下個 ENDING :

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

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

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

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

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

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



68
你們是用 45 做 HA 嗎?

其實我不太建議 在 SNMP 上開這麼重的 功能.

你可以測試一下 , 有開和沒開 CPU 的使用率 .

可以改用 MONITOR 的方式  ,直接讀取 INTERFACE 上的 NETFLOW 會比較輕.



69
應該是後者. 網路上的 1K 是 1000, 不是 1024.

感謝twu2前輩的回覆^^

對snmp traffic的值真的不太了解~
所以一直對流量圖和設定對不起來@@~

@@" 樓主大哥.......誤差的問題 , 應該不是這樣判斷的.......

你是使用 MIB 的那個 OID ? 可以給個 OID NUMBER 嗎?


我猜這情況是這樣 :

http://www.cisco.com/en/US/docs/ios-xml/ios/netflow/configuration/12-4t/cfg-snmp-mib-mon-nf.html

MIB 去 獲得 SNMP 的 TRAFFIC 是使用 NETFLOW .

NETFLOW 不是一個 實際的流量值 , 而是一個抽樣分析的流量值.

所以會有誤差是正常的.

不過誤差也不會那麼大 , NETFLOW 都出到 V9 了, 演算法應該會更精準很多.

也有可能是 STG 沒寫好 或是 NETFLOW 的分位太舊.

這點反而 SFLOW 做的比較好 , SFLOW 的平均值 有一個演算法可以較精準的算回實際流量值.




70
Network 討論版 / Re: ipv6管控?
« 於: 2012-09-04 09:08 »
至於分位的問題 , 你沒有說你們家用那個型號那個廠牌的 L3 設備.

所以沒法子回覆你.

另外 , 我記得 2010 年 發生二件大事 :

個資法通過 還有 教育部先推 IPV6 , 行政院也公告要推 IPV6 ......

你們應該是公家機關吧?

現在一台 3750 價格真的不貴 早期買 3750 的就解套了.

我記得中信標裡 價格壓很低了.

翻翻你們家中信標裡的 價格表 , 考慮採構一些新的設備或是升級分位.

辛苦囉 ^^




71
Network 討論版 / Re: ipv6管控?
« 於: 2012-09-04 08:59 »
沒人回你~我回你好了~~


你們用那家的 SWITCH ?

STATIC ARP  的方式如果 IPV6 沒支援.

可以試著升級分位看看有沒有新的IPV6 ACL 的SUPPORT.

一般來說有 SWITCH 原廠 GOLD PARTNER 的 SI 都會有 幫客戶升級分位的專業人士.

如果沒有可能你們要編預算採購一批新的 LAYER3 設備了.


在這之前 , 你可以用 STATIC INTERFACE PORT LOCK 的方式 ,  把 MAC 鎖在 INTER FACE 上面.

先做 LAYER2 層的封鎖.

LAYER2 的 DEVICE 不貴 , 如果你們單位LAYER 2 有支援 STATIC INTERFACE PORT LOCK 挷定的功能.

其實鎖在 LAYER2 層會更安全.

而且可以降低 LAYER3 層的工作負擔 , 讓 LAYER3 層不用忙於做 STATIC ARP.

這問題不難 , 如果你們公司有 SI SUPPORT , CCIE 會給你很專業的意見.

補充說明 :

剛才你問了二個問題

上一篇回覆了 STATIC ARP 的問題.

而如果你要做 TCP/UDP PROTOCOL 的 ACL .

如果現在你們手上的 SWITCH 沒有支援 , 也無法升級分位 , 而你們又急於把某個服務的 IPV6 的 安全性補強.

可以先採構幾台較新型的 SWITCH 或 FIREWALL , 直接拉到舊的SWITCH 下面 , 然後在 下面 下 ACL 過濾封包.

我當然一定推薦 CISCO .

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-sec_trfltr_fw.html 
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/configuration/guide/swv6acl.html


72
Network 討論版 / Re: ipv6管控?
« 於: 2012-09-04 08:41 »
沒人回你~我回你好了~~


你們用那家的 SWITCH ?

STATIC ARP  的方式如果 IPV6 沒支援.

可以試著升級分位看看有沒有新的IPV6 ACL 的SUPPORT.

一般來說有 SWITCH 原廠 GOLD PARTNER 的 SI 都會有 幫客戶升級分位的專業人士.

如果沒有可能你們要編預算採購一批新的 LAYER3 設備了.


在這之前 , 你可以用 STATIC INTERFACE PORT LOCK 的方式 ,  把 MAC 鎖在 INTER FACE 上面.

先做 LAYER2 層的封鎖.

LAYER2 的 DEVICE 不貴 , 如果你們單位LAYER 2 有支援 STATIC INTERFACE PORT LOCK 挷定的功能.

其實鎖在 LAYER2 層會更安全.

而且可以降低 LAYER3 層的工作負擔 , 讓 LAYER3 層不用忙於做 STATIC ARP.

這問題不難 , 如果你們公司有 SI SUPPORT , CCIE 會給你很專業的意見.


73
又補了一佪邏輯.

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

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

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

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

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

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

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

樓上的 , 圖己改.


74
L7 層 的監控設備 不太會用來 FILTER 這種類型的封包.

大部份都是拿來做為 異常封包的檢查和過濾.

DNS 的封包 是走 Broadcast 架構 , 可以隋意更改 AP 端的設定 , 擋不住熱情的員工出去上網.


最省錢實惠的方式

是把 SRC IP ,  SRC PORT , DST IP , DST PORT 下 ACL BLOCK 起來.

或是架設 PROXY SERVER 把 內網所有對外的封包全部 BLOCK 起來 只開放這台 PROXY SERVER 出去.

然後在 PROXY SERVER 上下 ACL 來過濾不想出去和進來的封包.

目前 安全層級比較高的單位會用 第二種方式.

例如 : 總X府 , 台X電  , 軍X .........

如果沒有錢買可以下 L3 層 ACL 的設備 , 其實 有支援 L3 ACL 的設備 5000~30萬 不等 而己.

可以 用 LINUX 架 NAT , 直接在 NAT 裡 下 ACL 來阻止 不想放出去和進來的封包.

這樣做比較可以做到 阻止 不想要進和出的 封包.




如果有人走跳板出去

我的做法是背後放一台 PORT MIRROR 的 Analysis 設備在監控 跳板行為 .

我以前寫過一支攻擊程式.

會在走跳板的行為上 , 發出 EVENT .

然後我會開始在區網 利用 DNS 封包的特性 , 搶 遠端 DNS SERVER 的回應封包 , 在區網裡給假的封包 , 攻擊這個用跳板的用戶 , 讓它無法使用這個服務.

一般來說 區網搶遠端 DNS 的封包太容易了.

所以這樣攻擊 違法用戶 , 還可以在他的電腦上 警告他不要玩.




75
L7 層 的監控設備 不太會用來 FILTER 這種類型的封包.

大部份都是拿來做為 異常封包的檢查和過濾.

DNS 的封包 是走 Broadcast 架構 , 可以隋意更改 AP 端的設定 , 擋不住熱情的員工出去上網.


最省錢實惠的方式

是把 SRC IP ,  SRC PORT , DST IP , DST PORT 下 ACL BLOCK 起來.

或是架設 PROXY SERVER 把 內網所有對外的封包全部 BLOCK 起來 只開放這台 PROXY SERVER 出去.

然後在 PROXY SERVER 上下 ACL 來過濾不想出去和進來的封包.

目前 安全層級比較高的單位會用 第二種方式.

例如 : 總X府 , 台X電  , 軍X .........


76
請問php可否作到發表一個文章,可以同步到
fb google+ plurk twitter
或目前只可以同步到那裡呢
謝謝

沒人回你.......  我回你好了.

這些 交友平台 本身都有提供 SDK 供人串接.

而且你要申請 APP 來串接.

不過因為安全性 , 也慢慢拿掉很多 PHP 能做的功能了.

你要的應該是 Send Message To (Friends或自己) Wall  ( 發送訊息到(朋友或自己)的塗鴉牆 )

我己經很久沒有自己親自下去玩 這些 SDK 了 , 大部份都是給下面的人去做.

我比較建議你用 畫面邏輯 的 SDK 元件去觸發.

例如 : FLASH AS , JS , AJAX , JQUERY 等等.....

因為 就算你要用 PHP 來發送 , 你也必需在 瀏覽器上 經過 第三方驗證 使用者的登入訊息 , 才可以進行溝通.

而你要群發到非自己的好友的WALL是做不到的 , 除非你的 ACCOUNT 本身有這些好友. ( 這是安全性考量 )

所以 沒必要再往你自己的 SERVER 丟 溝通訊息進去 然後再出來.

浪費 SERVER 的溝通效能.

意思就是 ( 這塊不要用 PHP 做 , 改用 畫面邏輯SDK來做 )

除非你要做壞事 , 群發 廣告 到 WALL .

這個我就不方便教你了 ^^"






77
今天無聊 , 又穿插了一個 自動 把 容器內容的 新增 修改 自動廣撥並且插入其它遠端的容器.

等到所有容器都倒滿才會回應新增修改的成功訊息.

然後再去使用 LINUX KERNEL 層的 SHM 元件 MMAP , 來備份及倒回容器.

達到 分散式存取和備份及ROLLBACK 的功能.

而 連結的接口 會有一個 Leader Server 來與 SERVER 做長連結的溝通.

測試起來 , 新增的速度隋然降低了一點點.

但是讀取的效能不變.

每秒與 PHP-FPM 背後自己DIY 開的一個後門程式 , 溝通的速度可以達到 18000 次.

看起來 PHP 在分散式快取上 , 應該還有很大的進步空間.

不過這方法 , 做成 元件庫 應該會有很多 需要 教育訓練還有網路知識要再加強的問題.

原方法 顯然會讓使用者易懂多了.




78
剛才寫了一支~

DOS 攻擊程式...

狂轟

接收的接口.

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

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

效能馬上好很多!!!

果然是這個解法好.


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

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

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

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

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


80
我放假時 , 放空了二天 ,

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

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

測試看看 :




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

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

寫錯了可會造成災難~~


我實在笨的可以.

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

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



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

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

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

效能比預期的好很多.

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

這個迴路可以應用在 :

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

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

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

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

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


82
PHP程式設計討論區 / Re: 請問關於fb
« 於: 2012-08-31 11:37 »
把FB引入到自家的商城就好了

FB 在 2011 發佈 相關的CREDIT 的 POLICY , 真的有點讓很多公司入不了門.

我記得是年中發佈的 , 年底強制執行.

害我們改了很多CODE.

這樣也好 , 不然真的不小心做大了  , 也很麻煩.




83
找到答案了...

因為我掛在~BOOST 的 IO_SERVER下,member function is overloaded .


http://stackoverflow.com/questions/9048119/why-doesnt-stdbind-and-boostbind-cant-be-used-interchangeably-in-this-boos

The boost::asio::io_service::run() member function is overloaded: one version takes no argument while another version takes one argument. That is, taking the address of the of boost::asio::io_service::run requires a context in which the compiler can directly deduce the signature of the function. However, std::bind() isn't required to do deduction magic while it seems that boost::bind() attempts to locate a matching overload i.e. it seems for its first argument type to be readily constrained (assuming the boost example indeed compiles).

剛想成功的CALL THREAD 了~


                std::thread bw(&session::brocastWrite,this);
                bw.join() ;

但是在~BOOST 下的 異步~IO 底下做會卡到另一個 PROCESS.

怪怪的~

所以乾脆~讓它繞過第二圈 遞迴式 CALL BACK 生成一個永遠有效的第三圈~做一個 開關 ,

後面跑支 FORK 控制 KERNEL 層的共享記憶體( KERNEL 層元件 的 SHM )來決定要不要讓流程走過去.......

應急用~>_<" XD ......

趕時間東西寫到都快四不像了~~我好爛~~~~


84
找到答案了...

因為我掛在~BOOST 的 IO_SERVER下,member function is overloaded .


http://stackoverflow.com/questions/9048119/why-doesnt-stdbind-and-boostbind-cant-be-used-interchangeably-in-this-boos

The boost::asio::io_service::run() member function is overloaded: one version takes no argument while another version takes one argument. That is, taking the address of the of boost::asio::io_service::run requires a context in which the compiler can directly deduce the signature of the function. However, std::bind() isn't required to do deduction magic while it seems that boost::bind() attempts to locate a matching overload i.e. it seems for its first argument type to be readily constrained (assuming the boost example indeed compiles).


85

error: no matching function for call to ‘std::thread::thread(<unresolved overloaded function type>)’
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread:132: note: candidates are: std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = void (session::*)(), _Args = ]
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread:128: note:                 std::thread::thread(_Callable) [with _Callable = void (session::*)()]
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread:124: note:                 std::thread::thread(std::thread&&)
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread:122: note:                 std::thread::thread(const std::thread&)
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/thread:121: note:                 std::thread::thread()
./src/wge.cpp:484: error: expected ‘;’ before ‘readClientRequest’



有沒有人遇過 一樣的問題 >_<"




86
??? php 跟 memcache access 有這麼慢嗎??
平常拿來當Cache處理,效能最少都有 10000 req/s 以上
1600會不會太誇張了。
瓶頸應該是卡在php-fpm的fcgi分發上吧...

你誤會文意囉 , 這個 1600 指的不是 MC 的速度 , 指的是 MC 目前在~PHP 的架構上 走上 NGINX 後 , 所得到 單一個 來源 非併發的可消化數量.

己經很高了 , 平時有流量時應該低於一千 我試過丟到之前公司的服務上測 不到 600.

PHP-FPM 的影響其實沒那麼大~調的好單純只有~FPM 每秒可以到 六千左右~

####
原本舊的方法是

CLIENT  <---->  NGINX(APACHE) <---> PHP-FPM <---> 你寫的 AP 程式 <---> MEMCACHE

平均每秒一個 CONNECT 只 可以處理 1600 次. ( 原因是 MEMCACHE 跟 PHP 的溝通還是停留在短連結 , 而且溝通太多層 , 併發測試 會高上很多但是 純碎的效能要看單一 CONNECT 的次數喔. )  <<< 怕誤會有特別標明原因..
####

所以要想法子往前掛~~

########
新架構的想法 :

CLIENT <----> NGINX ( PLUGING ) <----> PHP-FPM ( PLUGING )  <--- PHP , 直接搖控 PHP-FPM 的存取內容
                                                   |             |
                                                   |             |
                                                   |             |
                                         ( DIY SESSION SERVER )               
########

而且要放棄短連線的做法.

如果沒有改~ULIMIT 會更低.

我在做實驗~~降低 TCP 連線的 LOADING~~~

讓 連線數減少 .

MC 直接在 COMMAND MODE 下 調完 作業系統的 網路參數 我測過最高可以跑到一萬六 ..

所以其實中間那個容器用 MC 也可以 , 但是PHP 跟 MC 之間 PHP元件沒有支援長連線的接口.

主要是它走 HTTP BASE 才會是這樣的架構.

( HTTP <--> PHP-FPM <-->PHP <--> MC ) , 所以它沒有設計長連結的方式 , 要另外中間再做一個 SERVER 來讓 PHP 直接讀取(保持連線). ( 以達到降低連線數的目地 )

如果能剋服這個問題 就可以加速很多.

實際上 MC 在底層夠快 但是一但走到中間的溝通就會降很多.

主軸是 :

1. PHP 怎麼跟 MC 間的 SCOEKT 做長連結接口
2. MC 怎麼直接透過建好的長連結讓 PHP 模組直接使用 , 而不是用 SOCKET 連線的方式來溝通.
3. MC 的 CODE 比較肥 , 所以我先做一個 暫時的容器來替代 MC 這樣實驗起來比較快.

如果說~先解決 SESSION 跟 MC , PHP 的連線問題 , 我想應該網路效能就可以節省很多.

這是我的原意~不好意思~表達不清楚~


#########

實際情況如果在 上百台的分散式架構下 會有更多問題.

個位數的伺服器 對這問題應該興趣會缺缺..

我會有這個想法是因為之前的公司之前花了 200萬 的冤枉錢 去買光纖背板.

就是因為工程師用了太多 MC 了.

之前的公司有五千多萬個會員 , 所以對這個連結數跟網路的消耗 很敏感~~ ^^


87
PHP程式設計討論區 / Re: 請問關於fb
« 於: 2012-08-30 13:52 »
是指fb幣是他們若跟我們銷費,我還要一些錢給fb嗎

是的 我記得是 利潤的三成.

很高~~高到不像話~ ( 等於它的平台給你用來做生意它要賺你利潤的三成就是了 )

不知道POLICY 有沒有做什麼改變~~

你可以去~FB 官網查一下~


88
PHP程式設計討論區 / Re: 請問關於fb
« 於: 2012-08-30 11:58 »
FB 幣 的 抽拥 % 數很高 , 而且新的 POLICY 是除了 FB CREDIT 外 限制使用其它金流

應該不太適合做商城~遊戲才有那種利瀾~

可以試著偷渡~

有人舉發 FB 才會關你的 APP......

>_<" 去年為了這件事~很多公司大地震~這是去年~公佈的新 POLICY ...


89
PHP程式設計討論區 / Re: 請問關於fb
« 於: 2012-08-30 11:57 »
FB 幣 的 抽拥 % 數很高 , 而且新的 POLICY 是除了 FB CREDIT 外 限制使用其它金流

應該不太適合做商城~都給它賺就飽了~遊戲才有那種利瀾~

你們可以試著跟FB談看看....




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

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

不採用 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 , 這樣可移值性會高一點~




頁: 1 2 [3] 4 5 ... 24