接收缓冲区的限制
我以这种方式与客户端建立了连接:
gen_tcp:listen(1234,[binary,{packet,0},{reuseaddr,true},{active,false},{recbuf,2048}]).
此代码执行消息处理:
loop(Socket)->
inet:setops(Socket,[{active,once}],
receive
{tcp,Socket,Data}->
handle(Data),
loop(Socket);
{Pid,Cmd}->
gen_tcp:send(Socket,Cmd),
loop(Socket);
{tcp_close,Socket}->
% ...
end.
我的操作系统是 Windows。当消息的大小为 1024 字节时,我会丢失 Data
中的字节。服务器向客户端发送ACK+FIN。
我相信Erlang限制为1024字节,因此我定义了recbuf
。
问题出在哪里:Erlang、Windows、硬件?
谢谢。
I established a connection with a client this way:
gen_tcp:listen(1234,[binary,{packet,0},{reuseaddr,true},{active,false},{recbuf,2048}]).
This code performs message processing:
loop(Socket)->
inet:setops(Socket,[{active,once}],
receive
{tcp,Socket,Data}->
handle(Data),
loop(Socket);
{Pid,Cmd}->
gen_tcp:send(Socket,Cmd),
loop(Socket);
{tcp_close,Socket}->
% ...
end.
My OS is Windows. When the size of the message is 1024 bytes, I lose bytes in Data
. The server sends ACK + FIN to the client.
I believe that the Erlang is limited to 1024 bytes, therefore I defined recbuf
.
Where the problem is: Erlang, Windows, hardware?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可能将接收缓冲区设置得太小。 Erlang 当然不限于 1024 字节缓冲区。您可以通过在 shell 中执行以下操作来自行检查:
在 Mac OS XI 上,获得大约 512Kb 的默认接收缓冲区大小。
通过
{packet, 0}
解析,您将收到网络堆栈选择发送的任何块中的 tcp 数据,因此您必须自己进行消息边界解析和缓冲。您是否有可靠的方法来检查有线协议中的消息边界?如果是这样,则接收 tcp 数据并将其附加到缓冲区变量,直到获得完整的消息。然后调用完整消息的句柄并从缓冲区中删除完整消息,然后再继续。如果您向我们提供有关客户端和所使用协议的一些信息,我们可能可以为您提供更多帮助。
You may be setting the receive buffer far too small. Erlang certainly isn't limited to a 1024 byte buffer. You can check for yourself by doing the following in the shell:
On Mac OS X I get a default receive buffer size of about 512Kb.
With
{packet, 0}
parsing, you'll receive tcp data in whatever chunks the network stack chooses to send it in, so you have to do message boundary parsing and buffering yourself. Do you have a reliable way to check message boundaries in the wire protocol? If so, receive the tcp data and append it to a buffer variable until you have a complete message. Then call handle on the complete message and remove the complete message from the buffer before continuing.We could probably help you more if you gave us some information on the client and the protocol in use.