Solución:
Puede tomar tiempo para que se observe el cierre de la red; el tiempo total es nominalmente de aproximadamente 2 minutos (¡sí, minutos!) Después de un cierre antes de que se asuma que todos los paquetes destinados al puerto están muertos. La condición de error se detecta en algún momento. Con una pequeña escritura, está dentro de la MTU del sistema, por lo que el mensaje se pone en cola para su envío. Con una escritura grande, eres más grande que la 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.
El estado actual de un socket está determinado por la actividad de “mantener vivo”. En su caso, esto es posible que cuando esté emitiendo el send llama a keep-alive La actividad dice que el socket está activo y, por lo tanto, el send La llamada escribirá los datos requeridos (40 bytes) en el búfer y regresará sin dar ningún error.
Cuando está enviando una porción más grande, la llamada de envío entra en estado de bloqueo.
La página de manual de envío también confirma esto:
Cuando el mensaje no encaja en el búfer de envío del conector, send () normalmente se bloquea, a menos que el conector se haya colocado en modo de E / S sin bloqueo. En modo sin bloqueo devolvería EAGAIN en este caso
Por lo tanto, mientras se bloquea el búfer libre disponible, si se notifica a la persona que llama (mediante el mecanismo de mantener vivo) 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.
¿Quizás los 40 bytes quepan en el búfer de la tubería y los 40000 bytes no?
Editar:
El proceso de envío recibe 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 búfer de tubería en esto. Es posible que pueda recuperarse capturando la señal con la llamada sigaction.