Tema
Ciclo de vida del software y dependencia del proveedor
Dentro de la faceta Tema, la inteligencia temática Ciclo de vida del software y dependencia del proveedor conecta artículos que comparten un tema específico, un enfoque en señales o una temática de seguimiento. La página ofrece a los lectores un recorrido más completo a través de informes relacionados, evidencia de fuentes, actores del mercado e implicaciones de infraestructura, con el contexto suficiente para entender por qué el tema es relevante en los movimientos corporativos, las decisiones de gobernanza, la exposición regional y el riesgo operativo. Los lectores pueden comparar señales recurrentes, organizaciones implicadas, evidencia pública, contexto de mercado, continuidad del servicio, contratación, competencia, cumplimiento y cuestiones de planificación estratégica que subyacen al tema, en lugar de quedarse en una lista escueta de artículos relacionados. Explica de qué trata el tema, qué actores o políticas de infraestructura están implicados, qué evidencia respalda la cobertura y por qué puede ser relevante para operadores, clientes, inversores y lectores interesados en las políticas.
Historia de Internet
El receptor que elegía qué llegaba primero
En MTP, el remitente podía preguntar `MRSQ ?` y recibir `215 T Text first, please`. Esa respuesta obligaba a entregar y almacenar el cuerpo antes de nombrar a los destinatarios. Otro receptor prefería reunir primero las direcciones y aceptar después una sola copia del texto. El…
Historia de Internet
El byte que el remitente no envió: cómo FTP MODE C reconstruía el relleno desde TYPE
El receptor encuentra una cantidad, pero no un byte que copiar. No falta ningún fragmento: en el modo comprimido de FTP, la propia ausencia cerraba la instrucción. El valor estaba fuera de esa secuencia, fijado por el tipo de representación de la sesión.
Historia de Internet
La ruta que retrocedía en cada relevo
Cuando el relevo ONE recibió `@ONE,@TWO:JOE@THREE`, no debía reenviar la cadena intacta. Quitó su propio nombre del extremo izquierdo del forward-path y añadió al reverse-path el nombre con el que lo conocía el entorno de salida. La instrucción pendiente perdió un tramo; el…
Historia de Internet
El byte que tuvo que aparecer dos veces: cómo FTP insertó límites de registro en un flujo
Al final de un bloque de lectura aparece un byte con todos sus bits a uno. Todavía no es dato ni control. FTP obligaba al receptor a esperar: una segunda copia devolvía un único byte literal al archivo; un valor pequeño convertía la pareja en final de registro, final de archivo o…
IETF
Ray Bellis y el proxy que tenía que dejar pasar lo desconocido
El cliente pide una respuesta DNS grande; el servidor la entrega; el equipo intermedio devuelve una versión recortada que parece completa. Ese falso éxito es más peligroso que un error visible. La RFC 5625 de Ray Bellis convirtió esta clase de fallo en una regla de gobierno…
Historia de Internet
La página ausente que no era una página de ceros: cómo FTP STRU P transportó huecos entre hosts
Un receptor obtiene una página y después otra con un índice posterior. La posición intermedia no apareció en la conexión. FTP no obligaba a diagnosticar pérdida ni a rellenarla con ceros: con `STRU P`, la ausencia podía ser una propiedad deliberada del archivo.
Historia de Internet
El fragmento más corto que seguía siendo correcto
Tres fragmentos salieron del mismo datagrama IPv4. El primero llevaba Loose Source and Record Route y Record Route; los otros dos sólo llevaban la primera opción. Sus campos IHL no coincidían. Tampoco debían coincidir: el bit Copy del tipo 131 ordenaba que la ruta de origen…
Historia de Internet
El cambio de nombre que aún no había ocurrido: cómo FTP dejó un archivo entre RNFR y RNTO
FTP podía responder afirmativamente y seguir esperando. `RNFR` aceptaba la ruta antigua; el código `350` dejaba la acción pendiente; `RNTO` aportaba la ruta nueva. Hasta que llegaba la respuesta final, el protocolo no autorizaba a confundir una intención bien formada con un…
Historia de Internet
El quinto octeto pertenecía a dos palabras
En una transferencia `TYPE L 36`, el quinto octeto no era propiedad de una sola palabra. Sus cuatro primeros bits cerraban la primera unidad lógica de 36; los cuatro restantes abrían la segunda. FTP podía transportar dos palabras de aquella máquina en nueve octetos de ocho bits…
Historia de Internet
La sesión que sobrevivió al cambio de sistema de archivos: FTP SMNT separó identidad y espacio de nombres
Una ruta puede conservar todas sus letras y dejar de señalar el mismo objeto. FTP dejó esa posibilidad a la vista con `SMNT`: una orden opcional que cambiaba la estructura de archivos activa sin borrar el inicio de sesión, la contabilidad ni los parámetros de transferencia. En…
Historias
FORT de LACNIC valida ASPA. Su canal hacia los routers arranca en la versión 0
LACNIC presentó un validador capaz de llevar datos ASPA hasta los routers. La versión publicada deja ese recorrido detrás de un parámetro cuyo valor inicial es cero. No es una contradicción: es la frontera entre entregar una capacidad y demostrar que está activada.
Historia de Internet
El mensaje que quiso llegar antes que al buzón: cómo SMTP abandonó la entrega al terminal
El SMTP temprano podía hacer algo más ambicioso que depositar correo. Un emisor podía pedir que el texto apareciera en el terminal activo del destinatario, que el buzón actuara como alternativa o que ambos recibieran una copia. Aquellas órdenes convirtieron una condición fugaz…
Historia de Internet
La contraseña era correcta, pero faltaba decidir la cuenta
Un servidor FTP podía aceptar `PASS` y aun así no declarar iniciada la sesión. Respondía `332` y esperaba `ACCT`. La pausa no dudaba necesariamente de la identidad: dejaba pendiente otra decisión, la del contexto local al que debía atribuirse el acceso o una operación concreta.
Historia de Internet
El límite que miraba en dirección contraria
El 1460 escrito por un cliente en su SYN no limita lo que el cliente va a enviar. Limita lo que está dispuesto a recibir del servidor. En el SYN-ACK puede aparecer 1200, y ese segundo valor manda en la otra dirección. TCP colocó dos límites en el mismo apretón de manos, pero…
Historia de Internet
La publicación que debía conservar su nombre: cómo NNTP acotó una respuesta final perdida
El cliente ya había enviado hasta el punto final. El servidor pudo aceptar el artículo y emitir `240`, pero el corte se llevó la respuesta. Volver a mirar la lista pública no resolvía el enigma: una moderación podía retrasar la aparición. NNTP hizo algo más preciso que prometer…
IETF
El servidor aplazó el coste de creer: las defensas TCP ante el SYN flood
Un servidor TCP asumía memoria en cuanto un desconocido llamaba. El RFC 4987 explica cómo retrasar ese gasto hasta que el supuesto cliente demuestre, al menos, que recibió la respuesta.
Historia de Internet
El hueco que quizá no contenía ningún dato
Faltaban varios números en la secuencia, pero eso no bastaba para contar las pérdidas de la aplicación. En DCCP también se numeraban los paquetes dedicados a confirmar otros paquetes. Esa decisión permitía observar la pérdida de los informes y, al mismo tiempo, obligaba a…
Historia de Internet
La escritura que regresó antes de estar a salvo
El servidor había contestado con éxito, pero el cliente aún no podía soltar los bytes. Podían vivir solamente en una memoria que desaparecería con el siguiente reinicio. NFS versión 3 convirtió esa diferencia en un contrato visible: rapidez ahora, custodia en el cliente y una…
IETF
El primer número de secuencia no podía ser solo un reloj: la defensa ISN de TCP
Cada conexión TCP empieza publicando un número. Cuando ese número seguía con demasiada claridad un reloj global, un atacante que no veía la conexión aún podía predecir suficiente estado para hacerse pasar por un par.
IETF
El reset tuvo que demostrarlo: la defensa Challenge ACK de TCP
Antes, a un reset falsificado le bastaba caer en algún punto de una ventana de recepción móvil. El RFC 5961 exige que las señales TCP destructivas demuestren que reflejan el estado actual del par antes de que un número adivinado borre una conexión duradera.