sockaddr_in - sockets java
¿Son válidas las llamadas en paralelo para enviar/recv en el mismo zócalo? (3)
- ¿Podemos llamar a send desde un thread y recv desde otro en el mismo socket?
- ¿Podemos llamar múltiples envíos de forma paralela desde diferentes hilos en el mismo socket?
Sé que un buen diseño debería evitar esto, pero no tengo claro cómo se comportarán estas API del sistema. No puedo encontrar una buena documentación también para el mismo.
Cualquier sugerencia en la dirección será útil.
El descriptor de socket pertenece al proceso, no a un hilo en particular. Por lo tanto, es posible enviar / recibir desde / hacia el mismo socket en diferentes subprocesos, el SO manejará la sincronización.
Sin embargo, si el orden de envío / recepción es semánticamente significativo, usted mismo (o su código) debe garantizar la secuencia adecuada entre las operaciones en los diferentes hilos, como siempre ocurre con los hilos.
No veo cómo recibir en paralelo podría lograr algo. Si tiene un mensaje de 3 bytes, 1 hilo podría obtener los primeros 2 bytes y otro el último byte, pero no tendría forma de decir cuál fue cuál. A menos que sus mensajes sean solo de un byte, no hay manera de que pueda hacer que algo funcione de manera confiable con la recepción de múltiples hilos.
Múltiples envíos podrían funcionar, si envió el mensaje completo en una sola llamada, pero no estoy seguro. Es posible que uno pueda sobrescribir otro. Ciertamente no habría ningún beneficio en el rendimiento al hacerlo.
Si es necesario enviar varios subprocesos, debe implementar una cola de mensajes sincronizados. Tiene un hilo que hace el envío real que lee mensajes de la cola y tiene los otros hilos en cola mensajes enteros. Lo mismo funcionaría para recibir, pero el hilo de recepción debería conocer el formato de los mensajes para poder deserializarlos adecuadamente.
POSIX define send / recv como operaciones atómicas, por lo que, suponiendo que esté hablando de POSIX send / recv, entonces sí, puede llamarlos simultáneamente desde múltiples hilos y las cosas funcionarán.
Esto no significa necesariamente que se ejecutarán en paralelo: en el caso de envíos múltiples, el segundo bloqueará probablemente hasta que el primero se complete. Probablemente no se dará cuenta de esto, ya que un envío finaliza una vez que coloca sus datos en el búfer del zócalo.
Si está utilizando sockets SOCK_STREAM, es menos probable que intente hacer las cosas de forma paralela ya que send / recv podría enviar o recibir solo parte de un mensaje, lo que significa que las cosas podrían dividirse.
El bloqueo de envío / recepción en sockets SOCK_STREAM solo se bloquea hasta que envían o reciben al menos 1 byte, por lo que la diferencia entre bloqueo y no bloqueo no es útil.