We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
分隔符解码器中maxFrameSize默认是8192,如果接收数据的速度大于解码数据的速度,那么肯定就会在某一时刻出现超出maxFrameSize的情况,这时您的操作是断开连接,但是与此同时没有对_receiveDataBuffer里的数据进行及时的解码处理,那么下次重新连接成功后,_receiveDataBuffer里的数据就只能丢弃,这不符合长连接保证数据的准确性原则。如果解码的时候每次都从缓存中取出固定大小(比如maxFrameSize)解码,给_receiveDataBuffer缓存池设置一个最大的size,超出size后断开连接,但是解码工作一直继续,直到_receiveDataBuffer为空,会不会更好一些?
The text was updated successfully, but these errors were encountered:
赞,理解的好透彻啊,这里确实是有这个问题,我抽时间调整更新一下。
Sorry, something went wrong.
搭个车... 想邀请Repo作者来w3c.group创建项目的对应小组。w3c.group是类似知识星球的社群工具,小组可设置为付费且有赞助功能,同时也是一个区块链主导的创作者社区。这是相关介绍: http://t.cn/Ai1vLcCU http://t.cn/Ai1vLcCG http://t.cn/Ai1vLcCA
No branches or pull requests
分隔符解码器中maxFrameSize默认是8192,如果接收数据的速度大于解码数据的速度,那么肯定就会在某一时刻出现超出maxFrameSize的情况,这时您的操作是断开连接,但是与此同时没有对_receiveDataBuffer里的数据进行及时的解码处理,那么下次重新连接成功后,_receiveDataBuffer里的数据就只能丢弃,这不符合长连接保证数据的准确性原则。如果解码的时候每次都从缓存中取出固定大小(比如maxFrameSize)解码,给_receiveDataBuffer缓存池设置一个最大的size,超出size后断开连接,但是解码工作一直继续,直到_receiveDataBuffer为空,会不会更好一些?
The text was updated successfully, but these errors were encountered: