自定義協(xié)議粘包問(wèn)題
我在gateway里用自定義tcp協(xié)議，參考text協(xié)議寫的，區(qū)別就是text協(xié)議用的\n作為結(jié)束符，我是用的5555作為結(jié)束符。。。老大說(shuō)，text協(xié)議不會(huì)粘包，但是為啥我用5555結(jié)尾就粘包呢？客戶端是智能電器，可能因網(wǎng)絡(luò)不穩(wěn)定導(dǎo)致的粘包。 我在input($buffer)中，只return一個(gè)包的長(zhǎng)度，但是在encode($buffer)中，還是會(huì)同時(shí)把兩個(gè)包一起發(fā)過(guò)來(lái)。 ...
用workerman代替redis
redis優(yōu)點(diǎn)主要是內(nèi)存讀取和本地持久化，但提供的數(shù)據(jù)類型太簡(jiǎn)單，只能字符串和一維key的操作。所以做做簡(jiǎn)單的存儲(chǔ)和并發(fā)檢索還是可以的，但是要想更復(fù)雜的功能，我們就要基于redis做封裝。 那么，如果用workerman來(lái)開(kāi)發(fā)仿造一個(gè)redis，php-frm直接連接worker進(jìn)程中的內(nèi)存變量，兩者都是常駐內(nèi)存，數(shù)據(jù)也都是在內(nèi)存中的，就像Gateway::bindUid一樣的原理，豈不是更爽。 暫且不管redis的...
Events判斷從哪個(gè)協(xié)議進(jìn)來(lái)的
一個(gè)BusinessWorker對(duì)應(yīng)多個(gè)geteway時(shí)，如何在Events.php中知道geteway是什么協(xié)議方式？...
能否一個(gè)BusinessWorker管理多個(gè)Gateway？
我們有不同類型的硬件設(shè)備，想每種設(shè)備連接不同的Gateway端口。因?yàn)闆](méi)有大面積測(cè)試過(guò)，請(qǐng)教下，如果只開(kāi)一個(gè)register和BusinessWorker來(lái)管理多個(gè)Gateway，有沒(méi)有什么隱患？...
在websocket的onWorkerStart方法中，能否發(fā)送send到客戶端？
需求是這樣的，在onWorkerStart中，定時(shí)檢測(cè)并異步執(zhí)行耗時(shí)任務(wù)，當(dāng)有客戶端連接ws時(shí)，可以實(shí)時(shí)獲取該進(jìn)程任務(wù)的執(zhí)行日志。 目前我采用的方案是文件和redis這樣的中間件。我在想，既然timer和websocket同屬于一個(gè)進(jìn)程，那么能否不用中間件，直接在onWorkerStart里發(fā)送send給客戶端呢？...
跪求，郵件群發(fā)如何提高效率？
由于郵件發(fā)送比較耗時(shí)，所以我用AsyncTcpConnection異步任務(wù)，但由于workerman是多進(jìn)程單線程，那么在如下場(chǎng)景中，該如何提高并發(fā)效率呢？ 場(chǎng)景： 有2個(gè)耗時(shí)任務(wù)需要在同一時(shí)間執(zhí)行，其中一個(gè)是郵件群發(fā)，假設(shè)要發(fā)送1000個(gè)郵件，任務(wù)進(jìn)程100個(gè)。 方案疑問(wèn)： 1、1000個(gè)郵件分別通過(guò)AsyncTcpConnection發(fā)送給100個(gè)進(jìn)程。這種方案會(huì)因?yàn)?00個(gè)進(jìn)程被占滿，而導(dǎo)致另一個(gè)任務(wù)必須等待1...
求解，windows下，開(kāi)啟了多進(jìn)程，協(xié)議還是堵塞的原因
不知道哪里寫的不對(duì)，設(shè)置了4個(gè)進(jìn)程，同時(shí)打開(kāi)3個(gè)網(wǎng)頁(yè)，每個(gè)等待10s，結(jié)果總時(shí)長(zhǎng)需要30s，求大神幫忙解釋下，謝謝了 下圖是http: 下圖是websocket ...
gatewayworker每次重啟，client_id都是從固定的1開(kāi)始
下面兩個(gè)圖是我分別重啟后截圖，默認(rèn)都是從client_id=1開(kāi)始遞增。 這樣是不是一旦項(xiàng)目上線后，就不能關(guān)閉重啟了，只能通過(guò)平滑重啟，不然clietn_id與數(shù)據(jù)庫(kù)的uid對(duì)不上了？或者有沒(méi)有其他解決辦法？ 查看源碼發(fā)現(xiàn)，client_id是通過(guò)ip+端口+connection_id的16進(jìn)制，connection_id是當(dāng)前連接數(shù)，所以workerman重啟后，connection_id就從1重新開(kāi)始計(jì)算了。 /...
