Hay soluciones viejas que usan ese patrón, pero son de antes de estandarizar la API del curso (o están equivocadas).
Ahora, el enviar de TCP está alineado al comportamiento real de TCP, por lo que al invocar el send no hay ninguna garantía sobre la cantidad de bytes que van a ser exitosamente cursados. Por lo tanto, asumir que todo el mensaje pasa porque es "corto" se consideran como un error.
El caso de los sockets bloqueantes es más sutil, y probablemente necesite una aclaración en la API. La documentación dice que:
- el settimeout fija el tiempo disponible para la operación, y que si se pasa un número negativo ese tiempo es infinito
- el send envía todo lo que puede en el tiempo disponible, pero eso no implica que puede pasar algo de tamaño arbitrario. En una implementación real, el tamaño mñaximo que el send puede pasar por invocación está limitado por el tamaño de buffers internos del SO para TCP, típicamente de algunos KB. O sea que si haces send de un string de 1MB con un socket completamente bloqueante, igualmente va hacer escrituras parciales del tamaño de este buffer.