TcpClient读/写超时不会超时 [英] TcpClient read/write timeouts do not timeout

查看:314
本文介绍了TcpClient读/写超时不会超时的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个TcpClient。我将读/写超时设置为1分钟(

毫秒)。我从中获得了一个NetworkStream并确认超时

仍然存在。我做一个NetworkStream.Write(),然后是一个

NetworkStream.Read()。有时它会坐下来等待 - 在写()

或Read() - 15分钟之后我厌倦了并关闭

应用程序... ..


我没有连接到TcpListener。我使用ProtocolType.Tcp连接到Socket

,这是可以接受的。这些读/写

通常可以工作,但是当我得到3或4个TcpClients同时连接在

时,连接问题就开始了。我不明白为什么有些连接失败了。并且,当它们失败时,为什么不是超时

工作?


我相信我的服务器中有一个错误,但仍然是超时应该是b $ b超时。

解决方案

2008年7月21日星期一08:11:48 -0700,Zytan< zy**********@gmail.com写道:


[...]

我相信我有一个服务器中的错误,但是,超时应该是
超时。



很难说没有看到一个实际的简洁但完整的代码示例。

那说,你的描述不是全部清楚。你有/ b $ b读/写问题或连接问题?一段说明

前者,而另一段称后者。


小心使用TCP超时:一旦超时发生,套接字不是

更长的可用时间。根据你的意图,你最好在其他地方实现超时逻辑。


Pete


< blockquote>(似乎我的回复没有出现,所以我会再写一次:)


很难说没有看到实际的简洁但完整的代码示例。



我使用此示例中的代码:
http://msdn.microsoft.com/en-us/libr...tcpclient.aspx

(除了我实现超时。)


你有/ b $ b读/写问题或连接问题?



连接正常。服务器看到连接。客户端得到了
卡在stream.Write()调用中,服务器从未看到任何数据

。 (这个时间是1%。其他99%,一切正常

罚款。)


谨防使用TCP超时:一旦发生超时,套接字就没有了b / b
更长的可用时间。



好​​的。


根据你的意图,你可能会更好/>
自己在其他地方实现超时逻辑。



实现是:1。连接,2。发送数据,3。得到回复,4。

断开连接,所以TcpClient看起来像答案,因为它是同步的,就像我想要的那样,以避免

异步代码的麻烦。


我甚至在stream.Write()挂断后将服务器关闭,以便

看看是否会结束stream.Write()调用......而且它没有。

Write()应该结束,因为没有服务器,因为超时

是1分钟,现在已经20分钟了。即使我的服务器代码是一堆乱七八糟的错误,这也没有意义。

谢谢,皮特,


Zytan


我想我已经确定地表明.NET已经被炒掉了,或者

其他东西导致了这个问题(即我)。而且我想我可能已经找到它了......所以,等等......在你浪费时间阅读我之前

回复....... 。


Zytan


I have a TcpClient. I set the read/write timeouts at 1 minute (in
milliseconds). I get a NetworkStream from it and confirm the timeouts
still exist. I do a NetworkStream.Write() and then a
NetworkStream.Read(). Sometimes it sits and waits -- on the Write()
or the Read() -- for 15 minutes before I get fed up and close the
app.....

I am not connecting to a TcpListener. I am connecting to a Socket
with ProtocolType.Tcp, which is acceptable. These read/writes
normally work, but when I get 3 or 4 TcpClients all connecting at the
same time, connection problems start. I don''t understand why some of
the connections fail. And, when they do fail, why don''t the timeouts
work?

I believe I have a bug in the server, but still, the timeouts should
timeout.

解决方案

On Mon, 21 Jul 2008 08:11:48 -0700, Zytan <zy**********@gmail.comwrote:

[...]
I believe I have a bug in the server, but still, the timeouts should
timeout.

Hard to say without seeing an actual concise-but-complete code example.
That said, your description isn''t all that clear either. Are you having
read/write problems or connection problems? One paragraph says the
former, while another says the latter.

Beware of using the TCP timeout: once the timeout occurs, the socket is no
longer usable. Depending on your intent, you may be better off
implementing timeout logic yourself elsewhere.

Pete


(It appears my reply isn''t appearing, so I''ll write again:)

Hard to say without seeing an actual concise-but-complete code example.

I use the code from this example:
http://msdn.microsoft.com/en-us/libr...tcpclient.aspx
(except I implement timeouts.)

Are you having
read/write problems or connection problems?

It connects fine. The server sees the connection. The client gets
stuck in the stream.Write() call, and the server never sees any data
from it. (This occurs 1% o the time. The other 99%, everything works
fine.)

Beware of using the TCP timeout: once the timeout occurs, the socket is no
longer usable.

Ok.

Depending on your intent, you may be better off
implementing timeout logic yourself elsewhere.

The implementation is: 1. connect, 2. send data, 3. get reply, 4.
disconnect, so TcpClient seemed like the answer, since it was
synchronous, just as I wanted it to be, to avoid the hassle of
asynchronous code.

I even TURNED THE SERVER OFF once the stream.Write() got hung up, to
see if that would end the stream.Write() call... and it doesn''t.
Write() should end because there''s NO server and because the timeout
is 1 minute, and it''s been 20 minutes now. Even if my server code is
a mess of bugs, this makes no sense.
Thanks, Pete,

Zytan


I guess I''ve conclusively shown that either .NET is fried, or
something else is causing this issue (i.e. me). And I think I may
have found it.... so, hold up... before you waste your time reading my
replies........

Zytan


这篇关于TcpClient读/写超时不会超时的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆