Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
La elaboración de este Proyecto Fin de Carrera ha supuesto un coste apreciable que ya está dando sus primeros frutos. Con él he intentado crear una herramienta capaz de ejecutarse en multitud de pequeñas plataformas personales (incluso sencillos prototipos informáticos) poco difundidas y así cubrir el vacio de conectividad al que hasta ahora estaban condenadas. Me propuse diseñar un entorno compacto y sencillo de utilizar pero, a la vez, eficiente y capaz.
Creo haberlo logrado. A pesar de la longitud del código fuente, el ejecutable final del programa es lo bastante reducido como para ser almacenado en una EPROM, y la cantidad de memoria RAM que necesita para funcionar es completamente configurable. Los servicios implantados (DNS, TELNET, FTP, SMTP y POP3) cubren sobradamente las necesidades de comunicación de cualquier usuario típico. En el futuro se incorporarán otras aplicaciones, como NEWS, y se realizará una API para poder utilizar software ya realizado por otras personas (en especial, HTTP).
Por otra parte, este Proyecto ha sido diseñado para ser mantenido y mejorado durante largo tiempo, y por un equipo compuesto por numerosas personas. Su arquitectura es muy modular y su fin último es servir de base para la creación de aplicaciones avanzadas por terceras partes. Una vez que este Proyecto haya sido evaluado por el Tribunal, y si éste y mi Tutor no se oponen, será declarado FREEWARE bajo la licencia de distribución de librerías de GNU; el código fuente será hecho público.
A pesar de que el esquema multitarea implantado puede parecer complejo y poco eficiente, la realidad constata lo contrario. Las pruebas efectuadas demuestran que una CPU Motorola 68030 a 16Mhz es capaz de transferir unos 193Kb por segundo, en ambas direcciones. Esa velocidad es muy superior a la de cualquier MODEM para línea telefónica. Con la tecnología actual los MODEMS en el mercado no superan nunca los 16Kb/s, en el mejor de los casos (33.600bps y normas V.42 y V.42bis). Existe, no obstante, un detalle que el usuario de esta herramienta debería conocer:
Con la implementación actual cada enlace TCP puede contener hasta 4Kb de datos no confirmados. Esta es, por tanto, su ventana de transmisión. Las repercusiones que ello tiene sobre la eficiencia del enlace son importantes y deben tenerse en cuenta.
En general nuestra velocidad de transmisión de información será máxima cuando el retardo ida y vuelta de la red sea igual o inferior a, aproximadamente,
Btx - MTU
--------- segundos [1]
V
donde 'Btx' es el tamaño del búffer de transmisión, 'MTU' es el tamaño del mayor datagrama que puede atravesar la red y 'V' es la velocidad de transferencia del MODEM, en bytes por segundo. Con un MODEM de 14.400bps (sin V.42 ni V.42bis), una MTU de 1008 bytes y un búffer de 4Kb, el resultado de la ecuación es algo más de dos segundos. Es decir, cualquier red cuya suma de tiempo de propagación y de procesado local en los ordenadores sea superior a dos segundos nos estará frenando. La transferencia, para ese caso, se realiza a ráfagas (depende de la estrategia de confirmaciones del receptor) y su tasa media converge, aproximadamente, a
Btx - MTU
--------- bytes por segundo [2]
D
donde 'D' es el retardo de la red. Si para los parámetros anteriores el retardo total fuese de cuatro segundos, transmitiríamos a una tasa aproximada de 772 bytes por segundo o, de forma equivalente, al 54% de la posibilidades del MODEM. De cara al usuario resulta más intuitivo trabajar con el retardo total, o tiempo transcurrido desde que iniciamos la transmisión de un segmento hasta que nos llega su confirmación. Las ecuaciones aproximadas son las mismas, eliminando el término MTU.
La solución más simple consiste en incrementar el tamaño de los búfferes. El problema de esa modificación es que la demanda de memoria RAM se incrementa. Dependiendo del equipo disponible puede ser una buena idea. Se eligió un tamaño de 4Kb porque las máquinas a las que accedí para las pruebas están topológicamente lo bastante cerca como para no incurrir en un retardo apreciable.
De todos modos no hay que olvidar que todo lo dicho es válido sólo
para cuando somos nosotros los transmisores. Pero el contexto de
aplicación de este software será, típicamente, el opuesto. Seremos
receptores de información. Mi capa TCP ha sido diseñada para sacar
el máximo partido de ello, utilizando técnicas agresivas de
actualización de ventana para forzar a la máquina remota a que
mantenga el índice de ocupación de nuestro canal de llegada al
máximo. En otros contextos dicha técnica sería considerada
perjudicial, pero dado que estamos trabajando con un canal serie
de baja capacidad la sobrecarga global de la red es completamente
despreciable.
Bibliografía
[RFC1122] RFC1122: "Requirements for Internet Hosts --
Communication Layers"
Robert Braden
Octubre 1.989
[RFC1123] RFC1123:"Requirements for Internet Hosts --
Application and Support"
Robert Braden
Octubre 1.989
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
