java套接字/输出流写入:它们会阻塞吗? [英] java socket / output stream writes : do they block?

问题描述

如果我只是在输出流上写入套接字，它会阻塞吗?只有读取可以阻塞，对吗?有人告诉我写入可以阻塞，但我只看到套接字读取方法的超时功能 - Socket.setSoTimeout().

If I am only WRITING to a socket on an output stream, will it ever block? Only reads can block, right? Someone told me writes can block but I only see a timeout feature for the read method of a socket - Socket.setSoTimeout().

我认为写入可能会阻塞是没有意义的.

It doesn't make sense to me that a write could block.

推荐答案

对 Socket 的写入也会阻塞，尤其是 TCP Socket.操作系统只会缓冲一定数量的未传输(或传输但未确认)的数据.如果您编写内容的速度比远程应用程序能够读取的速度快，则套接字最终会备份并且您的 write 调用将被阻塞.

A write on a Socket can block too, especially if it is a TCP Socket. The OS will only buffer a certain amount of untransmitted (or transmitted but unacknowledged) data. If you write stuff faster than the remote app is able to read it, the socket will eventually back up and your write calls will block.

回答这些后续问题:

那么有没有一种机制可以设置一个超时?我不确定是什么它应该有的行为......也许扔掉如果缓冲区已满，则数据?或者可能删除缓冲区中的旧数据?

So is there a mechanism to set a timeout for this? I'm not sure what behavior it'd have...maybe throw away data if buffers are full? Or possibly delete older data in the buffer?

没有在 java.net.Socket 上设置写入超时的机制.有一个 Socket.setSoTimeout() 方法，但它影响 accept() 和 read() 调用......而不是 write() 调用.显然，如果您使用 NIO、非阻塞模式和选择器，您可以获得写入超时，但这并不像您想象的那么有用.

There is no mechanism to set a write timeout on a java.net.Socket. There is a Socket.setSoTimeout() method, but it affects accept() and read() calls ... and not write() calls. Apparently, you can get write timeouts if you use NIO, non-blocking mode, and a Selector, but this is not as useful as you might imagine.

除非连接关闭，否则正确实现的 TCP 堆栈不会丢弃缓冲数据.但是，当您收到写入超时时，不确定当前在 OS 级缓冲区中的数据是否已被另一端接收......另一个问题是，您不知道上次 write 中有多少数据实际上传输到了操作系统级 TCP 堆栈缓冲区.缺少一些用于重新同步流的应用程序级协议^*，write 超时后唯一安全的做法是关闭连接.

A properly implemented TCP stack does not discard buffered data unless the connection is closed. However, when you get a write timeout, it is uncertain whether the data that is currently in the OS-level buffers has been received by the other end ... or not. The other problem is that you don't know how much of the data from your last write was actually transferred to OS-level TCP stack buffers. Absent some application level protocol for resyncing the stream^*, the only safe thing to do after a timeout on write is to shut down the connection.

相比之下，如果您使用 UDP 套接字，write() 调用不会阻塞很长时间.但不利的一面是，如果出现网络问题或远程应用程序跟不上，消息将被丢弃在地板上，而不会通知任何一端.此外，您可能会发现消息有时会乱序传送到远程应用程序.由您(开发者)来处理这些问题.

By contrast, if you use a UDP socket, write() calls won't block for any significant length of time. But the downside is that if there are network problems or the remote application is not keeping up, messages will be dropped on the floor with no notification to either end. In addition, you may find that messages are sometimes delivered to the remote application out of order. It will be up to you (the developer) to deal with these issues.

^{* 理论上可以这样做，但对于大多数应用程序来说，在已经可靠(在一定程度上)的 TCP/IP 流之上实现额外的重新同步机制是没有意义的.如果确实有意义，您还需要处理连接关闭的可能性......因此假设它关闭会更简单.}

^{* It is theoretically possible to do this, but for most applications it makes no sense to implement an additional resyncing mechanism on top of an already reliable (to a point) TCP/IP stream. And if it did make sense, you would also need to deal with the possibility that the connection closed ... so it would be simpler to assume it closed.}

这篇关于java套接字/输出流写入:它们会阻塞吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！