vcenter - vsphere web client 6.5 download
¿Qué causa el error Broken Pipe? (3)
Sé que se produce un error en la tubería rota cuando el zócalo en el lado del par está cerrado.
Pero, en mi prueba, he notado que una llamada de ''envío'' inmediata en este lado cuando el lado del par está cerrado no siempre conduce a un error de tubería roto.
P.ej:
Después de cerrar el socket en el lado de los pares (he intentado el cierre limpio llamando al cierre y también el cierre anormal matando al igual), si trato de enviar 40 bytes, entonces no obtengo una tubería rota, pero si intento envíe 40000 bytes y luego da error de tubería roto.
¿Qué causa exactamente la tubería rota y su comportamiento puede predecirse?
Puede tomar tiempo para que se observe la red cercana; el tiempo total es nominalmente de unos 2 minutos (¡sí, minutos!) Después de un cierre antes de que se asuma que los paquetes destinados al puerto están muertos. La condición de error se detecta en algún momento. Con una escritura pequeña, se encuentra dentro de la MTU del sistema, por lo que el mensaje se pone en cola para enviar. Con una gran escritura, usted es más grande que el MTU y el sistema detecta el problema más rápido. Si ignora la señal SIGPIPE, las funciones devolverán el error EPIPE en una tubería rota, en algún momento cuando se detecte la rotura de la conexión.
Tal vez los 40 bytes encajen en el buffer de la tubería, y los 40000 bytes no?
Editar:
El proceso de envío se envía una señal SIGPIPE cuando intenta escribir en una tubería cerrada. No sé exactamente cuándo se envía la señal, o qué efecto tiene el buffer de tubería en esto. Es posible que puedas recuperar atrapando la señal con la llamada sigaction.
El estado actual de un socket está determinado por la actividad ''keep-alive''. En su caso, es posible que cuando esté emitiendo la llamada de send , la actividad de keep-alive diga que el socket está activo y la llamada de send escribirá los datos requeridos (40 bytes) en el búfer y regresará sin dar ninguna error.
Cuando envía un fragmento más grande, la llamada de envío entra en estado de bloqueo.
La página enviar hombre también confirma esto:
Cuando el mensaje no encaja en el búfer de envío del zócalo, send () normalmente bloquea, a menos que el zócalo se haya colocado en modo de E / S sin bloqueo. En modo no bloqueante devolvería EAGAIN en este caso
Por lo tanto, al bloquear el búfer disponible de manera gratuita, si se le notifica a la persona que llama (mediante el mecanismo keep-alive) que el otro extremo ya no está presente, la llamada de envío fallará.
Predecir el escenario exacto es difícil con la información mencionada, pero creo que esta debería ser la razón de su problema.