Reading the MSDN documentation for Socket.AcceptAsync I am still not entirely clear if there is a complimentary 'End' method.
So, in the case of BeginAccept() there is an EndAccept() method that completes t开发者_StackOverflow中文版he call and takes the IAsyncResult as a parameter, allowing the developer access to the Socket (via the IAsyncResult.AsyncState method). Calling EndAccept (or any other Endxxx method pair) internally cleans up some CLR allocated resources, as well as providing functionality to monitor if an asynchronous operation actually completed/errored etc.
All this leads me to the question of whether there is a need to call an End method following a call to AcceptAsync - or ReceiveAsync for that matter? Or are their End methods neatly wrapped up within the Async, perhaps as a Task and ContinueWith? Hence why a SocketAsyncEventArgs contains the Socket itself.
If anyone knows then brilliant! Many thanks!
No. There are no End method.
You should handle the Completed
event in the SocketAsyncEventArgs
. Also note that ReceiveAsync
etc can complete directly (and therefore not trigger the event).
Update
Hence why a SocketAsyncEventArgs contains the Socket itself.
It's because you should be able to handle IO operations for all clients in the same class. You also have a UserToken
property which can be used to store client specific information.
Or are their End methods neatly wrapped up within the Async, perhaps as a Task and ContinueWith
No. The new Async model are more like the "real" model (IO Completion ports) which are provided by Windows. The Begin/End kind of structure was introduced to make the asynchronous programming easier. The XxxxAsync model was created to get even better performance for those applications that need it (imho there are a few that will benefit from it, but it's really important for those)
精彩评论