gatewayWorker中連續(xù)接受tcp數(shù)據(jù)時(shí)候丟包

surechina 更新于2016-04-23

用gateway在做一個(gè)轉(zhuǎn)發(fā)的網(wǎng)關(guān)，一邊是tcp socket，一邊是websocket，當(dāng)tcp連續(xù)發(fā)十多條數(shù)據(jù)，每條30字節(jié)左右的數(shù)據(jù)時(shí)，gateway有時(shí)只收到七八條數(shù)據(jù)，可是我加了sleep函數(shù)1s發(fā)送一條時(shí)候，又能完整接受所有數(shù)據(jù)，按理說tcp是不會(huì)出現(xiàn)丟包現(xiàn)象吧，而且我的tcp端每次send都是返回成功（沒有加延時(shí)）的啊，而網(wǎng)關(guān)端卻接受得不對(duì)？是client問題還是server問題呢？求大神解答

 5765  7 0

7個(gè)回答

walkor 2016-04-22

打賞

tcp會(huì)粘包的，你要處理下粘包，你的問題應(yīng)該是粘包引起的。
解決方法參考workerman手冊協(xié)議部分。

暫無評(píng)論

surechina 2016-04-22

在linux用tcpdump抓包，客戶端發(fā)過來14條數(shù)據(jù)，全部抓取到，而且每條數(shù)據(jù)長度正確，就是轉(zhuǎn)發(fā)給websocket時(shí)候轉(zhuǎn)少了幾條，是我的處理器問題嗎？

暫無評(píng)論

surechina 2016-04-22

補(bǔ)充一下：我是用text協(xié)議接收的

暫無評(píng)論

surechina 2016-04-22

18:01:24.583714 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 389:417, ack 7, win 3650, options , length 28
18:01:24.588340 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 417:445, ack 7, win 3650, options , length 28
18:01:24.661216 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 445:473, ack 7, win 3650, options , length 28
18:01:24.661586 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 473:501, ack 7, win 3650, options , length 28
18:01:24.661663 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 501:528, ack 7, win 3650, options , length 27
18:01:24.661702 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 528:556, ack 7, win 3650, options , length 28
18:01:24.661771 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 556:583, ack 7, win 3650, options , length 27
18:01:24.661807 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 583:611, ack 7, win 3650, options , length 28
18:01:24.661837 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 583:611, ack 7, win 3650, options , length 28
18:01:25.255745 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 611:639, ack 7, win 3650, options , length 28
18:01:25.257262 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 639:666, ack 7, win 3650, options , length 27
18:01:25.258095 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 666:694, ack 7, win 3650, options , length 28
18:01:25.259566 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 694:722, ack 7, win 3650, options , length 28
18:01:25.261078 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 722:749, ack 7, win 3650, options , length 27
18:01:25.263096 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 749:777, ack 7, win 3650, options , length 28

暫無評(píng)論

walkor 2016-04-22

打賞

可能是業(yè)務(wù)邏輯問題，或者客戶端問題。我也只能是猜測，這種問題只能自己定位了，別人沒環(huán)境沒法定位的。
另外tcp不會(huì)丟包的。workerman也不會(huì)丟包。

暫無評(píng)論

surechina 2016-04-23

我想應(yīng)該是gateway的業(yè)務(wù)邏輯問題，tcp客戶端過來的數(shù)據(jù)一條不少，可是在轉(zhuǎn)發(fā)的時(shí)候，我先將tcp的包經(jīng)過了一輪判斷和封裝再send給websocket的客戶端，會(huì)不會(huì)應(yīng)為tcp發(fā)過來太快了，第一條還沒封裝好發(fā)給websocket的數(shù)據(jù)又接著來第二條，致使有的數(shù)據(jù)漏發(fā)？