TCP套接字停止接收数据直到关闭。

Question

我有个很奇怪的问题要把我逼疯。

我有一个Ruby服务器和一个Flash客户机(动作脚本3)。这是多人游戏。

问题是，所有的事情都是完美的，然后，突然，一个随机的玩家停止接收数据。当服务器因不活动而关闭连接时，大约20-60秒后，客户端将接收所有缓冲数据。

客户端使用XMLsocket检索数据，因此客户端接收数据的方式没有问题。

socket.addEventListener(Event.CONNECT, connectHandler);
function connectHandler(event)
{
    sendData(sess);
}

function sendData(dat)
{
    trace("SEND: " + dat);
    addDebugData("SEND: " + dat)
    if (socket.connected) {
        socket.send(dat);
    } else {
        addDebugData("SOCKET NOT CONNECTED")
    }
}

socket.addEventListener(DataEvent.DATA, dataHandler);
function dataHandler(e:DataEvent) {
    var data:String = e.data;
    workData(data);
}

服务器在每次写入后刷新数据，因此不存在刷新问题：

sock.write(data + DATAEOF)
sock.flush()

DATAEOF是空字符，因此客户端解析字符串。

当服务器接受新套接字时，它将sync设置为true，将TCP_NODELAY设置为true，将TCP_NODELAY设置为true：

newsock = serverSocket.accept
newsock.sync = true
newsock.setsockopt(Socket::IPPROTO_TCP, Socket::TCP_NODELAY, true)

这是我的研究：

信息:我每秒钟都会将netstat数据转储到一个文件中。

• 当客户端停止接收数据时，netstat显示套接字状态仍然是ESTABLISHED。
• 几秒钟后，发送队列将相应地增长到发送的数据。
• tcpflow显示数据包被发送了2次。
• 当服务器关闭套接字时，套接字状态将按预期更改为FIN_WAIT1。然后，tcpflow显示所有缓冲数据都被发送到客户端，但是客户机不接收数据。几秒钟后，netstat和tcpflow中的连接取消了对相同数据的发送，但这一次客户端接收数据，因此开始向服务器发送数据，服务器接收数据。但为时已晚..。服务器已关闭连接。

我不认为这是一个OS/网络问题，因为我已经从位于西班牙的VPS变成位于爱尔兰的亚马逊EC2，问题仍然存在。

我不认为这也是一个客户网络问题，因为它每天发生数十次，平均在线用户数量大约在45-55，每天有大约400个独立用户，所以这个比例非常高。

编辑：，我做了更多的研究。我已将服务器更改为C++。

当客户端停止发送数据时，服务器会在一段时间后收到“对等服务器重置连接”错误。在那一刻，tcpdump告诉我客户端发送了一个RST数据包，这可能是因为客户机关闭了连接，服务器试图读取，但是.为什么客户端关闭连接？我认为答案是，客户端不是关闭连接的那个，而是内核。以下是一些信息：http://scie.nti.st/2008/3/14/amazon-s3-and-connection-reset-by-peer

Basically, as I understand it, Linux kernels 2.6.17+ increased the maximum size of the TCP window/buffer, and this started to cause other gear to wig out, if it couldn’t handle sufficiently large TCP windows. The gear would reset the connection, and we see this as a “Connection reset by peer” message.

我遵循了这些步骤，现在似乎只有当客户端失去与internet的连接时，服务器才会关闭连接。

我要加上这个作为一个答案，这样人们就对此有了一点了解。

Answer 1

我认为答案是内核是关闭连接的内核。以下是一些信息：http://scie.nti.st/2008/3/14/amazon-s3-and-connection-reset-by-peer

Basically, as I understand it, Linux kernels 2.6.17+ increased the maximum size of the TCP window/buffer, and this started to cause other gear to wig out, if it couldn’t handle sufficiently large TCP windows. The gear would reset the connection, and we see this as a “Connection reset by peer” message.

我遵循了这些步骤，现在似乎只有当客户端失去与internet的连接时，服务器才会关闭连接。