java nio:如果read返回-1是否意味着客户端已关闭连接?
我有一个关于本教程的问题
http://rox-xmlrpc.sourceforge.net/niotut/< /a>
在服务器的 read 方法中,如果 read 返回 -1 那么是否总是意味着客户端已关闭连接?
我修改了示例客户端,使其在发送消息后休眠很长时间,我发现 selector.select() 不会阻塞并继续选择通道为可读,即使客户端没有发送任何内容并且服务器读取方法读取并返回 -1,从而关闭通道,但客户端并没有断开连接。
我不理解这种行为。有人可以帮我理解吗?
我正在尝试修改服务器,以便即使客户端没有发送任何内容,服务器也不会与客户端断开连接,因此它必须在selector.select()处阻塞。
谢谢你!
I have a question with reference to this tutorial
http://rox-xmlrpc.sourceforge.net/niotut/
In the read method of the server, if read returns -1 then does it always mean client has closed connection??
I modified the example client to sleep for long time after sending the message I see that the selector.select() does not block and keeps selecting the channel as readable even if client is not sending anything and server reads method reads and returns -1, and thus closes the channel, but the client has not disconnected.
I do not understand this behavior. Can some one help me understand?
I am trying to modify the server so that the server does not disconnect with client even if client is not sending anything and so it must block at selector.select().
thank you!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
![扫码二维码加入Web技术交流群](/public/img/jiaqun_03.jpg)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
API 应按描述工作。当套接字连接关闭时,Read 将返回 -1。这与“消息结束”不同。连接可以通过超时关闭,我注意到您说您让客户端等待“很长时间”。
我还注意到您正在按照特定的教程进行工作。该教程中的客户端代码在收到响应后专门关闭连接,并为每次发送打开一个新连接。您必须对客户端代码设计进行大量更改才能阻止这种情况。
当我使用不关闭连接的客户端运行该教程中的 nio 服务器时,其行为正如 API 所描述的那样 - 服务器线程在 Selector.select() 中等待,而客户端在发送消息之间休眠。
因此,我的答案是,您可能正在使用正在关闭连接的客户端,如果不是,您等待的“长时间”可能会导致网络为您关闭连接。鉴于您所描述的行为,我很确定是前者。
The API should work as described. Read will return -1 when the socket connection is closed. This is not the same as "end of message". A connection can be closed by a time-out and I note that you said you had the client wait for "a long time".
I also note that you are working from a specific tutorial. The client code in that tutorial specifically closes the connection after receiving a response and opens a new one for every send. You would have to make large changes to the client code design to stop this.
When I run the nio server from that tutorial with a client that does not close the connection, the behaviour is as the API describes - the server thread waits in Selector.select() whilst the client sleeps between sending messages.
My answer is hence that you are probably using a client that is closing connections, and if not the "long time" you are waiting could cause the network to close the connections for you. Given the behaviour you describe I am pretty sure it is the former.
是的。总是。
是的,确实如此。这就是它的意思。客户端已关闭连接。
Yes. Always.
Yes it has. That's what it means. The client has closed the connection.
我想 - 但我不太确定,因为我没有完全阅读它 - 你无法区分端口连接和套接字连接。据我了解,连接是通过特定端口上的套接字打开的。套接字可以分别关闭。收到发送的消息的结尾 - 但连接仍然可以保持。
据我了解,-1 表示通过套接字连接发送的消息结束。没有明确的指示器可以直接告诉您连接已关闭......您必须自己发明它。 (我的2美分理解。)
I guess - but I am not really sure, cause I didn't read it completely - you fail in the distinction between Port-connection and Socket-connection. To my understanding the connection is opened via a socket on a specific port. The socket could be closed resp. received the end of the message which was sent - but the connection could still remain.
To my understanding -1 indicates the end of the messages sent via the socket-connection. There is no clear indicator which tells you directly the connection is closed.... You have to invent it by yourself. (My 2cents of understanding.)