¿ Habéis obtenido de forma intermitente el error 10053 en el proceso de depuración de vuestro código?
#### Exception System.Net.Sockets.SocketException – CLR_E_FAIL (1) ####
#### Message:
#### Microsoft.SPOT.Net.SocketNative::connect [IP: 0000] ####
#### System.Net.Sockets.Socket::Connect [IP: 001d] ####
#### Programa:Connect [IP: 0021] ####
#### Programa:funcion [IP: 0042] ####
#### Programa::Main [IP: 01b1] ####
#### SocketException ErrorCode = 10053
#### SocketException ErrorCode = 10053
Excepción del tipo ‘System.Net.Sockets.SocketException’ en Microsoft.SPOT.Net.dll
#### SocketException ErrorCode = 10053
#### SocketException ErrorCode = 10053
Este post explora consejos para solucionar este error molesto: 10053 SocketException ,es decir «Con la conexión establecida fue abortado por el software en el equipo host»
Puede pasar al azar el error «SocketException 10053», pero éste no esta realmente vinculado a ninguna situación específica, aunque de facto pueda ocurrir con mayor facilidad cuando el servidor tarde más tiempo para responder a una solicitud (digamos unos 500 ms).
Puede de hecho ocurrir con un sólo 1 agente virtual en la parte «BeginRead» , pero también puede suceder durante «BeginWrite» también aunque el servidor no este cargado
Para rastrear el problema en la parte servidor podría usarse el WireShark con objeto de ver que la solicitud sea enviada al servidor (en este caso nunca obtuvo respuesta, saliendo SocketException en su lugar),pero también seria buena idea instalar Wireshark en el servidor remoto para ver si la solicitud llega al servidor
En casos puede llegar inmediatamente después de conseguir un paquete [RST, ACK] ),lo cual puede significar que el socket había sido cerrado del lado del servidor pero es extraña esta excepción pues no debería ser posible enviar datos en un socket cerrado ,(aunque lo sea a nivel de TCP, pero. NET debería lanza un error) pues e acuerdo con RFC se deberia obtener 0 bytes de BeginRead que es mucho más limpio que la obtención de una excepción. Por tanto si el socket se ha cerrado ,la máquina anfitrión debería detectarlo pues se puede ver que equipo servidor ha enviado [FIN, ACK] antes en el mismo canal TCP.
Así que aquí están, finalmente, la cuestión es ¿Cómo se puedo detectar que una conexión se ha cerrado en async E / S? (dado que Tuve ningún error al enviar los datos, sólo durante la lectura).
Aquí está el código fuente que obtenía dicho error:
public void StartReading (WebRequest petición) {
if (readBuffer == null)
readBuffer = new byte [ConfigManager.readBufferSize];
try {
request.ParentSocket.networkStream.BeginRead (readBuffer, 0, ConfigManager.readBufferSize, ReadAsyncCallback, petición);
} Catch (IOException ioe) {
Logger.LogError (nombre + «IOException en StartReading: BeginRead» + Request.Path);
ProcessIOException (request, OIE);
} Catch (Exception ex) {
throw new WAException («StartReading:» + ex.Message, ex);
}
}
AsyncReadHandler public void (IAsyncResult result) {
try {
WebRequest request = (WebRequest) result.AsyncState;
BytesRead int = 0;
try {
BytesRead = request.ParentSocket.networkStream.EndRead (resultado);
} Catch (IOException ioe) {
Logger.LogError («IOException Si bien la lectura (BytesRead =» + BytesRead + «) la respuesta a» + + Request.Path ioe.Message);
}
/ / Obtener 0 bytes mientras que la lectura mediante conexión se ha cerrado
if (BytesRead == 0) {
Logger.LogWarn (nombre + «> EndRead devuelve 0 bytes, petición =» + Request.Path + «, socket se ha cerrado, el envío de nuevo»);
RecreateSocketAndSend (petición);
volver;
}
} Catch (Exception ex) {
Logger.LogError (nombre + «> AsyncReadHandler: Excepción:» + ex.Message);
throw new WAException (nombre + «> AsyncReadHandler: Exception («. ex.Message + + «) Path =» + ((WebRequest) result.AsyncState) Path, ex);
}
}
Y aquí la solución: cambiar el socket en modo de no bloqueo y tratar de leer 0 bytes. Si se devuelve 0 bytes y SocketError = éxito entonces sé que ha cerrado Socket lado del servidor. Si la conexión está todavía activa entones SocketError = WouldBlock. Lo interesante es que en ambos casos los resultados son muy rápidos de obtener.
Otras solución podría ser confiando en los tiempos de espera pero esto es bastante lento, incluso cuando la conexión está todavía. Quizás la solución propuesta sea la forma rápida de detectar la desconexión limpia, pues esto no puede funcionar si el paqute «FIN, ACK» no se recibe por el cliente.
Aquí ID un pedazo de mi código, de ejemplo de como puede solucionarse :
bool previousMode = socket.Blocking;
socket.Client.Blocking = false;
SocketError se;
int BytesRead = socket.Receive (nuevo byte [0], 0, 0, SocketFlags.Peek, a sí mismo);
socket.Blocking = previousMode;
if ((SE == SocketError.Success) && (BytesRead == 0)) {
Logger.LogDebug («isConnected = false»);
}
Fuente en ingles aqui
Me gusta esto:
Me gusta Cargando...
Debe estar conectado para enviar un comentario.