Trabajo en Red

Los ordenadores que se ejecutan en Internet comunican unos con otros utilizando los protocolos TCP y UDP, que son protocolos de 4 capas.

Cuando se escriben programas Java que se comunican a trav�s de la red, se est� programando en la capa de aplicaci�n. T�picamente, no se necesita trabajar con las capas TCP y UDP -- en su lugar se puede utilizar las clases del paquete java.net. Estas clases porporcionan comunicaci�n de red independiente del sistema. Sin embargo, necesitas entender la diferencia entre TCP y UDP para decidir que clases Java deber�an utilizar tus programas.

Cuando dos aplicaci�n se quieren comunicar una con otra de forma fiable, establecen una conexi�n y se env�an datos a trav�s de la conexi�n. Esto es parecido a hacer una llamada de tel�fono --se establece una comunicaci�n cuando se marca el n�mero de tel�fono y la otra persona responde. Se env�an y reciben datos cuando se habla por el tel�fono y se escucha lo que le dice la otra persona. Al igual que la compa�ia telef�nica, TCP garantiza que los datos enviados por una parte de la conexi�n realmente llegan a la otra parte y en el mismo orden en el que fueron enviados (de otra forma dar�a un error).

Las aplicaciones que requieren fiabilidad, canales punto a punto para comunicarse, utilizan TCP para ello. Hyper Text Transfer Protocol (HTTP), File Transfer Protocol (ftp), y Telnet (telnet) son ejemplos de aplicaciones que requieren un canal de comunicaci�n fiable. El orden en que los datos son enviados y recibidos a trav�s de la Red es cr�tico para el �xito de estas aplicaciones -- cuando se utiliza HTTP para leer desde una URL, los datos deben recibirse en el mismo orden en que fueron enviados, de otra forma tendr�s un fichero HTML revuelto, un fichero Zip corrupto o cualquier otra informaci�n no v�lida.

Para muchas aplicaciones esta garant�a de fiabilidad es cr�tica para el �xito de la transferencia de informaci�n desde un punto de la conexi�n al otro. Sin embargo, otras formas de comunicaci�n no necesitan esta comunicaci�n tan estricta y de hecho lo que hace es estorbar porque la conexi�n fiable anula el servicio.

Considera, por ejemplo, un servicio de hora que env�a la hora actual a sus clientes cuando estos lo piden. Si el cliente pierde un paquete, �tiene sentido volver a enviar el paquete? No porque la hora que recibir�a el cliente ya no ser�a exacta. Si el cliente hace dos peticiones y recibe dos paquetes del servidor en distinto orden, realmente no importa porque el cliente puede imaginarse que los paquetes no est�n en orden y pedir otro. El canal fiable, aqu� no es necesario, causando una degradaci�n del rendimiento, y podr�a estorbar a la utilidad del servicio.

Otro ejemplo de servicio que no necesita un canal de fiabilidad garantizada es el comando ping. El �nico objetivo del comando ping es comprobar la comunicaci�n entre dos programas a trav�s de la red. De hecho, ping necesita conocer las caidas o los paquetes fuera de orden para determinar lo buena o mala que es la conexi�n. As� un canal fiable invalidar�a este servicio.

El protocolo UDP proporciona una comunicaci�n no garantizada entros dos aplicaciones en la Red. UDP no est� basado en la conexi�n como TCP. UDP env�a paquetes de datos, llamados datagramas de una aplicaci�n a la otra. Enviar datagramas es como env�ar una carta a trav�s del servicio de correos: el orden de env�o no es importante y no est� garantizado, y cada mensaje es independiente de los otros.

�Puertos

Generalmente hablando, un ordenador tiene una sola conexi�n f�sica con la Red. Todos los datos destinados a un ordenador particular llegan a trav�s de la conexi�n. Sin embargo, los datos podr�a ser utilizados por diferentes aplicaciones ejecut�ndose en el ordenador. �Entonces c�mo sabe el ordenador a qu� aplicaci�n enviarle los datos? A trav�s del uso de los puertos.

Los datos transmitidos por internet est�n acompa�ados por una informaci�n de direcci�n que identifica el ordenador y el puerto al que est�n destinados. El ordenador est� identificado por su direcci�n IP de 32 bits, esta direcci�n se utiliza para env�ar los datos al ordenador correcto en la red. Los puertos est�n identificados por un n�mero de 16 bits, que TCP y UDP utilizan para env�ar los datos a la aplicaci�n correcta.

En aplicaciones basadas en la conexi�n, una aplicaci�n establece una conexi�n con otra aplicaci�n uniendo un socket a un n�mero de puerto. Esto tiene el efecto de registrar la aplicaci�n con el sistema para recibir todos los datos destinados a ese puerto. Dos aplicaciones no pueden utilizar el mismo puerto: intentar acceder a un puerto que ya est� utilizado dar� un error.

En comunicaciones basadas en datagramas, los paquetes de datagramas contienen el n�mero de puerto del destinatario.

Los n�meros de puertos tienen un rango de 0 a 65535 (porque los puertos est�n representados por un n�mero de 16 bits). Los puertos entre los n�meros 0 - 1023 est�n restringidos -- est�n reservados para servicios bien conocidos como HTTP, FTP y otros servicios del sistema. Tus aplicaciones no deber�an intentar unirse a estos puertos. Los puertos que est�n reservados para los servicios bien conocidos como HTTP y FTP se llaman puertos bien conocidos.

A trav�s de las clases del paquete java.net, los programas Java puede utilizan TCP o UDP para comunicarse a trav�s de Internet. Las clases URL, URLConnection, Socket, y SocketServer utilizan el TCP para comunicarse a trav�s de la Red. Las clases DatagramPacket y DatagramServer utilizan UDP.