Diferencia entre la programación de redes y la programación de sockets


16

¿Hay alguna diferencia importante cuando hablamos de "programación de socket" en comparación con "programación de red"?

¿Hay algunos temas que cubren "programación de red" pero no "programación de socket"?

Respuestas:


26

La programación de sockets (al menos como se usa normalmente el término) es programar para una API de red específica. Los sockets admiten protocolos basados ​​en IP (principalmente TCP y UDP) 1 .

La programación de red se puede hacer usando varias otras API. Windows tiene una serie de API independientes del protocolo, como las funciones WNet * y Net *. Las versiones anteriores de Windows también usaban NetBIOS / NetBEUI (Interfaz de usuario final de NetBIOS), y la mayoría soportaba (y probablemente todavía lo haga) IPX / SPX (un antiguo protocolo de Netware).

Sin embargo, la mayoría de la programación de red actual se realiza utilizando sockets directamente o utilizando varias otras capas en la parte superior de los sockets (por ejemplo, mucho se hace a través de HTTP, que normalmente se implementa con TCP a través de sockets). TCP / IP y UDP / IP (así como una serie de otros protocolos basados ​​en IP) se realizan principalmente a través de la interfaz de sockets. En teoría, se podrían usar otras interfaces de programación, pero en la práctica los sockets parecen ser suficientes, por lo que no hay mucho interés en reemplazarlos. Sin embargo, debo mencionar que los sockets de Windows (WinSock) tienen bastantes extensiones que son más o menos exclusivas de Windows. Supongo que está abierto a algún argumento si el código que usa estas extensiones realmente califica como código de "sockets" o no, son extensiones basadas en los mismos conceptos, pero el código que las usa no lo es. Normalmente es portátil a otros sistemas. Supongo que si califica como "sockets" o no depende principalmente de si piensas en los sockets más como un concepto, o un conjunto muy específico de funciones, parámetros, etc.

Editar (en respuesta al comentario):

Es un poco difícil decir si "conocer sockets" implica saber "todo" sobre TCP y UDP. Consideremos solo una pequeña parte: un programa de demostración típico para sockets es crear un programa de chat cliente / servidor. El cliente se conecta al servidor, y cuando el usuario de un cliente escribe algo, se reenvía a los otros clientes que están conectados al mismo servidor. Cada cliente muestra lo que viene del servidor y permite que el usuario escriba los mensajes que se enviarán a los otros clientes.

Al mismo tiempo, considere lo que implica un programa de chat "real" como AIM, Windows Messenger, iChat, etc. Para manejar no solo texto, sino también voz, video, transferencias de archivos, grupos, listas, etc., un programa típico probablemente involucra una docena de estándares diferentes, que incluyen cosas como SIP, STUN, TURN, RTCP, RTP, XAMPP, mDNS, etc. .

En mi opinión, alguien que "conozca los sockets" debería poder codificar el primer programa de chat (nivel de demostración, solo texto) en unas pocas horas sin pasar mucho tiempo en los archivos de ayuda (y demás) investigando. A menos que afirmen tener al menos alguna experiencia previa trabajando en un programa de chat "real", no esperaría que supieran qué RFC / estándares se aplican a tales cosas.

Lo mismo se aplica en general: dada la cantidad de RFC (y varios otros estándares) que se aplican a todas las cosas diferentes que las personas hacen a través de las redes, no es razonable esperar que alguien las haya memorizado todas. No obstante, si tiene un conjunto de requisitos para algo que esperaría que las personas puedan manejar fácilmente en un programa "local", simplemente agregar "a través de la red" como un requisito normalmente no debería agregar una gran cantidad de dificultad (aunque se trata de problemas como la latencia de la red).


1 Los sockets en Unix también son compatibles con los sockets de la familia Unix, pero estos (al menos normalmente) se usan para IPC dentro de la máquina, no para redes. También hay literalmente docenas de otros protocolos para cosas como la administración de enrutadores que los sockets realmente no son compatibles (más allá de los sockets sin procesar que le permiten construir y enviar paquetes arbitrarios).


Gracias, ahora esta es una respuesta que vale la pena votar. :-) Entonces, ¿puedo concluir que cuando digo que conozco la programación de sockets, significa tratar " todo " solo con TCP / UDP? ¿Necesito saber todo sobre TCP / UDP?
Aquarius_Girl

@AnishaKaul: Ver la respuesta editada.
Jerry Coffin

@JerryCoffin: Posiblemente valga la pena señalar que los sockets también son un subconjunto de protocolos basados ​​en IP. Hay cosas como ICMP / IP que tampoco están cubiertas por sockets.
Matthew Scharley

6

La "programación de red" requerirá cierta tecnología de red, por ejemplo, RPC. Los zócalos (probablemente se refieren a los zócalos BSD) son un ejemplo de dicha tecnología. Entonces, "programación de socket" es un subconjunto de "programación de red".


@Anisha Kaul: De acuerdo, la programación de RPC es programación de red (un subconjunto de la misma) y un concepto importante de RPC es el llamado enlace de cadena : consulte msdn.microsoft.com/en-us/library/aa378691(v=VS.85) .aspx No necesita esa cosa al programar sockets BSD.
Sharptooth

@Anisha Kaul: No, "todas las posibilidades" es una lista enorme. Mencionaría algunos ampliamente utilizados: Java RMI y .NET Remoting son buenos ejemplos.
Sharptooth

-3

Sí, es cierto que la programación de red requiere tecnología de red, mientras que, por otro lado, la programación de socket es un subconjunto de la programación de red. La mayoría de la programación de red actual se realiza utilizando sockets directamente o utilizando varias otras capas en la parte superior de los sockets.


3
Esto no parece agregar nada sustancial sobre lo que ya se publicó en respuestas anteriores
mosquito
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.