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.
