java - 发送紧急数据后 TCP 连接被重置

Question

我目前正在调试两个通过 TCP 连接交换数据的 Java 应用程序。

其中一个应用程序，即 TCP 客户端，通过调用 Socket#sendUrgentData(int) 定期向另一个应用程序 TCP 服务器发送紧急数据。 .第18次尝试发送紧急数据，TCP客户端抛出如下异常

java.io.IOException:BrokenPipe
    at java.net.PlainSocketImpl.socketSendUrgentData(Native Method)
    at java.net.PlainSocketImpl.sendUrgentData(PlainSocketImpl.java:541)
    at java.net.Socket.sendUrgentData(Socket.java:927)

TCP 服务器抛出这个异常

java.net.SocketException: Software caused connection abort: recv failed
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)

我相信异常是由尝试写入/读取已关闭的连接/套接字引起的。我不明白的是为什么连接或套接字在调用 sendUrgentData() 17 次后关闭。我能够重复它，它总是在 17 次之后发生。

如果我在 Windows 上运行客户端和服务器，就会出现问题。如果我在 Solaris 上运行客户端和服务器，则不会出现该问题。如果我在 Solaris 上运行客户端，在 Windows 上运行服务器，就会出现问题。如果我在 Windows 上运行客户端，在 Solaris 上运行服务器，则不会出现该问题。这让我觉得它可能与 Windows 相关？

使用 Wireshark 我在连接上看到以下流量

--> = from TCP client to TCP server
<-- = from TCP server to TCP client

-->  [PSH, ACK, URG] (Seq=1, Ack=1)
<--  [ACK] (Seq=1, Ack=2)
-->  [PSH, ACK, URG] (Seq=2, Ack=1)
<--  [ACK] (Seq=1, Ack=3)
...
-->  [PSH, ACK, URG] (Seq=17, Ack=1)
<--  [RST, ACK] (Seq=1, Ack=18)

我写了一些简单的测试类来显示这个问题。

TCPServer.java IP_Address 端口

public class TCPServer 
{
    public static void main(String[] args) throws Exception 
    {
        ServerSocket socket = new ServerSocket();
        socket.bind(new InetSocketAddress(args[0], Integer.parseInt(args[1])));
        System.out.println("BOUND/" + socket);
        Socket connection = socket.accept();
        System.out.println("CONNECTED/" + connection);
        int b;
        while ((b = connection.getInputStream().read()) != -1) {
            System.out.println("READ byte: " + b);
        }
        System.out.println("CLOSING ..");
        connection.close();
        socket.close();
}
}

TCPClient.java IP_Address Port Interval_Between_Urgent_Data

public class TCPClient 
{
    public static void main(String[] args) throws Exception 
    {
        final Socket socket = new Socket();
        socket.connect(new InetSocketAddress(InetAddress.getByName(args[0]), Integer.parseInt(args[1])));
        System.out.println("CONNECTED/"+socket);
        Timer urgentDataTimer = new Timer(true);
        urgentDataTimer.scheduleAtFixedRate(new TimerTask() 
        {       
            int n = 0;  
            public void run() {
                try {
                    System.out.println("SENDING URGENT DATA ("+(++n)+") ..");
                    socket.sendUrgentData(1);
                    System.out.println("SENT URGENT DATA");
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        }, 1000, Integer.parseInt(args[2]));

        int b;
        while ((b = socket.getInputStream().read()) != 1) {
            System.out.println("READ byte: " + b);
        }
        System.out.println("CLOSING ..");
        urgentDataTimer.cancel();
        socket.close();
    }
}

有人能解释一下这里发生了什么吗？

谢谢。

Answer 1

我假设您实际上正确地接收了发生故障的应用程序中的紧急数据，并且数据符合您的预期？

失败的原因有很多，特别是如果您在跨平台的情况下尝试这样做:在 TCP 中，关于紧急数据的工作方式有两种相互矛盾的描述，RFC 793其中详细说明 TCP 表示紧急指针指示紧急数据之后的字节，但是 RFC 1122更正了这一点并指出紧急指针指示紧急数据的最后一个字节。如果一个点使用 RFC 793 定义而另一个点使用 RFC 1122 定义，这会导致互操作性问题。

因此，首先确认您的应用程序确实获得了正确的紧急数据字节。是的，我说的是字节，因为 Windows 只支持单个字节的带外数据，所以兼容性更复杂，而 RFC 1122 指定 TCP 必须支持任何长度的紧急数据字节序列。 Windows 也没有指定如何或是否缓冲后续的带外数据，因此如果您在读取一个字节的紧急数据时速度很慢，而另一个字节的紧急数据到达，那么其中一个字节可能会丢失；尽管我们的测试表明 Windows 确实会缓冲紧急数据。这一切都使得使用紧急数据的带外信号的使用在带有 TCP 的 Windows 上有些不可靠。

如果您碰巧使用重叠 I/O，则会出现所有其他问题。

尽管是从 C++ 的角度来看，我已经对此进行了更深入的介绍，此处:http://www.serverframework.com/asynchronousevents/2011/10/out-of-band-data-and-overlapped-io.html