La comunicación bidireccional con 1 enchufe - cómo hacer frente a las colisiones?

Question

Tengo una sola aplicación. que consiste en "Administrador" y "trabajador". Actualmente, el trabajador siempre inicia la conexión, le dice algo a la directora, y el director enviará la respuesta.

Dado que hay una gran cantidad de comunicación entre el gerente y el trabajador, estoy considerando la posibilidad de tener una toma abierta entre los dos y hacer la comunicación. También estoy esperando para iniciar la interacción de ambos lados - que permite al gerente para decir algo al trabajador siempre que quiera.

Sin embargo, estoy un poco confundido en cuanto a cómo hacer frente a "colisiones". Por ejemplo, el director decide decir algo al trabajador, y, al mismo tiempo que el trabajador decide decir algo con el gerente. ¿Lo que sucederá? ¿Cómo se debe manejar esta situación?

P.S. Voy a utilizar Netty para la implementación real.

Answer 1

"También estoy esperando para iniciar la interacción de ambos lados -. Que permite al gerente para decir algo al trabajador siempre que quiera"

Respuesta simple. no lo hacen.

Aprender de los protocolos existentes: un cliente y un servidor. Las cosas van a funcionar muy bien. Trabajador puede ser el servidor y el gestor puede ser un cliente. Manager puede hacer numerosas solicitudes. responde a las peticiones de los trabajadores a medida que llegan.

Peer-to-peer puede ser complejo sin valor real de la complejidad.

Answer 2

me gustaría ir para un canal bidireccional persistente entre el servidor y el cliente.

Si todo lo que tienes es un servidor y un cliente, entonces no hay problema de colisión ... Si el servidor acepta la conexión, se sabe que es el cliente y viceversa. Ambos pueden leer y escribir en el mismo socket.

Ahora, si tiene varios clientes y sus necesidades de servidor para enviar una petición específicamente para el cliente X, entonces usted necesita apretón de manos

Cuando se inicia un cliente, se conecta al servidor. Una vez establecida esta conexión, el propio cliente identifica como cliente X (el mensaje de negociación). El servidor ahora sabe que tiene una toma abierta al cliente X y cada vez que necesita para enviar un mensaje al cliente X, se vuelve a utilizar ese socket.

Qué suerte, acabo de escribir un tutorial (proyecto de ejemplo incluido) en este problema preciso. El uso de Netty! :)

Aquí está el enlace: http: // Bruno. linker45.eu/2010/07/15/handshaking-tutorial-with-netty/

Tenga en cuenta que en esta solución, el servidor no intento de conexión con el cliente. Es siempre el cliente que se conecta al servidor. Si estabas pensando en abrir un socket cada vez que desea enviar un mensaje, debe reconsiderar las conexiones persistentes, ya que evitan la sobrecarga de establecimiento de la conexión, en consecuencia, la aceleración de la velocidad de transferencia de datos N veces.

Answer 3

creo que necesita para leer sobre zócalos ....

No realmente da este tipo de problemas .... Aparte de cómo manejar responsablemente tanto en la recepción y envío, por lo general esto se hace a través de subprocesos en sus comunicaciones ... dependiendo de la aplicación que puede tomar una serie de enfoques a esto.

Answer 4

El enlace correcto a la tutorial Handshake / Netty mencionado en la respuesta de brunodecarvalho es http://bruno.factor45.org/blag/2010/07/15/handshaking-tutorial-with-netty/
Yo añadiría esto como un comentario a su pregunta, pero no tengo la mínima reputación necesaria para hacerlo.

Answer 5

Si tienes ganas de reinventar la rueda y no desea utilizar el middleware ...

El diseño de su protocolo para que las respuestas del otro por pares a sus peticiones siempre son fácilmente distinguibles de las peticiones de los otros pares. A continuación, elegir su estrategia de red de E / S con cuidado. Cualquier código que se encarga de leer de la toma debe determinar primero si los datos de entrada es una respuesta a los datos que se envían hacia fuera, o si se trata de una nueva solicitud de los pares (mirando a la cabecera de los datos, y si ha emitido una solicitud recientemente). Además, es necesario para mantener la puesta en cola adecuada para que al enviar las respuestas a las peticiones del otro extremo se separa adecuadamente de las nuevas solicitudes que emita.