Banda Ancha EU

Comunidad de usuarios
de fibra, móvil y ADSL

hosting en interdominios
166 lecturas y 26 respuestas
  • Cerrado

    Pregunta sobre conceptos TCP/IP

    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 es antiguo y puede contener información obsoleta. Abre un nuevo tema para publicar tu mensaje.
    • Cerrado

      [Editado]

      una de las cosas que hay que tener un poco clara en este…

      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 ... :(

      • Cerrado

        Lo que digo, es cuando una conexion esta ya en ESTABLISHED…

        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.

        • Cerrado

          [Editado]

          Ya veo que tienes bien todos o casi todos los conceptos ;)…

          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)

          • Cerrado

            Me referia a que eran protocolos de capa superior, de capa…

            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

      • Cerrado

        Me da un poco de cosa añadir algo a tu buena y generosa…

        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.

          • Cerrado

            Me refiero a que en MS VISUAL C++ 6.0 venden una interfaz…

            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.

    • Cerrado

      [Editado]

      Puedes enviar y recibir pero no simultaneamente, cuando creas…

      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.

      • Cerrado

        Hace tiempo que no programo y otro tanto convaleciente pero…

        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.

        • Cerrado

          [Editado]

          Un socket cuando se crea es bidireccional por defecto, se…

          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...

          • Cerrado

            Hola Stendall, un placer saludarte de nuevo y espero que…

            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.

            • Cerrado

              [Editado]

              Reciprocamente encantado de saludarte a ti, y espero que lo…

              Reciprocamente encantado de saludarte a ti, y espero que lo de tu convalecencia no sea nada y puedas estar en la brecha de nuevo y recuperado.

              En cuanto a tu explicación, no tengo practicamente nada que objetar, en todo caso matizar, si no lo he dejado mas claro con anterioridad como se establecen las conexiones tcp (intercambio de paquetes udp por un socket distinto al de la conexion final de tcp), es por que prefería intentar dejar la explicación a un nivel un poco mas "alto" de protocolos e ir directo a lo de la bidirecionalidad, pero tu has hecho un gran trabajo al respecto.

              El uso de mas de un canal para separar la transferencia de datos y el de control entre los dos puntos no es necesario como bien dices, se puede utilizar perfectamente uno solo, todo radica en que la aplicacion que hace de cliente y la que hace de servidor utilicen un mismo protocolo (entendiendo protocolos de nivel superior a la capa de transporte o subprotocolos, estandard como el http o definidos por el programador a la hora de desarroyar la aplicación) y en cada momento cada extremo de la conexión espere datos cuando el otro estremo los vaya a mandar y viceversa, ejemplos de esto hay muchos, hay juegos, troyanos, aplicaciones de monitorizacion de red etc.. que se apañan perfectamente con una sola conexion para todo, datos y control.

              Voy a intentar matizar el ejemplo que has puesto del servidor ftp, si me equivoco en cualquier cosa corrigeme, ya digo que hace tiempo que no programo el tema de redes desde C o similares.
              En el caso del FTP (cualquier otro podría servir), una vez establecida una conexión por tcp, si le pedimos al servidor un fichero, cuando este empieza a mandar los datos del fichero, el cliente no debe mandar a cada paquete o fragmento que le llega un ACK, de eso se encarga la capa de tcp.
              Así pues, visto desde la capa de ftp, es perfectamente posible y de hecho creo recordar que es así como funciona, el servidor manda continuamente datos de un fichero hasta finalizar la transferencia, sin que el cliente mande un solo paquete de conformidad a cada dato recibido, ya digo que de la integridad, ordenación, reintentos por perdidas etc se encarga el tcp, exactamente igual a la inversa, cuando el que manda es el cliente para subir algún fichero a la ftp.

              Esto se hace así por comodidad, el usar 2 conexiones, una para control y otra para datos porque desde el punto de vista del programador le da simultaneidad o full duplex, realmente la simultaneidad de 2 o mas conexiones en comunicaciones es algo que el la practica no se da (en todos los medios fisicos de red y capas de transporte que conozco los datos realmente van uno detras de otro y si hablamos de equipos, tanto routers u otros como ordenadores, las cpu realmente solo pueden tratar un dato por vez), pero al dejar a la capa y pila de tcp el transporte, ordenación de paquetes etc.. de varias conexiones, se le crea la ilusion de simultaneidad al programador y desde su punto de vista es mas facil la programación.
              Para hacer lo que comentabas de la 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, hace falta otra aproximación a el modo de funcionamiento del ftp, haría falta que el cliente o el servidor cuando mandan archivos, en vez de mandarlos continuamente sin esperar confirmación desde el otro lado, el que manda los ficheros hiciese pausas en la transmision cada cierta cantidad de bytes, o sea, fragmentar el archivo, cosa de la que ahora se ocupa el tcp, y ponerse en modo de escucha para esperar o bien una confirmacion de recepción o transmisión por parte del otro equipo, o bien un comando de cancelación para abortar la transferencia y que haga volver a ponerse al servidor en modo comandos.

              Esto es así, por que si bien las conexiones de tcp son half duplex, una vez establecida si un equipo esta mandando datos, no puede al mismo tiempo esperarlos por el mismo socket o conexion, para como decias mandarle una orden de cancelación, por eso es por lo que hace falta que o bien el protocolo haya tenido en cuenta tal eventualidad y haya establecido unos patrones de pausa en la transmisión para ponerse en modo recepción (cada tantos paquetes de cierto tamaño transferidos o recepcionados, etc..), o bien hayan implementado otro canal o conexion para estos menesteres, en http como hasta hace poco no se implementaban conexiones persistentes, para cancelar la transferencia de un archivo de una pagina web, se mandaba un RST por tcp cerrando la conexión desde el cliente y santas pascuas, si el cliente queria volver a ver esa pagina por que hacia un reload desde el navegador, o pinchaba en un link de la pagina que estaba a medio cargar, volvia a establecer una conexion con el servidor web y punto, sin embargo ese aproximamiento no es valido en ftp, por la sencilla razón de que si cancelamos las transferencias a base de cerrar la conexión, tendriamos que volver a hacer el login y se ralentiza un monton el asunto, aparte que hace mas inseguro el trafico al estar mandando continuamente el login y el password por internet cada vez que recibimos un archivo y lo cancelamos, o simplemente intentamos cambiar de directorio antes de haber recibido el listado del actual.

              En tcp y udp creo recordar que hay dos formas de orientar la recepcion de datos, bloqueante o no bloqueante, es decir, cuando haces un send y mandas datos, la funcion sale inmediatamente despues de haber mandado los datos, o da error si no ha podido mandarlos en el caso del udp, se hayan o no conseguido transmitir los datos, esto es así por que de eso se encarga la pila de tcp, así, aunque los datos realmente estén a la espera en la pila de tcp, el programa no se bloquea y puede seguir su ejecución, sin embargo cuando lo que se hace es ejecutar un recv, a la función se le pasa como parametro un buffer con capacidad suficiente para albergar los datos que reciba, pero el programa no sale de la función hasta que no ha recibido un paquete entero de datos desde el otro lado, así que la ejecucion de el programa queda detenido en ese punto, y si es un software monotarea, no puede hacer nada mas hasta que no reciba los datos que esperaba, esto tambien incluye ejecutar cualquier comando para cancelar el recv y pasar a hacer otras cosas, como mandar un comando de cancelacion por esa conexión al otro equipo, que es lo que comentabas en el caso del ftp.
              El metodo no bloqueante, hace uso de unos descriptores o flags, que hacen que el programa no tenga por que esperar datos y pueda seguir con su ejecución normalmente, si no que es la implementación de la pila de tcp la que le avisa al programa cuando está recibiendo datos con destino a ese puerto y socket para que el programa se ponga en modo de escucha y reciba esos datos antes de que la pila de tcp se vea desbordada y empiece a descartar paquetes, algo parecido a lo que hacen los wrappers de linux, que permiten que no se ejecute el demonio que debe de aceptar la conexión antes de que esta se produzca, solo que en el caso de windows no hay mas remedio que tener en todo momento el servidor o la aplicacion corriendo y a la espera de los datos (bloqueante o no).
              Espero haberte aclarado un poco el tema de lo que hablabas, no es un problema de concurrencia, s un problema de parada de toda la aplicación cuando esta esperando datos de el otro lado, y no se sale de ese bloqueo hasta que se reciben todos los datos correspondientes a esa trama, por eso normalmente se usa la conexión de control, ademas, el uso de una conexión de control, posibilita que una sola se pueda utilizar para controlar (valga la redundancia), no una si no multiples conexiones de datos, en este sistema se utiliza un metodo de escucha que puede ser bloqueante o no en la conexión de control por queno bloquea la transmision o recepcion de datos, mientras las de datos estan a lo suyo enviando o recibiendo y desde la de control, se pueden mandar comandos para cancelar alguan de ellas, todas, se pueden pasar los parametros para una conexión nueva de datos etc..

              Espero no haber liado demasiado el tema, que yo tampoco lo tengo demasiado fresco.

              Un saludo y cuidate.

              Editado.
              No habia cerrado el < i > .

              • Cerrado

                Bueno, siendo más breve: las conexiones tcp son full duplex,…

                Bueno, siendo más breve: las conexiones tcp son full duplex, independientemente de la aplicación o de si es un ordenador con un solo proceador. Es decir, si el programa pudiera ejecutarse simultáneamente (ej: multihilo, multiproceso...), podría escribir y leer a la vez del socket, de hecho lo que dices de:

                >>[...] por eso es por lo que hace falta que o bien el protocolo haya tenido en >>cuenta tal eventualidad y haya establecido unos patrones de pausa en la >>transmisión para ponerse en modo recepción (cada tantos paquetes de >>cierto tamaño transferidos o recepcionados, etc..), o bien hayan >>implementado otro canal o conexion para estos menesteres, en http como hasta hace poco no se implementaban conexiones persistentes [...]

                Se podría hacer mediante un hilo o proceso lector y otro escritor, con un sólo canal. ¿por qué no se hace? En un caso, porque es más facil lo otro y en otro porque normalmente son modelos cliente/servidor, que no tienen la necesidad de hablar a la vez, sino de pregunta/respuesta.
                De hecho en http, las conexiones persistentes, con pipelining, se basan en hacer todas las peticiones mientras se van descargando los objetos (que se guardan en los buffers del s.o).

                >> [...] sin embargo cuando lo que se hace es ejecutar un recv, a la función se le >>pasa como parametro un buffer con capacidad suficiente para albergar los >>datos que reciba, pero el programa no sale de la función hasta que no ha >>recibido un paquete entero de datos desde el otro lado, así que la ejecucion >>de el programa queda detenido en ese punto, y si es un software >>monotarea, no puede hacer nada mas hasta que no reciba los datos que >>esperaba, esto tambien incluye ejecutar cualquier comando para cancelar el >>recv y pasar a hacer otras cosas, como mandar un comando de cancelacion >>por esa conexión al otro equipo, que es lo que comentabas en el caso del >>ftp.

                Existe una llamada del sistema, "select", que permite escuchar en varios descriptores a la vez (incluido sockets, teclado y demás...), asi que no necesariamente se queda bloqueado.

                Conclusión: Estoy de acuerdo con FreeBSD, incluído en que son direccionales (full-duplex).

                • Cerrado

                  Aunque ya digo que hace mucho que no miro el tema ;).…

                  Aunque ya digo que hace mucho que no miro el tema ;).
                  Buscando he encontrado esto:

                  www.ussg.iu.edu/hypermail/linux/net/0004.1/0120.html

                  Creo que se puede fiar uno del tema, entre otros, Alan Cox contesta a la pregunta de si los socks tcp son full duplex.

                  La cuestión por lo visto, es que para hacerlo full duplex sin threads es necesario usar el select, y si se quiere hacerlo con socks bloqueantes hay que hacerlo con varios threads.

                  En fin, mea culpa, está visto que no se pueden abandonar las cosas por un tiempo que luego pasa lo que pasa.

                  Un saludo.

              • Cerrado

                Pillar una aplicación en una llamada bloqueante no aparece en…

                Pillar una aplicación en una llamada bloqueante no aparece en ningún libro de programación. Siempre hay que tener la posibilidad de escapar. Una función que permite eso es select que testea cuando se producen cambios en un descriptor (sea cual sea). De esa manera no bloqueas la aplicación. Seguramente existan más llamadas o librerías que permitan un manejo más avanzado en descriptores que esta simple función.

                Realmente hablamos de leer o escribir de un descriptor a la vez...pero como he dicho un descriptor muy singular que tiene un buffer para lectura completamente independiente del buffer de lectura...Puedo aceptar que el multiproceso no es 100% (en la mayoría de las maquinas) y que la limitación posible es en la CPU, no en bloqueos de aplicaciones o zonas críticas de memoria. No sé, parece el cuento de nunca acabar.

                Respecto a lo del FTP, obviamente hablaba de un FTP ficticio. Sólo era para explicar que es posible con un solo socket. La forma que tu explicas es el verdadero funcionamiento. De hecho yo también te he comentado que siempre se suele optar por la solución de señalización por canal común (conexiones separadas, que el nombre puede engañar), pero que se opte por una solución no quiere decir que sea la única.

                En el tema de la simultaneidad, cuanto dices que no se da simultaneidad en las conexiones...ahí si te digo que andas equivocado o que has cerrado mucho el mundo. Es posible que un PC no lo consiga, o que un simple router ADSL tampoco...pero si no fuera posible que un dispositivo maneje dos conexiones a la vez no hablaba por teléfono o no se conectaba a Internet ni Dios. De hecho, manejan muuuuuuuuuchas más. Y en medios físicos ya no digamos: fibra óptica o el propio aire. No podemos tener un cielo cada uno para hablar por el móvil. Y tampoco le podemos decir a ese señor que tenemos delante dando gritos en el móvil que cuelgue para llamar nosotros. Hay dos técnicas básicas para compartir medios de transmisión: 1) MDF (Multiplex por división en frecuencia) y MDT (Multiplex por división en el tiempo). La primera se basa en enviar cada señal en una frecuencia diferente (radio, por ejemplo) y la segunda en enviar cada señal en un instante de tiempo diferente (como en las redes Ethernet, por ejemplo). La segunda no da simultaneidad, la primera sí. Podrías pensar que te cuento bobadas. pero aunque parezca mentira hubo (y hay) topologías de redes de área local que se basan en MDF.

                Aunque parezca que estas cosas están lejos de las comunicaciones de Internet, realmente es lo mismo. Todo se basa en los mismo fundamentos.

                Me he perdido un poco y no puedo quedarme mucho más, perdona que me haya ido del tema. Sólamente me gustaría hacerte una pregunta:

                :-? ¿DÓNDE ESTÁ EL DOCUMENTO DE SQUID? :-?

                Un placer, como siempre.
                Salu2.

                • Cerrado

                  madre mía y pensaba que yo me enrollaba ... :) Me parece que…

                  madre mía y pensaba que yo me enrollaba ... :)

                  Me parece que si llego a saber que a raiz de mi post, se generaria este hilo de autenticos RFC's sobre sockets, conexiones TCP y demas herbas, me callo ;)

                  La verdad es que no termino de entender todo lo que aqui se ha dicho, me lo tendre que releer...

                  Por cierto, a ver si cuelgas YA la docu sobre el SQUID (como dice el compadre FreeBSD ; ) ). Así me decidiria a hacer el de QoS en GNU/Linux

                  Saludos 8)

                  • Cerrado

                    ¿Con el tiempo que llevaba sin poner un mensaje por aquí y me…

                    ¿Con el tiempo que llevaba sin poner un mensaje por aquí y me llamas pesado? :-( :-( :-(

                    Salu2.

                • Cerrado

                  Jejejeje, ya digo que teneis toda la razón. En cuanto a la…

                  Jejejeje, ya digo que teneis toda la razón.

                  En cuanto a la simultaneidad como el caso de comentas, es que depende del enfoque, cualquier cantidad de canales que sean multiplexados por un solo canal yo no lo consideraría simultaneo, por que o no ocurre en el mismo lapso de tiempo, o no ocurre en la misma capa de transporte aunque a nosotros nos pueda parecer simultaneo.
                  Por ejemplo, si tomamos un troncal de fibra optica con mil canales, todos pueden estar transmitiendo al tiempo, pero para que eso sea posible, al final y al principio debe de haber o mil equipos con enlaces de fibra optica, o un circuito que a su vez tenga mil subcircuitos que procesen la señal de cada canal independientemente, u otro dispositivo que sea capaz de transformar 1000 canales de X ancho de banda, por 1 canal de ancho de banda 1000X, lo que creo que a dia de hoy es practicamente imposibile que un equipo final del tipo que sea soporte mas de una via de datos simultaneamente por un solo canal, es decir, un ordenador puede tener 10 tarjetas de red, pero al final, aunque las tarjetas sean autonomas y tengan un buffer, el ordenador tendrá que leer los datos que le llegan de todas, pero tendrá que leerlo por un orden, por que a fin de cuentas, el bus de datos del ordenador solo puede direccionar 1 puerto o direccion de memoria por vez (dma aparte, pero es lo mismo, por que si se esta procesando los datos del dma no se pueden enviar datos al tiempo), y lo que realmente se hace es multiplexar la cpu distribuyendo su tiempo al procesar cada uno de los canales, creo que el full duplex en comunicaciones no pasa de ser en la inmensa mayoría de los casos mas que una ilusion optica :)

                  Un saludo.

                  • Cerrado

                    Se me habia olvidado contestar el tema. Va avanzando a buena…

                    Se me habia olvidado contestar el tema.
                    Va avanzando a buena velocidad, ahora que estoy de baja y tengo mas tiempo, aprovecho para adelantar trabajo sobre el, así y todo no penseis que va a estar en una o dos semanas, cada parte minuscula del squid es como para hacer un howto bien majo, solamente de el tema de autentificaciones o filtrado de cabeceras etc... se podia hablar laaargo y tendido, pero teneis suerte que esta planteado como FAQ, que si no.... :)

                    Un saludo.

                      • Cerrado

                        [Editado]

                        Me liaré la manta a la cabeza, en todo caso con enrollar me…

                        Me liaré la manta a la cabeza, en todo caso con enrollar me refiero a profundidad, cantidad de puntos tratados etc, nunca a divagaciones oniricas como en el foro.

                        Así que vale, pero luego no quiero arrepentimientos.

                        Un saludo.

                        Editado.
                        Por amor de Tux, había puesto enrollar con "y".

                • Cerrado

                  Aparte de mi metedura de pata con el tema del half y el full,…

                  Aparte de mi metedura de pata con el tema del half y el full, creo que me has interpretado mal o mas bien que yo no me he sabido expresar.
                  Con bloqueos no me referia en ningun caso a cuelgues del sistema o aplicacion por no saber contemporaneizar si le llegaban datos en un sentido y en otro "simultaneos" (ahora entiendo las cruces que te hacias con el tema de las concurrencias, simultaneidad etc), me refiero a funciones de sockets que cuando se ejecutan no salen hasta que no se ha completado una trama de datos o ha llenado el buffer asignado en esa funcion y es entonces cuando devuelven el control a la aplicacion para que pueda procesar esos datos, es algo que como bien dices se puede solucionar con select, pero creo que no con fork, es decir, fork serviria para crear en memoria otra rutina o aplicacion con los mismos datos, que se seguiria ejecutando a partir de el punto donde se llamo al fork en el padre (no he leido practicamente nada sobre el tema, mil perdones si me equivoco), pero la tarea hija no podria compartir el descriptor al tiempo que el padre CREO, si esto es así, fork sirve para el caso de un servidor, en el que puede mantener abierto y a la escucha continuamente un sock en un puerto por el que se conecten los clientes y una vez que tiene una peticion de conexion, hacer un fork y pasar la peticion a una tarea hija, creo que es mas o menos como funciona, pero no me hagais mucho caso, que hoy cuanto mas pienso las cosas menos claras las tengo.

                  Un saludo.

      • Cerrado

        [Editado]

        una cosa que me he dado cuenta es que no en todos los…

        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)

        • Cerrado

          a mi tambien me ha pasado, no se si es conforme a las RFC, en…

          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.