gateway使用的tcp協(xié)議,socket數(shù)據(jù)"粘包"我已經(jīng)通過(guò)程序處理,但是這種插隊(duì)問(wèn)題感覺無(wú)法通過(guò)程序代碼解決

不會(huì)出現(xiàn)插隊(duì)
gateway不能用tcp，使用現(xiàn)有協(xié)議或者參考手冊(cè)寫一個(gè)協(xié)議，否則會(huì)粘包，導(dǎo)致數(shù)據(jù)連在一起

我在event.php中的onMessage函數(shù)里面每個(gè)$message記錄了下來(lái),之前所說(shuō)的數(shù)據(jù)包"插隊(duì)"問(wèn)題的場(chǎng)景是這樣的:
有兩個(gè)客戶端同時(shí)向服務(wù)器不停的發(fā)送數(shù)據(jù),架設(shè)兩個(gè)客戶端在一段時(shí)間內(nèi)都向服務(wù)器發(fā)送了3個(gè)數(shù)據(jù)包.在一些情況下客戶端A會(huì)將數(shù)據(jù)以2.5+0.5的方式發(fā)送,即$message中現(xiàn)接受到A的2.5個(gè)數(shù)據(jù)包,然后接收0.5個(gè)剩余數(shù)據(jù)包.但同時(shí)客戶端B向服務(wù)器連續(xù)發(fā)送了3個(gè)數(shù)據(jù)包(按照1+1+1)方式.
最終在onMessage函數(shù)里面每個(gè)$message的順序?yàn)? 2.5(A) 1(B) 1(B) 1(B) 0.5(A).就是我說(shuō)的插隊(duì)現(xiàn)象.

原先我在每個(gè)數(shù)據(jù)包頭中增加了長(zhǎng)度來(lái)處理粘包問(wèn)題.現(xiàn)在想來(lái)那只是針對(duì)單個(gè)sock_id才有用,對(duì)于現(xiàn)在多個(gè)客戶端同時(shí)推送服務(wù)器信息的情景.可能需要對(duì)每個(gè)sock_id設(shè)置獨(dú)立的緩沖區(qū).
假如我按照你的建議寫一個(gè)協(xié)議,是否可以解決我說(shuō)的問(wèn)題?

補(bǔ)充一下,不知道我表達(dá)的是否明確
架設(shè)網(wǎng)關(guān)收到的數(shù)據(jù)包順序: 2.5(A) 1(B) 1(B) 1(B) 0.5(A)
使用多連接共用緩沖區(qū)在解析第三個(gè)數(shù)據(jù)報(bào)文時(shí),會(huì)將A客戶端的0.5個(gè)報(bào)文合并到B客戶端報(bào)文上,導(dǎo)致整體出錯(cuò).
使用自定義協(xié)議的話,能否避免這個(gè)問(wèn)題?

去參考手冊(cè)搞個(gè)協(xié)議就好了
或者直接用workerman的Text協(xié)議
協(xié)議格式為 數(shù)據(jù)包+換行符

問(wèn)題已經(jīng)解決,重新寫了一個(gè)協(xié)議.
原來(lái)對(duì)gateway/worker的運(yùn)行方式理解有誤導(dǎo)致,多謝指導(dǎo)哈

不客氣