在一个session中，一条读处理较慢的stream，可能饿死其他stream？

xtaci / smux

A Stream Multiplexing Library for golang with least memory usage(TDMA)

MIT License

1.31k stars 196 forks source link

在一个session中，一条读处理较慢的stream，可能饿死其他stream？ #18

Closed longzhiri closed 5 years ago

longzhiri commented 7 years ago

session中的所有stream共享一个读token，如果一个stream处理包慢，读包慢，很快耗尽session的读token，导致其他正常的stream读不出包处理了？看代码想到的问题，没有测试过，想确认是否存在这个问题。

xtaci commented 7 years ago

完全正确

cs8425 commented 7 years ago

自己嚕的TCP over TCP已踩到這問題... 改成每個stream一個token 加入2個控制封包: full, empty 這樣是否會比較好? 正在改寫中如果完成後沒問題會提交PR

xtaci commented 7 years ago

@cs8425 不清楚你说的每个stream一个token怎么实现，你又无法预知下一个strream id是什么的时候

cs8425 commented 7 years ago

@xtaci 目前大致構想是這樣的: 廢掉Session的token bucket Stream結構裡面加入token Session的recvLoop(), cmdPSH的時候檢查Stream的token(假設為A端) 不足的話傳送stream id + full到對面(假設為B端) block住B端那個stream id的Write 直到A端Read夠多的資料出來(token夠多了) A端傳送stream id + empty到B端讓B端的那個stream可以繼續Write 不知道這樣會不會有什麼問題就是

xtaci commented 7 years ago

这样stream越多，内存用量越大

cs8425 commented 7 years ago

是的理想情況下可能還需要一個機制來控制最大同時連線數不過理論上來說除非夠多的stream都很慢而且對面沒收到控制封包block住Write操作否則記憶體用量應該是可以接受的

xtaci commented 5 years ago

https://github.com/xtaci/smux/tree/v2