blocks|key|580295|text|这似乎是由(非常愚蠢的)设计的。您必须在代码中抛出并捕获此异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|580296|MSDN看起来确实对此保持沉默，但如果你查看另一个异步套接字方法BeginConnect()的文档，我们会发现：|offset|length|580297|580298|若要取消对BeginConnect()方法的挂起调用，请关闭套接字。当异步操作正在进行时调用Close()方法时，将调用提供给BeginConnect()方法的回调。随后对EndConnect(IAsyncResult)方法的调用将抛出一个ObjectDisposedException，以指示操作已被取消。|blockquote|580299|580300|580301|如果这对BeginConnect来说是正确的方式，那么对BeginReceive来说也是如此。对于微软的异步API来说，这肯定是一个糟糕的设计，因为让用户作为正常流程的一部分抛出和捕获异常将会惹恼调试器。您实际上没有办法“等待”到操作完成，因为Close()是首先完成它的。|580302|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/tad07yt6.aspx^0|0|W|E|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|-4|5|6|7|10|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|11|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|14|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|O|$P|$5|Q|R|S|A|$T|U]]]]

It seems like this is by (the very dumb) design. You must have this exception thrown and caught in your code. 

MSDN looks silent about it indeed, but if you look at the documentation of another asynchronous socket method, <a href="http://msdn.microsoft.com/en-us/library/tad07yt6.aspx" rel="noreferrer">BeginConnect()</a>, here's what we find:

<blockquote>
 To cancel a pending call to the
 BeginConnect() method, close the
 Socket. When the Close() method is
 called while an asynchronous operation
 is in progress, the callback provided
 to the BeginConnect() method is
 called. A subsequent call to the
 EndConnect(IAsyncResult) method will
 throw an ObjectDisposedException to
 indicate that the operation has been
 cancelled.
</blockquote>

If it is the proper way of doing for BeginConnect, it is probably so for BeginReceive as well. This is certainly a poor design on the part of Microsoft's async API, because making the user necessarily throw and catch exception as a part of a normal flow would annoy the debugger. You have really no way to "wait" until the operation is completed, because Close() is what completes it in the first place.

blocks|key|1642001|text|我很惊讶没有人推荐使用SocketOptions。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1642002|一旦堆栈有了发送或接收操作，它就被套接字的套接字选项绑定。|1642003|使用一个较小的发送或接收超时，并在操作之前使用它，这样您就不会关心它在同一操作期间是否被更改为更短或更长的超时。|1642004|这将导致更多的上下文切换，但在任何协议下都不需要关闭套接字。|1642005|例如：|1642006|1)设置较小的超时|1642007|2)执行操作|1642008|3)设置更大的超时|1642009|这类似于使用Blocking+=+false，但使用您指定的自动超时。|1642010|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|10|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|11|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|S|$]]

I am surprised no one recommended using SocketOptions.

Once the stack has the send or receive operation it is bound by the socket options of the socket. 

Use a small send or receive timeout and use it before the operation so you don't care if it's changed during that same operation to something shorter or longer. 

This will cause more context switching but will not require closing the socket under any protocol. 

For example:

1) Set a small timeout

2) Perform operations

3) Set timeout larger

This is similar to using Blocking = false but with an automatic timeout that you specify.

blocks|key|1642019|text|你可以在这里阅读我对这个问题的解决方案(在这里使用Pavel+Radzivilovsky的评论)：UdpClient.ReceiveAsync+correct+early+termination|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1642020|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/41019997/udpclient-receiveasync-correct-early-termination/41041601?noredirect=1#comment69291144_41041601^0|1D|1C|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You can read my solution of this problem here(using comment of Pavel Radzivilovsky here):
<a href="https://stackoverflow.com/questions/41019997/udpclient-receiveasync-correct-early-termination/41041601?noredirect=1#comment69291144_41041601">UdpClient.ReceiveAsync correct early termination</a>

blocks|key|580508|text|对于TCP套接字连接，在尝试访问任何已释放的方法之前，可以使用Connected属性确定套接字的状态。每个MSDN：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|580509|connected属性获取上一次I/O操作时套接字的连接状态。当它返回false时，套接字要么从未连接过，要么不再连接。|580510|因为它显示“不再连接”，这意味着之前在套接字上调用了Close()。如果在接收回调开始时检查套接字是否连接，则不会出现异常。|580511|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.connected?f1url=https://msdn.microsoft.com/query/dev15.query?appId=Dev15IDEF1&l=EN-US&k=k(System.Net.Sockets.Socket.Connected);k(TargetFrameworkMoniker-.NETFramework,Version=v4.7);k(DevLang-csharp)&rd=true&view=netframework-4.7^0|V|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

For TCP socket connections, you can use the <a href="https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.socket.connected?f1url=https%3A%2F%2Fmsdn.microsoft.com%2Fquery%2Fdev15.query%3FappId%3DDev15IDEF1%26l%3DEN-US%26k%3Dk(System.Net.Sockets.Socket.Connected);k(TargetFrameworkMoniker-.NETFramework,Version%3Dv4.7);k(DevLang-csharp)%26rd%3Dtrue&amp;view=netframework-4.7" rel="nofollow noreferrer">Connected</a> property to determine the state of the socket before trying to access any disposed methods. Per MSDN:

"The Connected property gets the connection state of the Socket as of the last I/O operation. When it returns false, the Socket was either never connected, or is no longer connected."

Since it says "no longer connected" it implies that a Close() was previously called on the socket. If you check whether the socket is Connected at the start of the receive callback, there will be no exception.

blocks|key|580546|text|在ReceiveCallback中，我检查了try块中的client.Connected。现在，当在BeginReceive之后接收到数据时，我可以调用client.Close()；这样，我看不到异常。我每隔200mS发送一次modbus-TCP请求，并及时得到响应。控制台输出看起来很干净。我使用了一个windows窗体应用程序来测试这一点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|580547|++++private+static+void+ReceiveCallback(IAsyncResult+ar)
++++{
++++++++try
++++++++{
++++++++++++//+Retrieve+the+state+object+and+the+client+socket
++++++++++++//+from+the+asynchronous+state+object.++
++++++++++++StateObject+state+=+(StateObject)ar.AsyncState;
++++++++++++Socket+client+=+state.workSocket;
++++++++++++if+(client.Connected)
++++++++++++{
++++++++++++++++//+Read+data+from+the+remote+device.++
++++++++++++++++state.dataSize+=+client.EndReceive(ar);
++++++++++++++++if+(state.dataSize+>+0)
++++++++++++++++{
++++++++++++++++++++Console.WriteLine("Received:+"+%2B+state.dataSize.ToString()+%2B+"+bytes+from+server");
++++++++++++++++++++//+There+might+be+more+data,+so+store+the+data+received+so+far.++
++++++++++++++++++++state.sb.Append(Encoding.ASCII.GetString(state.buffer,+0,+state.dataSize));
++++++++++++++++++++//++Get+the+rest+of+the+data.++
++++++++++++++++++++client.BeginReceive(state.buffer,+0,+StateObject.BUFFER_SIZE,+0,
++++++++++++++++++++++++new+AsyncCallback(ReceiveCallback),+state);

++++++++++++++++++++state.dataSizeReceived+=+true;+++++++++++//received+data+size?

++++++++++++++++++++dataSize+=+state.dataSize;
++++++++++++++++++++buffer+=+state.buffer.ToArray();
++++++++++++++++++++dataSizeReceived+=+state.dataSizeReceived;

++++++++++++++++++++string+hex+=+ByteArrayToString(state.buffer,+state.dataSize);
++++++++++++++++++++Console.WriteLine("<-+"+%2B+hex);

++++++++++++++++++++receiveDone.Set();
++++++++++++++++++++client.Close();
++++++++++++++++}
++++++++++++++++else
++++++++++++++++{
++++++++++++++++++++Console.WriteLine("All+the+data+has+arrived");
++++++++++++++++++++//+All+the+data+has+arrived;+put+it+in+response.++
++++++++++++++++++++if+(state.sb.Length+>+1)
++++++++++++++++++++{
++++++++++++++++++++++++Console.WriteLine("Length:+"+%2B+state.sb.Length.ToString());
++++++++++++++++++++}
++++++++++++++++++++//+Signal+that+all+bytes+have+been+received.++
++++++++++++++++++++receiveDone.Set();
++++++++++++++++}
++++++++++++}
++++++++}
++++++++catch+(Exception+e)
++++++++{
++++++++++++Console.WriteLine(e.ToString());
++++++++}
++++}|code-block|syntax|javascript|580548|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

In the ReceiveCallback I checked client.Connected within the try block.
Now, when data is received after BeginReceive, I can call client.Close();
This way, I do not see exceptions. I send modbus-TCP requests every 200mS, and get responses in time. The console output looks clean. I used a windows forms app, to test this.

<pre><code> private static void ReceiveCallback(IAsyncResult ar)
 {
 try
 {
 // Retrieve the state object and the client socket
 // from the asynchronous state object. 
 StateObject state = (StateObject)ar.AsyncState;
 Socket client = state.workSocket;
 if (client.Connected)
 {
 // Read data from the remote device. 
 state.dataSize = client.EndReceive(ar);
 if (state.dataSize &gt; 0)
 {
 Console.WriteLine("Received: " + state.dataSize.ToString() + " bytes from server");
 // There might be more data, so store the data received so far. 
 state.sb.Append(Encoding.ASCII.GetString(state.buffer, 0, state.dataSize));
 // Get the rest of the data. 
 client.BeginReceive(state.buffer, 0, StateObject.BUFFER_SIZE, 0,
 new AsyncCallback(ReceiveCallback), state);

 state.dataSizeReceived = true; //received data size?

 dataSize = state.dataSize;
 buffer = state.buffer.ToArray();
 dataSizeReceived = state.dataSizeReceived;

 string hex = ByteArrayToString(state.buffer, state.dataSize);
 Console.WriteLine("&lt;- " + hex);

 receiveDone.Set();
 client.Close();
 }
 else
 {
 Console.WriteLine("All the data has arrived");
 // All the data has arrived; put it in response. 
 if (state.sb.Length &gt; 1)
 {
 Console.WriteLine("Length: " + state.sb.Length.ToString());
 }
 // Signal that all bytes have been received. 
 receiveDone.Set();
 }
 }
 }
 catch (Exception e)
 {
 Console.WriteLine(e.ToString());
 }
 }
</code></pre>

blocks|key|2646994|text|另一种解决方案是使用绑定到不同端口的套接字向“您自己”发送“控制消息”。这不完全是一个中止，但它会结束你的异步操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2646995|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Another solution would be to send "yourself" a "control message" using a socket bound to a different port. It's not exactly an abort, but it would end your async operation.

blocks|key|4249814|text|我也在努力解决这个问题，但据我所知，在调用.BeginReceive()之前使用一个简单的布尔标志也可以(所以不需要异常处理)。因为我已经有了启动/停止处理，所以这个修复只需要一条if语句(向下滚动到OnReceive()方法的底部)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4249815|if+(_running)
{
++++_mainSocket.BeginReceive(_data,+0,+_data.Length,+SocketFlags.None,+OnReceive,+null);
}++++++++++++++++|code-block|syntax|javascript|4249816|如果我用这种方法忽略了什么，请让我知道！|4249817|entityMap^0|L|F|2I|2|2S|B|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|V|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|W|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|N|$]]

I was struggling with this as well but as far as I can tell using a simple boolean flag before calling <code>.BeginReceive()</code> will work as well (so there'll be no need for exception handling). Since I already had start/stop handling, this fix was a matter of one <code>if</code> statement (scroll down to the bottom of the <code>OnReceive()</code> method).

<pre><code>if (_running)
{
 _mainSocket.BeginReceive(_data, 0, _data.Length, SocketFlags.None, OnReceive, null);
} 
</code></pre>

Should I have overlooked something with this approach, let me know!

Naturally, <code>BeginReceive()</code> will never end if there's no data.
MSDN <a href="http://msdn.microsoft.com/en-us/library/dxkwh6zw.aspx" rel="nofollow noreferrer">suggests</a> that calling <code>Close()</code> would abort <code>BeginReceive()</code>.
However, calling <code>Close()</code> on the socket also performs a <code>Dispose()</code> on it, as figured out in <a href="https://stackoverflow.com/questions/3601521/c-socket-close-should-i-still-call-dispose/3601548#3601548">this great answer</a>, and consequently <code>EndReceive()</code> would throw an exception because the object is already disposed (and it does!).
How should I proceed?

How to abort socket's BeginReceive()?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

当然，如果没有数据，BeginReceive()永远不会结束。MSDN 表示调用Close()将中止BeginReceive()。但是，在套接字上调用Close()还会对其执行Dispose()，如中所述，因此EndReceive()将抛出异常，因为该对象已经被释放(它确实释放了！)。我应该如何继续？

问如何中止套接字的BeginReceive()？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何中止套接字的BeginReceive()？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何中止套接字的BeginReceive()？
EN