我目前正在调试两个通过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端口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();
}
}
有人可以解释这里发生了什么吗？
谢谢。
最佳答案
我假设您实际上在故障应用程序中正确接收了紧急数据，并且这些数据符合您的预期？
失败的原因有很多，尤其是在跨平台的情况下尝试时:在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