java - socket - Cliente/servidor: ¿cómo separar el protocolo de la lógica de red?
como hacer un programa cliente servidor en java (1)
Quiero implementar y probar la unidad (no necesariamente TDD) una aplicación cliente que se comunica con un servidor TCP usando un protocolo de aplicación determinado.
He visto en lugares como aquí (1) y aquí (2) que el código de protocolo debe estar preferiblemente desacoplado del código de red para que cada uno de ellos pueda ser probado por separado.
Sin embargo, no entiendo cómo debería diseñar e implementar esas partes.
El primer enlace habla de una clase MyProtocolHandler con los métodos HelloMessage() y HowdyMessage() . ¿Eso significa que se espera que un manejador de protocolo tenga dos métodos para generar un mensaje y procesar la respuesta? ¿Cómo los usaré? Una cosa más, debería haber diferentes clases ProtocolHandler para cada par de mensaje / respuesta o solo una para todos ellos?
El segundo enlace habla de un Reader y un Writer . De nuevo, no puedo entender cómo debería usarlos.
Esos dos son solo ejemplos. La pregunta principal es, ¿cómo puedo desacoplar la lógica de la red y probarla en una unidad? Debo decir que aún no he intentado nada; Estoy acostumbrado a escribir solo código acoplado y no sé por dónde empezar.
Esas son formas diferentes de enfocar la tarea. La pila de red se diseña como diferentes capas en las que cada capa proporciona funcionalidades "bien definidas" a la capa superior y proporciona esas funcionalidades a través de API.
Entonces, si desea implementar su propio protocolo de capa de aplicación ejecutándose en TCP o también en SSL (que a su vez probablemente se ejecutará en TCP), usará la interfaz de socket. La forma en que diseñas esa parte es de la misma manera que diseñarías cualquier aplicación. En general, desea separar la lógica de su aplicación del protocolo, llámese A, lógica. Su protocolo A se encargará de enviar un mensaje al servidor usando sockets (escribir y leer), leer el mensaje del servidor, lidiar con tiempos de espera (por ejemplo, cuando se espera una respuesta del servidor que nunca llega), tratar con los errores del socket , formato de mensaje, análisis de mensaje, etc. El protocolo A ocultará todos esos problemas de su aplicación.
Su aplicación solo se ocupará de las funciones API provistas por su protocolo: al igual que HelloMessage, llamará a ese método y, dentro, HelloMessage se ocupará de los sockets, el formato del mensaje, etc.
Ahora su protocolo A puede implementarse solo con una clase o un conjunto de clases. Si se trata de un conjunto de clases, te recomiendo que las conviertas en parte del mismo paquete.
Para más información sobre cómo implementarlo, sugeriría dos opciones: 1) Usted tiene una clase Reader y Writer que son envoltorios de un socket. Luego, las clases de Protocolo utilizan estos lectores y escritores y puede probarlo sin tener una red con un lector y escritor secundario que no use sockets. 2) Esto es más complejo, puede tener una clase de comunicación que podría recibir mensajes para enviar a través de una cola de mensajes y también puede enviar mensajes recibidos utilizando otra cola de mensajes. La clase de Comunicación sabe cómo tratar con conexiones o zócalos (según el nivel de abstracción). Sabe cómo abrir conexiones, manejar tiempos de espera, etc. Este es un mejor diseño pero demasiado complejo.
Espero que esto ayude.