BandaAncha.eu

Comunidad de usuarios
de fibra, móvil y ADSL

Pregunta sobre conceptos TCP/IP

overpeer

Tal vez no tenga que ir aki, pero me parecio el mejor sitio para ponerla.

Una conexion en un socket , es unidireccional o bidireccional?..... simplex.. half ... full.

Osea... , si inico una conexion al puerto X de un host, por esa conexion puedo enviar y recibir datos.

Por un lado pienso que si, cuando haces una conexion telnet envias y recibes. Por otro... claro... no se como explicarlo

Se que es una tonteria, hasta hace unos dias lo veia claro, pero ahora mismo me salen un monton de dudas y supuestos que me hacen dudar, supongo que si alguno me lo explicais con vuestras palabras lo entendere mejor :D

Un saludo.

Este tema está cerrado a nuevas respuestas. Abre un nuevo tema para retomar la conversación.
anthrax

una de las cosas que hay que tener un poco clara en este mundillo de las redes, es como funcionan las cosas a bajo nivel (la capa TCP/IP). Una cosa que puedes hacer si quieres ver como va la cosa, es usar un sniffer para ver como funcionan por ejemplo el http o el ftp :)

Un sitio donde puedes mirar es en : www.rfc-editor.org/
eso si te aconsejo que te mentalizes, pues según que rfc es como mínimo infumables (como diria FreeBSD). Pero es un buen sitio para aprender y quitarse algunas dudas de la gran familia de protocolos TCP/IP.

Despues de todo esto, voy a "intentar" responder tu pregunta/s :

Solo entraré en los protocolos de capa de aplicación (http p ftp por ejemplo) que usan el TCP como capa de transporte.El UDP va más a su bola ... :P

Pues bien la mayoria de las veces se sigue un esquema de Servidor/Cliente para comunicarse. El server escucha en un puerto (por ejemplo web, el 80), para eso abre un socket. Un socket es una forma fácil (interficie) que las aplicaciones (tipo http) puedan acceder a las capas 4 y por debajo. En GNU/LInux se programa con sockets y en Guindous con Winsocks si no voy equivocado. Un socket permite entre otras cosas abrir un puerto en la máquina servidor, esperando que los clientes quieran conectar con él. Un proceso llamado generalmente demonio (el httpd ó Apache) se encarga de responder a las peticiones de los clientes.
Antes de enviar los datos en si entre servidor y cliente (las páginas web por ejemplo), se hace la conexión entre ellos, que en TCP se llama de tres vias :

1º Cliente -------SYN->-- Server
2º Cliente ---3º Cliente --------ACK---->-- Server

(SYN y ACK son "banderas" que usa el TCP )

Una vez estrablecida la conexión se envias los datos, el server envia los datos (página web) y el cliente los confirma con ACK :

1º Cliente ----2º Cliente --->-----ACK-- Server

Respecto a lo que preguntas ... :P, pues si el tráfico de datos es bidireccional y puede ser half o full duplex. Pero teniendo simpre en cuenta que suele ser el cliente el que inicie la conexión hacia el servidor, que esta esperando conexiones.

Saludos 8)
Espero no haberme alargado demasiado y que te hayas enterado de "algo". Se nota que el tema de redes me gusta :D

P.D: Ahora que me doy cuenta, no se que @#½ ha pasado que las explicaciones sobre el establecimiento de conexión me han salido un gañapo ... :(

🗨️ 7
overpeer

Lo que digo, es cuando una conexion esta ya en ESTABLISHED por ejemplo A q conecta con B , en sentido down llegarian los datos que A le va pidiendo a B y respuestas de los comandos de protocolo y en sentido up los SYNC_ACK negociados en el tamaño de ventana y las instrucciones de del protocolo correspondiente pero.... ademas de esas instrucciones y sync.ack's .... podrian ir datos?? o sea

hostA:1025 --> insrucciones http, sync_ack's --> hostB:80
hostA:1025

Ahhhhhhhhhhhhhhhhhhhhhh xD
lo acabo de entender.

La comunicacion si puede ser hall o full duplex, de hecho siempre lo es. Cuando establecemos una conexion por ejemplo http con un server, la idea es que nosotros le damos instrucciones y el nos devuelve la salida de esas instrucciones o los datos solicitados en llas, cuando rellenamos por ejemplo, un formulario como el de esta web para registrarnos... si, le enviamos datos al server, pero no son datos propiamente dichos, sino instrucciones de protocolos superiores (html, php, htm.. ) embebidas en http que el server interpreta.

Es asi verdad?

Es que el quebradero de cabeza ha empezado cuando he rellenado uno de estos chismes xDDD

Un saludo.

🗨️ 2
anthrax

Ya veo que tienes bien todos o casi todos los conceptos ;)
Por tu pregunta pensaba que muchas de estas cosas no las sabias. Perdona por haberlo supuesto ... :P

Te vuelvo a RECALCAR que si tienes dudas existenciales sobre el funcionamiento de protocolos TCP/IP :), te enchufes por ejemplo el Ethereal en tu pc y captures el tráfico al acceder a páginas webs,ftp,etc ...
Una vez que hallas capturado el tráfico, miratelo y verás como se te van aclarando dudas y demás. Solo con que tengas unos cuantos conceptos claros, verás como sabes interpretar y comprender el funcionamiento del tcp,ip y protocolos de nivel de aplicación como el http p el ftp. Te lo digo por experiencia propia.

Una vez que se ha establecido la conexión a tres bandas, entonces le toca el turno al protocolo de aplicación (http,ftp,telnet,etc ...) de enviar datos entre cliente y servidor. En la establecimiento de la conexión no se envian datos ( los datos circulan por encima de la capa 4 de transporte tcp o udp). Hecha la conexión entre cliente y servidor se envian comandos propios solo del nivel de aplicación. Estos comandos y datos siempre se envian sobre la capa 4(tcp o udp).
Un comando típico seria en el http cuando el cliente le hace una petición 'GET / HTTP/1.1' al servidor, diciendole entre otras cosas el nombre del navegador web del cliente. Entonces el servidor le devuelve un un HTTP/1 .1 200 Ok conforme acepta la petición (el servidor web tb dice que servidor es apache o IIS y la versión,modulos cargados,etc.). A continuación empieza la transferencia de la página web en si. En este caso la página index de la web. Normalmnete a lo lago de una sesión se abren y cierran conexiones tcp unas cuantas veces.

Una cosa que confundes es que html o php no son protocolos de red en si, sino lenguajes que tanto cliente como servidor saben entender que como dices muy bien viajan en el http.

Saludos 8)

🗨️ 1
overpeer

Me referia a que eran protocolos de capa superior, de capa aplicacion.

No hay nada que perdonar :PP ojala todo el mundo se explicase de forma tan extensa :D

Bueno, pues habra que darle caña al ethereal ... a ver si alcanzo el "Nirvana TCP/IP" xD

Un saludo y gracias ;D

FreeBSD

Me da un poco de cosa añadir algo a tu buena y generosa explicación pero me muero si no aporto algo después de tanto tiempo a este foro.

En Windows (Visual C++ 6.0 porque es lo que conozco) puedes utilizar tanto una interfaz Winsocks como la socket. Aunque la socket no cumple el estándar al 100% (como casi siempre) pero se puede reutilizar parte del código.

Por otro lado haces bien en decir que "Un socket permite entre otras cosas abrir un puerto en la máquina servidor...", porque es verdad que hace otras cosas. Un socket es un punto de acceso a servicio (lo que en telemática se llama SAP, creo recordar). Normalmente se accede a la capa de "Control de la Transmisión" (protocolos TCP y UDP), aunque pueden usarse sockets más "crudos".

Digo esto porque parece que cada puerto sólo tiene "asignado" un único socket y no tiene que ser así y muy a cuento por el post original cuando dice:"Una conexion en un socket , es unidireccional o bidireccional?..... simplex.. half ... full". Me imagino que Overpeer cuando habla de sockets se refiere a conexiones (si no es así que me corrija), pero las conexiones en Internet siempre son bidireccionales por el simple control de flujo.

Espero que se me haya entendido aunque me parece que no lo he dejado muy claro.

Salu2.

🗨️ 3
anthrax

dices que los sockets no siguen los RFC's, dirás los Winsocks, no?

Y cuando te refieres a los sockets "crudos", te refieres a los RAW sockets, nops?

Saludos 8)

🗨️ 2
FreeBSD

Me refiero a que en MS VISUAL C++ 6.0 venden una interfaz socket que no cumple con el standar. Obviamente los Winsocks ni lo cumplen ni lo pretenden. Winsocks es una interfaz más adaptada a Windows. No me parece mal que tenga una interfaz separada porque poco tienen que ver con los sistemas Unix para cargar con algo tan antiguo.

Aunque la verdad, cada día se programa menos sobre la interfaz socket. Es más fácil, cómodo y rápido usar otras cosas.

Salu2.

🗨️ 1
FreeBSD
Lofter

Puedes enviar y recibir pero no simultaneamente, cuando creas el socket (q no es mas q un "canal", ip origen, puerto origen, ip destino, puerto d destino) se establece la conexion cliente/servidor poniendose d acuerdo con paquetes d control, es decir, primero el cliente negocia con el servidor si esta disponible, cuando el otro le responde (enviando al final d cada transmision el ack, o nack segun sea) el cliente solicita los datos y se qda a la escucha, el servidor envia lo q tenga q enviar y el cliente le responde si ha llegado bien (despues d verificar los paquetes recibidos) y le confirma la llegada o le pide un reenvio segun sea necesario, n el caso d un navegador enviaria ademas los comandos d sesion para cortar la conexion (cuando ves una pagina n el navegador, aunq recargues varias veces, el puerto origen local es distinto cada vez, puesto q se descartan los sockets una vez usados) si no, se qdan ambos a la escucha hasta q uno envie al otro el cierre d sesion.

Un ejemplo del metodo d transmision es el ftp, tienes un puerto para datos (el 20) y otro para control (el 21) d manera q a mitad d una transmision puedes seguir enviando comandos al servidor, si no hasta q no termine no t va a escuchar, si los sockets fuesen bidireccionales full duplex, con uno solo arreglarias la gestion y la transferencia.

🗨️ 17
FreeBSD

Hace tiempo que no programo y otro tanto convaleciente pero creo recordar que una vez obtenido un socket puedes enviar y recibir datos por el mismo, son de lectura/escritura completamente.

De todas las maneras no me parece tampoco muy apropiado el ejemplo de FTP porque se vuelven a igualar sockets a puertos y no tiene nada que ver.

Decidme si estoy equivocado o si hablo de cosas distintas a los dejas :-D .

Salu2.

🗨️ 14
Stendall

Un socket cuando se crea es bidireccional por defecto, se pueden enviar y recibir datos, no simultaneamente, por que para eso harian falta 2 canales, pero si primero en un sentido y luego en otro, para eso tiene que haber una sincronizacion entre el servidor y el cliente, para llegar a esa sincronizacion:
Servidor Manda -> Cliente Recibe
Servidor Recibe Servidor Recibe
El orden y la repeticion de pasos, es decir, manda->recibe->recibe etc.. es lo de menos, pero ambos tienen que usar el mismo protocolo (que puede y suele ser un protocolo por encima de tcp/ip o tcp/udp, por ejemplo http y que esta definido por la aplicacion, no por la implementacion de el layer inferior), para que en cada momento sepan cuando deben mandar y cuando recibir, por que el software en cada momento hace una cosa y espera o no contestacion en un momento dado (hablando de uniprocesos y un solo socket).
Los sockets aunque son bidireccionales o half duplex, se pueden cerrar en un sentido o en otro creo recordar, es decir, una vez creado un socket se puede cerrar uno u otro estremo de la tuberia, para que solo pueda enviar o recibir, pero no ambos, pero en ningun caso es obligatorio ni mucho menos necesario para el half duplex.

Los que creen que es unidireccional se lian con el hecho de que por ejemplo en una conexion con una pagina web o ftp hay 2 sockets (no necesariamente), 1 se utiliza como socket de control, para envio de peticiones y recepcion de mensajes de confirmacion estado etc, por ejemplo las peticiones de pagina web, cabeceras etc, y el otro para la transferencia de los archivos que manda el servidor que se sincroniza con el cliente a traves de el socket de control.
Esto es así por que si estamos por ejemplo bajando un fichero grande de un servidor ftp y hubiese un solo socket para todo, control y transferencia, no se le podria indicar al servidor que deseamos por ejemplo cancelar la descarga y ejecutar un ls, por que como he dicho antes, a pesar de ser bidireccional es half duplex y si el servidor esta mandando datos no puede recibir (el control de paquetes y fragmentos va por debajo a traves del tcp), con lo cual habría que esperar a la finalizacion de la descarga para mandarle otro comando al servidor desde el cliente, pasa exactamente lo mismo con http y muchos otros subprotocolos.

Bueno, eso es todo, espero no haber metido la pata hasta la ingle, que hace bastante que no programo para redes desde lenguajes de bajo nivel.

Un saludo.

Editado, habia puesto full duplex en vez de half y no habia terminado de escribir parte de el Servidor Manda etc...

🗨️ 13
FreeBSD

Hola Stendall, un placer saludarte de nuevo y espero que saquemos algo interesante de la conversación.

Creo que has explicado cosas mejor que yo pero hay otras en las que no estoy muy de acuerdo.Voy a intentar no liarme (raro) e ir al grano (imposible).

El hecho de que un protocolo baraje distintas conexiones para una misma comunicación no responde a otra cosa más que a una decisión de diseño del protocolo. Cuando se diseña un protocolo se decide (entre otras cosas) si la señalización será por canal común (datos y señalización por conexiones/canales/cables/circuitos independientes) o canal asociado (por el mismo tó). Para el ejemplo del FTP que propones hay miles de soluciones con una conexión únicamente. Pero es cierto que las soluciones por canal común suelen ser las más elegidas por simplicidad y desempeño.

Por ponerte una posible solución a tu problema del FTP: si estás enviando un fichero muy grande y quieres hacer otra operación, simplemente dejas de mandar paquetes de datos con el fichero, mandas un paquete de suspensión de esa sesión de transferencia, mandas un paquete de datos con el ls, recoges el resultado y reanudas la sesión. Así hemos metido los datos y el control por la misma conexión y el mismo socket.

Para mostrar que no es lo mismo un socket que una conexión o un puerto, lo mejor es hablar de los servidores. Un servidor, tras solicitar un socket(TCP) y hacer su configuración (bind), crea una cola de peticiones en dicho socket con la llamada listen. Ese socket se queda escuchando en el puerto que se le haya asignado y SOLO se dedica a recibir peticiones. Cuando llega una petición, el servidor la acepta con la llamada accept. ¿Sabeis lo que devuelve esa llamada? Devuelve un socket en estado de transferencia (listo para enchufar datos). ¿Qué dirección local tiene ese socket? La misma dirección IP y puerto que tenía el socket original (el que creamos y le pasamos el listen). De manera que podemos llegar a tener un montón de sockets asociados a una serie de conexiones y todos con la misma dirección local (dirección IP + puerto). Y además resulta que en una conexión intervienen 2 sockets diferentes. Espero que se me haya entendido: socket conexion puerto.

Por otro lado tienes razón, un socket se puede cerrar en recepción o envío mediante la llamada shutdown.

Lo que no tampoco llego a compartir del todo es la afirmación que haces cuando dices que no se pueden enviar y recibir datos a la vez por un socket. Lofter también lo ha dicho y ya me siento un bicho raro porque no llego a entender bien la razón por la que se dice. Así que pregunto:

-¿Es un problema de concurrencia?
Creo que no existe problema ya que el sistema cuando recibe un mensaje lo almacena en un buffer. Y cuando le decimos que envíe un mensaje lo escribe en otro buffer. Por lo tanto estamos leyendo y escribiendo de zonas de memoria distintas.

Por otro lado se me ocurre que el problema puede venir por leer y escribir del mismo descriptor a la vez. Pero creo que un socket es un descriptor muy especial (no lleva asociado un fichero físico) y sí permitiría hacer esa operaciones a la vez.

-¿Problema físico de simultaneidad?
Es posible. A día de hoy la simultaneidad de operaciones es un hecho alcanzable para muy pocos. Pero aún así podría ser posible.

La simultaneidad es posible que sea un tema un poco bobo pero ya que salió lo discutimos a ver que sacamos algo en claro.

Si me he dejado algo (espero que no), lo meto en otro post más adelante que este ya quedó muy largo.

Salu2.

🗨️ 12
Stendall
🗨️ 11
Velaznito
🗨️ 2
FreeBSD
FreeBSD
🗨️ 7
anthrax
🗨️ 1
FreeBSD
Stendall
🗨️ 3
Stendall
🗨️ 2
FreeBSD
🗨️ 1
Stendall
anthrax

una cosa que me he dado cuenta es que no en todos los servidores ftp el puerto origen del servidor es siempre el 20 (en el flujo de datos, no en el de control). Eso esta bien !!!? :-?

He visto puertos origen bastante elevados, del orden del 40000
No me estoy refiriendo a cuando el cliente se conecta de forma pasiva, porque entonces las conexiones se hacen algo diferentes, sino al modo "normal", el que no es pasivo. En el modo pasivo es el cliente el que conecta al server para recibir los datos por puertos bastantes altos (ni el cliente ni server usan el 20).

Saludos 8)

🗨️ 1
Stendall

a mi tambien me ha pasado, no se si es conforme a las RFC, en todo caso como el puerto de la conexión de datos lo pasa el servidor de ftp a traves de la conexión de control (21), no hay problemas con los clientes, a lo mas con los firewall.
Yo me di cuenta de esto precisamente por que en la epoca que usaba el windows 2000 para firewall y nat, no podia transferir datos desde cierta ftp, hasta que añadí una regla para el puerto que usaba ese servidor, el 1023.

Un saludo.