Cómo cancelar el socket BeginReceive()?

Question

Naturalmente, BeginReceive() nunca terminará si no hay datos. MSDN suggests que llamando al Close() abortaría BeginReceive().

Sin embargo, llamando Close() en el zócalo también realiza una Dispose() en él, tal como figuraba en this great ansewr, y por lo tanto EndReceive() lanzaría una excepción porque el objeto ya está dispuesto (y lo hace!).

¿Cómo debo proceder?

Answer 1

Parece que esto es por (el muy tonto) diseño. Debe tener esta excepción lanzada y atrapada en su código.

MSDN ve silencio al respecto en efecto, pero si nos fijamos en la documentación de otro método de toma asíncrono, BeginConnect(), esto es lo que encontramos:

Para cancelar una llamada en espera a la BeginConnect método(), cierre el conector . Cuando se llama al método Close() mientras se está llevando a cabo una operación asíncrona , la devolución de llamada proporcionada al método BeginConnect() es llamada. Una llamada posterior al método EndConnect (IAsyncResult) dará arrojar una excepción ObjectDisposed a indicando que la operación ha sido cancelada.

Si es la forma correcta de hacer para BeginConnect, probablemente sea así también para BeginReceive. Este es sin duda un diseño deficiente por parte de la API asíncrona de Microsoft, porque hacer que el usuario tire necesariamente y atrape la excepción como parte de un flujo normal molestaría al depurador. Realmente no tiene forma de "esperar" hasta que se complete la operación, porque Close() es lo que la completa en primer lugar.

Answer 2

Otra solución sería enviar "usted mismo" un "mensaje de control" utilizando un socket conectado a un puerto diferente. No es exactamente un aborto, pero pondría fin a su operación asincrónica.

Answer 3

Tuve problemas con esto también, pero hasta donde puedo decir usando un indicador booleano simple antes de llamar al .BeginReceive() también funcionará (por lo que no será necesario el manejo de excepciones). Como ya tenía el manejo de inicio/detención, esta solución era una cuestión de una sola declaración if (desplácese hacia abajo hasta la parte inferior del método OnReceive()).

if (_running) 
{ 
    _mainSocket.BeginReceive(_data, 0, _data.Length, SocketFlags.None, OnReceive, null); 
}     

Debería haber pasado por alto algo con este enfoque, hágamelo saber!

Answer 4

Estoy sorprendido de que nadie haya recomendado usar SocketOptions.

Una vez que la pila tiene la operación de envío o recepción, está sujeta a las opciones de socket del socket.

Utilice un tiempo de espera de envío o recepción pequeño y utilícelo antes de la operación para que no le importe si se cambió durante la misma operación a algo más corto o más largo.

Esto causará más cambio de contexto pero no requerirá cerrar el socket bajo ningún protocolo.

Por ejemplo:

1) Establecer un pequeño tiempo de espera

2) Realizar operaciones

3) Ajuste de tiempo de espera más grande

Esto es similar al uso de bloqueo = false pero con una automática tiempo de espera que especifique.

Answer 5

Puede leer mi solución de este problema aquí (con comentario de Pavel Radzivilovsky aquí): UdpClient.ReceiveAsync correct early termination

Answer 6

Para conexiones de socket TCP, puede utilizar la propiedad Connected para determinar el estado de la toma de corriente antes de intentar acceder cualquier método eliminado Por MSDN:

"La propiedad Connected obtiene el estado de conexión del Socket a partir de la última operación de E/S. Cuando devuelve false, el Socket nunca se conectó o ya no está conectado."

Dado que dice "ya no está conectado" implica que se llamó previamente a Close() en el socket. Si comprueba si el socket está Conectado al inicio de la devolución de llamada de recepción, no habrá excepción.