java.net versus java.nio
networking (5)
¿En qué momento es mejor cambiar de java.net a java.nio? .net (no la entidad de Microsoft) es más fácil de entender y más familiar, mientras que nio es escalable y viene con algunas características extra ingeniosas.
Específicamente, tengo que hacer una elección para esta situación: tenemos un centro de control que administra el hardware en varios sitios remotos (cada sitio con una computadora administrando múltiples unidades de hardware (un transceptor, TNC y rotador)). Mi idea era tener una aplicación de corte en cada máquina que actúe como una puerta de acceso desde el centro de control al hardware de la radio, con un enchufe para cada unidad. Desde mi punto de vista, NIO está pensado para un servidor, muchos clientes, pero lo que estoy pensando es en un cliente, muchos servidores.
Supongo que una tercera opción es usar MINA, pero no estoy seguro si eso es tirar demasiado a un problema simple.
Cada servidor remoto tendrá hasta 8 conexiones, todas del mismo cliente (para controlar todo el hardware y los zócalos TX / RX separados). Sin embargo, el único cliente querrá conectarse a varios servidores a la vez. En lugar de poner cada servidor en diferentes puertos, ¿es posible usar los selectores de canales en el lado del cliente, o es mejor utilizar el io de subprocesos múltiples en el lado del cliente y configurar los servidores de forma diferente?
En realidad, dado que las máquinas remotas solo sirven para interactuar con otro hardware, ¿sería RMI o IDL / CORBA una mejor solución? Realmente, solo quiero poder enviar comandos y recibir telemetría desde el hardware, y no tener que inventar algún protocolo de capa de aplicación para hacerlo.
Dado el pequeño número de conexiones involucradas, java.net suena como la solución correcta.
Otros carteles hablaron sobre el uso de XML-RPC. Esta es una buena opción si los volúmenes de datos que se envían son pequeños, sin embargo, he tenido malas experiencias con protocolos basados en XML al escribir comunicaciones entre procesos que envían grandes cantidades de datos (por ejemplo, grandes solicitudes / respuestas o pequeñas cantidades frecuentes de datos). El costo del análisis de XML es generalmente de mayor magnitud que los formatos de cable optimizados (por ejemplo, ASN.1).
Para aplicaciones de control de bajo volumen, la simplicidad de XML-RPC debería superar los costos de rendimiento. Para comunicaciones de datos de gran volumen, puede ser mejor utilizar un protocolo de cable más eficiente.
Evite NIO a menos que tenga una buena razón para usarlo. No es muy divertido y puede que no sea tan beneficioso como piensas . Puede obtener una mejor escalabilidad una vez que tenga que lidiar con decenas de miles de conexiones, pero en números más bajos probablemente obtendrá un mejor rendimiento bloqueando IO. Sin embargo, como siempre, haz tus propias mediciones antes de comprometerte con algo de lo que puedas arrepentirte.
Otra cosa a considerar es que si desea usar SSL, NIO lo hace extremadamente doloroso.
La cantidad de conexiones de las que me habla me dice que debería usar java.net. Realmente, no hay ninguna razón para complejizar su tarea con E / S sin bloqueo. (A menos que sus sistemas remotos carezcan de potencia suficiente, pero ¿por qué usa Java en ellos?)
Eche un vistazo al paquete XML-RPC de Apache . Es fácil de usar, oculta completamente las cosas de la red y funciona a través de HTTP. No hay necesidad de preocuparse por los problemas de protocolo ... todo se verá como una llamada de método para usted, en ambos extremos.
La escalabilidad probablemente guiará su elección de paquete. java.net requerirá un hilo por socket. Codificarlo será significativamente más fácil. java.nio es mucho más eficiente, pero puede ser difícil de codificar.
Me preguntaría cuántas conexiones espera manejar. Si es relativamente poco (digamos, <100), iría con java.net.
No hay casi ninguna razón para escribir este tipo de código de red desde cero ahora. Los paquetes como netty.io casi siempre te ofrecerán un código más confiable y flexible con menos líneas de código que una solución hecha a mano. Además, con Netty, puede obtener soporte SSL sin complicar su implementación. Las bibliotecas como Netty también obvian casi por completo la pregunta "Async vs Threads", le ofrece un buen rendimiento y aún le permite modificar el modelo de subprocesamiento según sea necesario.