Con los sockets de C TCP, ¿puede ''enviar'' devolver cero?
return-value send (5)
Bueno, siempre existe el caso en el que se pasa en cero como el número de bytes que se enviarán ... en ese caso, "devolver el número de bytes enviados" indicaría que debería devolver cero bytes.
Probablemente sea mejor manejar el caso de devoluciones-cero adecuadamente de todos modos; No puede doler, y podría ayudar.
¿Es posible que la función de send C devuelva cero cuando se usan sockets TCP? La página de manual solo dice que devolverá el número de bytes enviados, pero no estoy seguro de que devolverá -1 cuando no pueda enviar ningún dato.
Estoy bastante seguro, aunque la memoria está muy arraigada en el tiempo, que lo he visto regresar a cero antes, en la situación de transferencias masivas de datos donde el otro extremo no estaba al día.
De la memoria, en ese caso, los buffers de la pila TCP remota se habían llenado, el stack había notificado al extremo local que se iba a demorar hasta que se despejara algo de espacio y los buffers locales también se hubieran llenado.
En ese momento, no es técnicamente un error (por lo tanto, no se devuelve -1), pero la pila local no puede aceptar datos.
No estoy completamente seguro de que ese sea el caso ahora, ya que el estándar Posix actual parece indicar que simplemente se bloqueará en ese caso (o fallará si está configurado para no bloquear).
Sin embargo, sospecho que es un punto discutible. Tiene la posibilidad de que devuelva menos que los bytes que solicitó enviar y, por lo tanto, debe tener un código para manejar eso.
Y, dado que será más o menos el mismo manejo lógico ''uno menos de lo que solicitó'' como manejo ''cero bytes'', también puede suponer que puede devolver cero.
La página del manual de BSD dice:
Si no hay espacio disponible para mensajes en el socket para retener el mensaje que se va a transmitir, entonces send () normalmente se bloquea, a menos que el socket se haya colocado en modo de E / S sin bloqueo.
La especificación de Posix va más allá y establece que, en el modo de bloqueo, todos los datos se transfieren, a menos que se produzca una interrupción.
En ambos casos, no se puede devolver cero a menos que el recuento suministrado sea cero.
La respuesta a esto puede depender de la implementación y, por lo tanto, variar según el sistema operativo.
Una circunstancia en la que se esperaría 0, cuando se solicita una transmisión de 0 bytes.
AF_UNIX un retorno de cero desde el send(2) en un AF_UNIX tipo AF_UNIX este momento.
Yepp, se debió al campo de size de valor cero.
Entonces, JFYI.