Red de conocimiento informático - Conocimiento informático - Cómo hacer que el programa RMI admita tanto IPv4 como IPv6

Cómo hacer que el programa RMI admita tanto IPv4 como IPv6

La práctica ha demostrado que es robusto, fácil de implementar y tiene buena interoperabilidad. Sin embargo, todavía existen algunas deficiencias que no se consideraron en el diseño inicial del protocolo IPv4. Con el rápido desarrollo de Internet y la aparición continua de nuevas aplicaciones, estas deficiencias se van revelando gradualmente. En primer lugar, Internet ha crecido exponencialmente en los últimos años, y IPv4 con direcciones de sólo 32 bits ha causado un problema inminente de agotamiento del espacio de direcciones IP. En segundo lugar, la estructura de enrutamiento IPv4 es relativamente plana, lo que requiere que los enrutadores troncales de Internet mantengan un enrutamiento enorme; tablas; En tercer lugar, en el esquema de implementación actual de IPv4, la mayoría de los casos requieren configuración manual o el uso del modo con estado DHCP para configurar el protocolo. A medida que más y más nodos requieren acceso a la red, se necesita un método de configuración simple. IP En términos de nivel de seguridad, IPv4 no exige el uso de IPSec. Finalmente, el protocolo IPv4 utiliza el campo TOS del tipo de servicio para admitir la transmisión de flujo de comunicación en tiempo real y la función TOS es limitada, por lo que el soporte para tiempo real; La Qos de transmisión de datos no es muy ideal. Para resolver los problemas anteriores y otros problemas relacionados, el Grupo de Trabajo de Ingeniería de Internet IETF desarrolló un nuevo conjunto de protocolos y estándares llamado IP versión 6 (IPv6). Incorpora muchas ideas nuevas utilizadas para actualizar IPv4 y está diseñado para tener un impacto mínimo en los protocolos superiores e inferiores. En comparación con IPv4, el protocolo IPv6 tiene las siguientes características nuevas: el encabezado del protocolo IPv6 utiliza un encabezado de longitud fija y los enrutadores serán más eficientes al procesar los encabezados IPv6. IPv6 tiene un enorme espacio de direcciones de 128 bits. Incluso si a todos los hosts actuales se les asigna una dirección IPv6, IPv6 todavía tiene suficientes direcciones para uso futuro. IPv6 es plug-and-play. IPv6 introduce un método de configuración automática de direcciones sin estado. Los hosts en el enlace pueden generar automáticamente una dirección IPv6 basada en anuncios de enrutamiento y sus propias direcciones de enlace, simplificando así el proceso de configuración de los hosts conectados a la red y logrando IPv6 plug-and-play. Proporciona autenticación y cifrado de capa de red. IPv6 es compatible con IPSec, que proporciona una solución basada en estándares para la seguridad de la red. IPv6 soporta mejor QoS. El encabezado del protocolo IPv6 contiene un campo de etiqueta de flujo, que permite a los enrutadores identificar y proporcionar un procesamiento especial para los paquetes de datos que pertenecen a un flujo. El campo de clasificación de flujo de negocios se utiliza para priorizar los flujos de comunicación. Por lo tanto, IPv6 proporciona un mejor soporte para QoS. IPv6 soporta mejor la movilidad. Aunque IPv4 también tiene características móviles, como extensión de IPv4, está limitado por la arquitectura y la conectividad. Las características de movilidad de IPv6 están integradas, tienen menos limitaciones y son más escalables y robustas para satisfacer las necesidades de comunicación de Internet en el futuro. IPv6 es altamente extensible al agregar nuevos encabezados de extensión después de los encabezados del protocolo IPv6. Volver arriba Soporte de Java para IPv6 Java ha proporcionado soporte para IPv6 desde 1.4. Las API de Java siguen los siguientes estándares IPv6: RFC2373: Arquitectura de direccionamiento IPv6RFC2553: Extensiones de interfaz de socket básica para IPv6RFC2732: Formato para dirección IPv6 literal en URL Sin embargo, debido a la seguridad y otros factores, Java no admite sockets sin formato. Además, Java no admite algunas funciones de IPv6, como túneles, configuración automática, IP móvil, etc.

A diferencia del soporte de C/C para IPv6, el soporte de Java para IPv6 es automático y transparente, lo que significa que los programas Java existentes pueden soportar directamente IPv6 sin modificaciones. Tome el siguiente código como ejemplo. Este código puede ejecutarse normalmente en IPv4 y también puede funcionar en IPv6. InetAddress ip = InetAddress.getByName("java.sun.com"); Socket s = new Socket(ip, 80); El soporte de Java para IPv6 se refleja en el soporte de su JDK para IPv6. necesita proporcionar soporte para IPv6. Los siguientes sistemas operativos han proporcionado soporte para IPv6, Tabla 1. Soporte de SO para IPv6 Windows: Windows 2000Windows XPWindows NTWindows 2003 serverLinux: Linux kernel 2.2 y superior Unix: AIX 4.3 y superior Solaris 8 y superior HP-UX 11i y superior BSD/OS 4.0 y superior True64 Unix 4.0D y superior FreeBSD 4.0 y superior NetBSD OpenBSD 2.7 y superior Otros sistemas operativos: OS/390, Z/OS V1R4 y superior OS400 V5R2 y superior Mac OS X y inferior Muestra la compatibilidad con IPv6 en cada versión de JDK . Tabla 2. Compatibilidad de JDK con IPv6 JDK/OSWindowsLinuxAIXSolarisHPUXZOSIBM JDK 1.4NOYESYESNOIBM JDK 1.5YESYESYESSUN JDK 1.4NOYESYESSUN JDK 1.5YESYESYESJRockit JDK 1.4NOYESJRockit JDK 1.5YESYESHP-UX JDK -UX JDK 1.5SÍ Volver arriba RMI admite IPv6 ya que Java admite IPv6. transparente, por lo que, en teoría, el programa RMI debería admitir tanto IPv4 como IPv6, pero los resultados de las pruebas nos dicen que esta conclusión solo es cierta cuando el socket del lado del servidor RMI no está vinculado a una dirección IP. Considere el siguiente ejemplo de un servidor de doble pila configurado con una dirección IPv4 y una dirección IPv6. La aplicación del servidor utiliza el siguiente código para crear un socket de servidor y esperar a que el cliente se conecte. Debido al soporte transparente de Java para IPv6, tanto los clientes IPv4 como IPv6 pueden conectarse a este servidor normalmente. Listado 1. Programa de socket de servidor sin enlace de IP try { int port = 2000; ServerSocket srv = new ServerSocket(port); Socket socket = srv.accept() } catch (IOException e) { e.printStackTrace() ; Se puede ver en natestat - na que el servidor está escuchando en 0.0.0.0:2000, por lo que cualquier cliente puede conectarse al servidor, incluidos los clientes IPv6. También pueden conectarse sin problemas utilizando la dirección IPv6 del servidor.

Proto Dirección local Dirección extranjera Estado TCP 0.0.0.0: 2000 0.0.0.0: 0 ESCUCHA Sin embargo, muchas veces, las aplicaciones necesitan vincular el socket del servidor a una IP específica desde la perspectiva de la seguridad. Ahora asumimos que el socket del servidor está vinculado a una dirección IPv4, como se muestra en el siguiente programa: Listado 2. Programa de socket del servidor vinculado a IP try { int port = 2000 ServerSocket srv = new ServerSocket(port); new InetSocketAddress(" 9.181.27.34 ", puerto) Socket socket = srv.accept(); } catch (IOException e) { e.printStackTrace() } A través de natestat - na, podemos encontrar que el método de escucha ha cambiado: Proto Dirección local Dirección extranjera Estado TCP 9.181.27.34: 2000 0.0.0.0: 0 ESCUCHA Según la definición de socket, consta de IP y puerto. Determinan de forma única un socket y también limitan el acceso al socket cuando se accede a un socket. IP y puerto fijos, el cliente debe especificar la IP y el puerto del servidor para conectarse normalmente. Cuando el servidor está vinculado a una dirección IPv4, el cliente IPv6 no puede usar la dirección IPv6 del servidor para acceder, por supuesto, el cliente IPv4 puede conectarse y. acceda a través de la dirección IPv4 del servidor 9.181.27.34. Lo anterior analiza el soporte de Java para IPv6 y cómo el socket del servidor afecta la conexión del cliente. A continuación, usamos un ejemplo para analizar el uso de IPv6 por parte de RMI.

Construimos el siguiente entorno experimental: Figura 1. Entorno experimental A continuación, diseñamos una aplicación RMI básica. El siguiente párrafo es el programa del servidor RMI: Listado 3. Programa del servidor RMI import java.rmi.*; *; import java.rmi.registry.*; la clase pública SampleServerImpl extiende UnicastRemoteObject implementa SampleServer { SampleServerImpl() lanza RemoteException { super() } public int sum(int a, int b) lanza RemoteException { return a b } public static void; main(String args[]) { try { //crea una instancia local del objeto SampleServerImpl Server = new SampleServerImpl(); //coloca la instancia local en el registro Naming.rebind("rmi://9.181 .27.34/SAMPLE -SERVIDOR", Servidor); System.out.println("Servidor esperando....."); } catch (java.net.MalformedURLException me) { System.out.println("URL con formato incorrecto: " me.toString( )); } catch (RemoteException re) { System.out.println("Excepción remota: " re.toString()); Compile el programa fuente, inicie rmiregistry y luego ejecute el programa del servidor RMI. A través de netstat - na podemos ver que el método de monitoreo RMI es el siguiente, aunque usamos "Naming.rebind("rmi://9.181.27.34/SAMPLE-SERVER", Server)" en el programa: Proto Dirección local Dirección extranjera State TCP 0.0.0.0:1099 0.0.0.0:0 ESCUCHANDO Bueno, según nuestro análisis anterior sobre el impacto de los sockets en las conexiones de los clientes, podemos ver que en este caso, tanto los clientes IPv4 RMI como los clientes IPv6 RMI deberían poder conectarse a Servidor RMI sin problemas.

Echemos un vistazo al programa de conexión del cliente IPv4: Listado 4. Programa cliente RMI import java.rmi.*; import java.rmi.server.*; public class SampleClient { public static void main(String[] args) { / / obtenga el objeto remoto del registro intente { //usar la dirección IPv4 del servidor RMI para conectarse String url = "//9.181.27.34/SAMPLE-SERVER"; SampleServer remoteObject = (SampleServer)Naming.lookup(url); out.println("Obtuve objeto remoto"); System.out.println(" 1 2 = " remoteObject.sum(1, 2) } catch (RemoteException exc) { System.out.println("Error en la búsqueda: " exc.toString()); } catch (java.net.MalformedURLException exc) { System.out.println("URL con formato incorrecto: " exc.toString()); } catch (java.rmi.NotBoundException exc) { System . out.println("NotBound: " exc.toString()); } } } Compile y ejecute el programa, puede ver que está conectado al servidor RMI normalmente y los resultados de la ejecución son los siguientes: Obtuve el objeto remoto 1 2 = 3 A continuación estamos en IPv4 RMI Realice algunos cambios según el programa cliente y use la dirección IPv6 del servidor RMI para conectarse. Las modificaciones son las siguientes: String url = "//2001:251:1a05::6/SAMPLE. -SERVER"; SampleServer remoteObject = (SampleServer)Naming. lookup(url); Compile el programa modificado y ejecútelo en el cliente RMI IPv6. También puede conectarse al servidor RMI normalmente. Los resultados de la ejecución son los siguientes: Obtuve el objeto remoto 1 2 = 3. A través de este ejemplo, podemos ver que el programa RMI básico es compatible con IPv6, es transparente y puede admitir tanto IPv4 como IPv6. A través de este ejemplo, también podemos ver que en realidad no puede vincular una dirección IP, lo cual no es muy adecuado en aplicaciones de nivel empresarial con requisitos de seguridad relativamente altos. Generalmente usan exportObject (Remote obj, puerto int de la clase UnicastRemoteObject, RMIClientSocketFactory. csf, RMIServerSocketFactory ssf) para vincular la dirección IP de RMI. En la instancia RMIServerSocketFactory, cree un socket de servidor RMI y vincule la dirección IP, y acceda a él en la instancia RMIClientSocketFactory a través de la dirección IP vinculada al servidor.

Cuando el servidor RMI está vinculado a una dirección IP, ¿qué pasa si RMI admite tanto IPv4 como IPv6? A continuación se proporciona una solución. Como queremos que RMI admita tanto IPv4 como IPv6, en el lado del servidor, necesitamos crear dos sockets al mismo tiempo, uno vinculado a la dirección IPv4 y otro vinculado a la dirección IPv6. Primero, debemos crear dos clases IPv4RMIServerSocket e IPv6RMIServerSocket, ambas implementan la interfaz RMIServerSocketFactory. IPv4RMIServerSocket crea un socket de servidor y lo vincula a la dirección IPv4 del servidor RMI; IPv6RMIServerSocket crea un socket de servidor y lo vincula a la dirección IPv6 del servidor RMI. En segundo lugar, después de crear dos clases, IPv4RMIClientSocket e IPv6RMIClientSocket, ambas implementan la interfaz RMIClientSocketFactory. IPv4RMIClientSocket crea un socket de cliente y se conecta a través de la dirección IPv4 del servidor RMI; IPv6RMIClientSocket crea un socket de cliente y se conecta a través de la dirección IPv6 del servidor RMI. Luego, después de crear las clases de servidor y cliente que necesitamos, la aplicación del servidor debe llamar al método exportObject dos veces para exportar el objeto remoto. Pero surge un problema: el mismo objeto remoto no se puede exportar dos veces al mismo tiempo. ¿Cómo solucionar este problema? La solución es que necesitamos crear un contenedor para el objeto remoto.

Ahora supongamos que hay una definición de clase de Kernel de objeto remoto de la siguiente manera: Listado 5. Definición de clase de Kernel public class Kernel extends Remote{ public void addWebServer(String hostName, int port) throws RemoteException { //Código de implementación de función } public void changeLogLevel(int nivel) throws RemoteException { //Código de implementación de función } }El Wrapper del kernel se define de la siguiente manera: Listado 6. Definición de la clase Wrapper del kernel public class KernelWrapper extends Remote { transient Kernel kernel_; public KernelWrapper (kernel kernel) throws RemoteException, IOException { super(); ; kernel_ = kernel; } public void addWebServer (String hostName, int port) lanza RemoteException { kernel_.addWebServer (hostName, puerto) public void changeLogLevel (int nivel) lanza RemoteException { kernel_.changeLogLevel (nivel); inicialización Al crear una instancia de Kernel y usarla como parámetro para crear una instancia de dos instancias de KernelWrapper, como se muestra a continuación: Listado 7. Creación de instancias de KernelWrapper kernelObj = new Kernel() //objeto de kernel remoto para clientes IPv4 ipv4kernelObj = new KernelWrapper (kernelObj); //objeto de kernel remoto para clientes IPv6 ipv6kernelObj = new KernelWrapper (kernelObj); Finalmente, la aplicación necesita exportar los objetos remotos ipv4kernelObj e ipv6kernelObj, como se muestra a continuación: Listado 8. Exportación de objetos remotos //exportar objeto remoto para el cliente IPv4 UnicastRemoteObject. exportObject(ipv4kernelObj, 1099, IPv4RMIClientSocket, IPv4RMIServerSocket) //exportar objeto remoto para el cliente IPv6 UnicastRemoteObject.exportObject(ipv6kernelObj, 1099, IPv6RMIClientSocket, IPv6RMIServerSocket) para que el cliente IPv4 pase el acceso a la dirección IPv4 del servidor mientras que los clientes IPv6 pasan por el servidor IPv6 dirección para acceder desde

El resultado es que el servidor RMI admite tanto IPv4 como IPv6 al vincular una dirección IP. Volver arriba Conclusión Basado en el análisis del impacto de los sockets de servidor en los clientes IPv4 e IPv6, este artículo presenta el soporte de dos aplicaciones RMI diferentes para IPv6 y también brinda soporte a un servidor RMI que necesita vincular una dirección IP. Clientes IPv4 e IPv6. Referencias Página de inicio de IPv6: sitio web oficial de IPv6.

Guía del usuario de redes IPv6 para J2SDK/JRE 1.4: compatibilidad con JDK 1.4 para IPv6.

Un ejemplo de programación RMI: Un ejemplo sencillo de RMI.

"Exploración del protocolo de Internet, versión 6 (IPv6)" (developerWorks, julio de 2006): obtenga información sobre el formato de dirección de IPv6, los beneficios clave y los productos de TI que cumplen con el nuevo estándar.

"Configuración de un servidor FTP para admitir IPv6" (developerWorks, agosto de 2006): en este artículo, aprenderá a configurar un servidor de protocolo de transferencia de archivos (FTP) para admitir IPv6 y luego usar un programa Java simple para comunicarse con el servidor FTP.

"Uso de WebSphere Application Server V7 con IPv6" (developerWorks, noviembre de 2008): este artículo describe el proceso para validar IBM WebSphere Application Server V7 para IPv6 y para el soporte de infraestructura de modo mixto IPv4/IPv6.

DeveloperWorks Java Technology Zone: Cientos de artículos sobre programación Java.

Acerca del autor Gang Shen actualmente se dedica al desarrollo de productos ITM para aplicaciones en el departamento de IBM Tivoli. Cerrar [x] Ayuda para denunciar abuso Informar abuso ¡Gracias! Este contenido ha sido marcado para la atención de los administradores. Cerrar [x] Ayuda para denunciar abuso Informar abuso Error al enviar el informe de abuso. Inténtelo de nuevo más tarde. Cerrando [x]developerWorks: Inicie sesión en IBM ID: ¿Necesita una ID de IBM? ¿Olvidó su ID de IBM? Contraseña: ¿Olvidaste tu contraseña? Cambie su contraseña Manténgase conectado. Al hacer clic en Enviar, acepta los términos y condiciones de DeveloperWorks. Términos de uso Cuando inicia sesión por primera vez en DeveloperWorks, se crea un perfil para usted. La información que elija hacer pública en su perfil de desarrolladorWorks será visible públicamente para otros, pero puede modificar la visibilidad de esta información en cualquier momento. Su nombre (a menos que elija ocultarlos) y su apodo aparecerán con el contenido que publique en desarrolladorWorks. Toda la información enviada se mantiene segura. Cerrar [x] Seleccione su apodo: cuando inicie sesión por primera vez en desarrolladorWorks, se creará un perfil para usted y deberá especificar un apodo. Su apodo aparecerá con el contenido que publique en desarrolladorWorks. La longitud del apodo puede tener entre 3 y 31 caracteres. Su apodo debe ser único dentro de la comunidad de DeveloperWorks y, por razones de privacidad, no puede ser su dirección de correo electrónico.

Apodo: (Longitud entre 3 y 31 caracteres) Al hacer clic en Enviar, acepta los términos y condiciones de DeveloperWorks. Términos de uso. Toda la información enviada se mantiene segura. Califica este artículo y comenta volver arriba