Ventajas del TCPIP en la red (1)

   Hola a todos:

   Hasta ahora se ha hablado mucho del TCP/IP: si es lo que se utiliza en
Internet, si es muy potente, si es el futuro, etc. Lo que no se si se ha
dicho es como puede cambiar la actual red usando TCP/IP de forma practica,
es decir, lo que el usuario y el administrador van a notar. Veamoslo punto
por punto. Empezare en este mensaje con la base de todo: el protocolo IP.

  ======
    IP
  ======

    IP significa Internet Protocol, es decir, protocolo de inter-red (no
protocolo de Internet como algunos dicen). IP fue diseado para unir varias
redes con distintos protocolos cada una en una unica red por encima, llamada
la inter-red o internet (fijese que es i minuscula). Entonces todas las
estaciones parecen estar en la misma red, aunque fisicamente no esten realmente
conectadas por un cable, o por un enlace de radio.

    Veamos como afecta esto en un caso practico (los nombre de estaciones son
tomados al azar).

    En la provincia XX tengo una BBS llamada EA2XX-2.
    En la provincia YY tengo una BBS llamada EA2YY-2.
    Uniendo a ambas, en un monte, hay un nodo enlace EA2XY-1.

    Tenemos 2 usuarios, uno de cada BBS:
    EA2XXX es un usuario de EA2XX-2 y EA2YYY es un usuario de EA2YY-2.

    Graficamente, se puede ver como:

                             /==> EA2XY-2 <==\
    EA2XXX <--> EA2XX-2 <==/       /"""\       \==> EA2YY-2  <--> EA2YYY
    _____________________________/       \________________________________
 
    Digamos que ahora los <--> son los enlaces "lentos" (1200 baudios),
mientras que los <===> son lo "rapidos" (9600 bits por segundo).

    Los protocolos: serian AX.25 "puro" en los enlaces a 1200. En las
subidas a los nodos puede haber AX.25 puro, o NET/ROM + AX.25, depende.
Entre nodos deberia haber NET/ROM + AX.25 (NET/ROM es un protocolo que
funciona sobre AX.25 y que sirve para el intercambio de informacion entre
los nodos sobre que rutas hay disponibles, con que calidad, etc.)

    Bien, veamos el mismo esquema en una red TCP/IP. La configuracion no
cambia. Seria en todo caso recomendable que cambiara la velocidad de los
enlaces, especialmente de los usuarios, pero no imprescindible.

    Ahora lo que cambian son los protocolos. Todas las estaciones deben
tener ahora TCP/IP apoyado sobre AX.25. Ademas de su indicativo,
necesitamos ahora los numeros IP. Por suerte, se reservaron los numeros de
la serie 44.x.x.x para los radioaficionados a nivel mundial, de los cuales
los 44.133.x.x le corresponden a Espaa. El tercer numero de los 4 es el
codigo postal de la provincia. Voy a escoger sin embargo los numeros 1 y 2,
disculpandome si los numeros coinciden con los de alguna estacion real.

    EA2XXX, EAXX-2 y EA2XY-1 estan en la provincia 1.
    Su subred sera: 44.133.1.0. EAXX-2 sera 44.133.1.15, EA2XXX sera
    44.133.1.31 y EA2XY sera 44.133.1.1.

    EA2YYY y EA2YY-2 estan en la provincia 2.
    Su subred sera: 44.133.2.0. EA2YY-2 sera 44.133.2.8 y EA2YYY sera
    44.133.2.36

    El nuevo grafico:
                                44.133.1.1
  44.133.1.31   44.133.1.15  /==> EA2XY-2 <==\    44.133.2.8    44.133.2.36
    EA2XXX <--> EA2XX-2 <==/       /"""\       \==> EA2YY-2  <--> EA2YYY
    _____________________________/       \________________________________
 
   Que hemos conseguido, ademas de complicarnos la cabeza con un monton de
numeros mas? Bien, pronto lo veremos. De momento, todas las estaciones de
la red funcionan con un unico protocolo: IP. AX.25 queda como mero
"transportista" de la informacion de IP en cada uno de los enlaces. Pero
imaginemos ahora que se inventa un nuevo protocolo mas rapido entre BBS's
y nodos (por ejemplo, el nodo es un satelite). Pues se sustituye el AX.25
por el nuevo protocolo, Y NO HACE FALTA NINGUN CAMBIO MAS!. Sobre el nuevo
protocolo circulara IP lo mismo que antes lo hacia sobre AX.25.

   La primera ventaja de IP: INDEPENDENCIA FISICA, entendiendo por esto que
es tanto independiente de los dispositivos fisicos, de por donde va el cable
o como es, y tambien independiente de los protocolos que necesite para su
gestion.

   Y ahora la segunda sorpresa: con cuantas estaciones cree que podra conectar
EA2XXX, por ejemplo? Pues con 3: EA2XX-2, EA2YY-2 y EA2YYY (suponiendo que
las BBS's estan siempre activas, y que EA2YYY esta en ese momento activa).
Alguien se preguntara: y por que no con el nodo? En realidad si que puede
conectar con el nodo, pero este no hace mas que de "puente", se dedica a
que los paquetes a traves de el circulen. Pero suponemos que el nodo no
tiene porque ofrecer ningun servicio mas que el de puente: no necesita tener
mensajeria, etc.

    La segunda ventaja es la UNIFICACION DE LA RED. Ahora si que estamos en
red!, con AX.25 estamos en pequeas redes "taifas" que de vez en cuando,
por un corto espacio de tiempo, estan conectadas entre si .

    Pero sobre como funciona esta red "virtual" hablaremos mas despacio
en un proximo mensaje.

IMPORTANTE: si estas interesado en que siga esta serie, enviame un mensaje.
No seas vago, con un par de lineas basta. Si no hay gente interesada, igual
no sigo. No pienso llenar la red de bytes inutiles, y escribir un mensaje
de estos lleva su tiempo y su esfuerzo.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EURO

---------

Ventajas del TCPIP en la red (2)

   Hola a todos:

   En el anterior mensaje conte mi intencion de describir de una forma practica
para que nos puede interesar tener una red de TCP/IP, ya que hacer una
explicacion teoria no le dice nada a la mayoria de la gente.

   Y despues de esta buena intencion, monte un follon con un simple ejemplito
de dos BBS, cada una con un usuario, conectadas por un nodo.  Entendiendo que
te haces una idea despues de tanto numero IP, veamos para que sirven y como
funciona el tinglado para que puedas llegar a estaciones a las que no te puedes
conectar directamente.

   AVISO: Si te parece demasiado tecnico, no creo que sea necesario para las
siguientes partes, asi que puedes pasar directamente a la 3. Sin embargo te
digo: es mas dificil explicarlo que entenderlo.

   Aqui va de nuevo el grafico, para que no te pierdas.

                                44.133.1.1
  44.133.1.31   44.133.1.15  /==> EA2XY-2 <==\    44.133.2.8    44.133.2.36
    EA2XXX <--> EA2XX-2 <==/       /"""\       \==> EA2YY-2  <--> EA2YYY
    _____________________________/       \________________________________


   IP tiene capacidad para mandar un paquete, o una trama en terminologia IP,
a cualquier estacion IP, solicitando que le envie un paquete de respuesta. Esto
nos sirve para saber si una estacion esta activa en la red. El comando para
hacerlo, suele ser el 'ping'. Asi que EA2XXX haria primero:

   C:\> ping 44.133.1.15

   Si EA2XX-2 esta activo y contesta, nos aparecera un mensaje indicandolo, asi
como un tiempo. El tiempo es el que le ha costado al paquete ir y venir. De
esta forma no solo sabemos que el nodo esta activo, sino que podemos
imaginarnos por el tiempo de respuesta, si esta cerca o lejos, o si una
conexion va a ser rapida o lenta. Si EA2XX-2 no contesta, tras una serie de
intentos, se nos avisara de ello.

   Ahora pongamonos en el papel de IP. Primero se empaqueta la informacion a
enviar -en este caso la informacion la determina el programa ping-. El sistema
sabe su numero IP: 44.133.1.31, ya que nosotros se lo habremos suministrado (de
como conseguir nuestro numero IP ya hablaremos mas adelante). En cuanto al
destino, no hay ningun problema: nosotros se lo hemos indicado al hacer el
ping: 44.133.1.15.

   Vamos a suponer que nuestra maquina esta configurada para que cualquier
paquete dirigido a 44.x.x.x salga por nuestro puerto de radio (TNC, baycom o lo
que sea). Como la direccion destino es de la misma subred que la nuestra
(empieza por 44.133.1.) abriremos una conexion AX.25 para enviarle el paquete
IP directamente a la estacion destino.

   Ahora, para hacer una conexion AX.25 necesitamos los indicativos de ambos
participantes. La nuestra, se la habremos suministrado al sistema: en el
ejemplo, EA2XXX tendra que el puerto con numero IP 44.133.1.31 tiene asociada
la direccion AX.25 "EA2XXX-0".

   Pero, y el destino 44.133.1.15? Para eso necesitamos un mecanismo que nos de
la direccion AX.25 a partir de un numero IP, por lo menos para las estaciones
de nuestra misma subred. Bien hay varios de estos mecanismos, que ahora no
vamos a describir.  Supongamos que los tenemos en un fichero, para simplificar.
Ahi nos diran que a 44.133.1.15 le corresponde "EA2XX-2".

   Asi que nos conectamos con ese indicativo y le pasamos la trama o paquete IP
en un paquete AX.25.

   En el otro lado, en EA2XX-2, el nivel de AX.25 se da cuenta que es un
paquete IP, asi que se lo pasa al nivel de IP. IP observa su direccion de
destino, que es 44.133.1.15 y se da cuenta que el paquete IP es para si mismo.
Lo analiza y procesa, y como ha de enviar una respuesta, manda un paquete IP
de respuesta con direccion origen 44.133.1.15 y destino 44.133.1.31

   Este nuevo paquete IP se tratara de la misma manera, de forma que seguira
el camino contrario llegando el paquete al nivel IP de EA2XXX. Por supuesto,
EA2XX-2 debera tambien tener un fichero donde a 44.133.1.31 le corresponda
"EA2XXX-0" para saber a quien conectarse a traves del AX.25.

   Una vez en el nivel IP de EA2XXX, se mide el tiempo que ha tardado la
respuesta desde que se envio, y ping avisa al usuario.

   Complicadillo, eh? Pues, cualquiera que conozca el funcionamiento de IP me
va a decir que me he saltado muchas cosas. Pero no nos interesa mas sobre IP
(por el momento).

   "Pero, estas de broma?" me diras. "Todo este embrollo para comunicarte
con la BBS?". Y tendrias razon, si solo me pudiera comunicar con la BBS.
Ahora, el mas dificil todavia. Vamos a comprobar que llegamos a EA2YY-2.

   C:\> ping 44.133.2.8

y ping nos dice algo como:

   PING 44.133.2.8: 56 data bytes
   64 bytes from 44.133.2.8: icmp_seq=0 ttl=64 time=17 s

   Como es posible que 44.133.2.8, BBS de otra provincia, nos conteste? Ya he
dicho que una de las dos principales ventajas, sino la principal, era la
formacion de una super-red o inter-red o red "virtual" con todas las redes que
la forman, en este caso simplificado con 44.133.1.x y 44.133.2.x. Parece que
alguien o algo se ha encargado de pasar nuestro paquete a la estacion destino.
Veamos como ha sido.

   Ahora es el momento de decir que en cada red -o subred, como prefirais- de
una internet debe haber un ordenador llamado el "gateway" que es el que esta
conectado con "el resto" de la red.

   En este ejemplo el "gateway" de la red 44.133.1.0 es 44.133.1.1, es decir,
el nodo de la provincia. Pero para nosotros, nuestro "gateway" va a ser la BBS
que tengamos a nuestro alcance, que es la que va a poder conectar con el nodo
y, a partir de ahi, con el resto.

   En nuestro ordenador habra que indicarle cual es nuestro "gateway".  No nos
importa como se hace, eso depende del sistema en concreto. En el caso de
EA2XXX, su "gateway" es 44.133.1.15, es decir el numero IP de su BBS. En el
caso de EA2XX-2, su "gateway" es 44.133.1.1, el nodo de la provincia.

   Para terminar con el tema de los "gateway", decir lo siguiente, que es lo
esencial: una estacion envia los paquetes a dos destinos: si es una estacion de
su red, directamente a esa estacion; si es una estacion de OTRA RED, se lo
envia al "gateway" que es una estacion especial dentro de su red, que se
ocupara de enviarlo a su destino real.

   Cual es el camino entonces del paquete? Graficamente:

       44.133.1.31 --> 44.133.1.15 ==> 44.133.1.1 ==> 44.133.2.8

   El paquete o trama IP es el mismo durante todo el camino:

       Dir origen   Dir destino   Otros datos IP  Informacion enviada
       44.133.1.31  44.133.2.8    xxxxxxxxxxxxxx  yyyyyyyyyyyyyyyyyyy

   La explicacion seria: EA2XXX tiene que enviar la trama IP. La direccion
44.133.2.8 no es de su red, por lo que NO puede abrir una conexion AX.25 ya que
no tiene conexion directa. Asi que hace lo unico que puede: pasarle el paquete
IP a su "gateway" 44.133.1.15, con quien si puede abrir una conexion AX.25.

   Una vez pasado el paquete a traves de AX.25, EA2XX-2 se da cuenta tambien
que el paquete no es para el, y que no puede acceder directamente a su
receptor, ya que no esta en ninguno de sus dos puertos. Entonces se lo pasa a
su gateway 44.133.1.1 (no diremos mas veces que para pasarlo hay que abrir la
conexion AX.25 y saber el indicativo del destino).

   Cuando llega a EA2XY-1, a 44.133.1.1, este si conoce como mandarselo a
44.133.2.8: por su otro puerto. Se lo envia directamente.

   El paquete de vuelta con el mismo metodo seguira el camino inverso si los
"gateways" se configuran adecuadamente.

   Si EA2YYY esta activo, tambien podemos hacer un ping de 44.133.2.36.  El
procedimiento de circulacion del paquete es el mismo, pero con un paso mas.

   Seguiremos con otros aspectos de IP.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (3)

   Hola a todos:

   De nuevo con vosotros para proseguir con lo que pretendo sea una explicacion
practica de las capacidades del TCP/IP. En la primera parte hablamos de las
ventajas de IP: independencia de la red fisica y establecimiento de una red
"virtual": los paquetes llegan a todas las estaciones de la red independiente-
mente si te puedes conectar a ellas directamente o no.

   En la segunda parte descubriste que esto no era magia: dentro de cada subred
(la formada por los ordenadores que si pueden conectarse directamente) habia un
ordenador llamado el "gateway" que, conectado a otra redes, era el encargado de
enviar y recibir todo el trafico "externo" a la subred.

   Voy a comentar ahora algunos "flecos" sobre IP.

   IP NO ES FIABLE

   Se dice que IP es un protocolo no fiable. Esto quiere decir que si un
paquete se pierde por el camino, o llega despues que otro que se envio antes,
no se sabe:

       IP no controla que todos los paquetes enviados lleguen ni
       que lleguen en el orden en que fueron enviados.

   Esto es muy importante, porque reduce la complejidad del protocolo,
haciendolo a la vez sencillo y rapido. Alguien podra pensar que IP no
necesita tal control, porque AX.25 ya se asegura que los mensajes no se
pierdan. Bien pensado, pero IP no funciona solo sobre AX.25 sino tambien
sobre otros protocolos no fiables.

   Ademas, la fiabilidad de AX.25 no asegura nada, debido a:

  * si un nodo se colapsa por el trafico (no es capaz de atender todos los
paquetes IP que estan entrando) tiene permiso para simplemente descartarlos.
Esto significa que tu paquete va seguro en AX.25, llega a un nodo saturado,
y este lo volatiliza!

  * nadie garantiza que por donde vaya un paquete de una a otra estacion,
vayan a ir el resto de los paquetes. Para que lo entendamos se utiliza la
siguiente metafora: un paquete es como una "patata caliente", todas las
estaciones lo que intentan (si no es la receptora del mismo) es "soltar" el
paquete lo antes posible. Asi que si tienen un puerto saturado, y por otro
puerto el paquete tambien puede ir, lo envian por otro puerto. No siempre pasa
esto: IP puede hacerlo si lo necesita, nadie garantiza por tanto el orden de
los paquetes (un paquete se "pierde" por otra ruta y llega despues que todos
los que salieron despues que el).

   "Pues si el protocolo bajo IP no tiene porque ser fiable, para que
queremos la fiabilidad de AX.25?" se pregunta alguien. Hay que abrir una
conexion, enviar el paquete y luego cerrarla: 3 paquetes para enviar 1.

   La respuesta es que en realidad se utilizan las siguientes tecnicas:

  * "circuito virtual": se abre una conexion, pero se mantiene abierta,
porque normalmente no se manda un unico paquete a la estacion destino.

  * "datagrama": no se abre ni cierra conexion alguna: se envia en un
paquete AX.25 en modo desconectado, tambien llamado UI. Son los mismos que se
emplean en las balizas, CQ's y listas UNPROTO de TPK. Los paquetes tienen que
tener un destino, no se mandan al aire o a CQ, ya que el AX.25 receptor tiene
que darse cuenta que ese paquete es para el. Pero nos evitamos mandar los
paquetes SABM, UA, DISC o DM y sobre todo los tiempos muertos esperando.

   Y que pasa si el paquete AX.25 desconectado no llega?. Y si el datagrama
es descartado? Estos "pequeos" problemas seran solucionados posteriormente.

   ICMP

   Nos sale en este punto una nueva sigla y protocolo: El Internet Control
Message Protocol o protocolo de control de mensajes de internet.

   Este protocolo es el "hermano inseparable" de IP. Lo utiliza IP cuando
hay problemas en la red: avisa de un enlace muy congestionado, tambien
si un nodo esta descartando paquetes tuyos (si es capaz), y otros errores
en la red, pero de naturaleza de IP: errores de la internet.

   Para los mas curiosos, digamos que ICMP tiene un modo de funcionamiento
llamado de "eco": le envias un paquete IP con ICMP "eco" y el receptor te
debe responder con un paquete que tenga el mismo contenido. No os suena?
Pues el famoso "ping" del segundo mensaje utiliza esto.

   ENCAMINAMIENTO

   Este tema es muy importante, pero si no te has leido el segundo mensaje,
saltatelo. Con "encaminamiento" nos referimos a la capacidad de la red para
hacer llegar los paquetes a su destino. Y es que no nos sirve de nada si los
paquetes se quedan dando vueltas y vueltas sin llegar a ningun sitio.

   Para ello es fundamental volver a hablar de los "gateway", porque ellos son
los encargados de hacer que los mensajes vayan en la direccion "correcta".

   En nuestro ejemplito, al definir los "gateway", quedo todo a pedir de
boca, y el mensaje llego como una flecha. Pero imaginemos de nuevo la
situacion:

                                44.133.1.1
  44.133.1.31   44.133.1.15  /==> EA2XY-2 <==\    44.133.2.8    44.133.2.36
    EA2XXX <--> EA2XX-2 <==/       /"""\       \==> EA2YY-2  <--> EA2YYY
    _____________________________/       \________________________________

Ahora el paquete va de 44.133.1.31 a 44.133.2.36. Que pasa cuando llega al nodo
44.133.1.1? Si consideramos, por ejemplo, que el "gateway" del nodo es EA2XX-2,
como no alcanzamos la estacion destino, el mensaje se iria por donde vino. Y lo
que es peor, EA2XX-2 volveria a mandarselo al nodo, que lo volveria a enviar a
la BBS, que ... El cuento de nunca acabar. Se ha producido un ciclo, y el
mensaje se quedaria dando saltos entre EA2XX-2 y EA2XY-2 para la eternidad.

   Sin embargo IP, como no, esta diseado para evitar estas y otras situaciones
donde se den ciclos. IP tiene un valor para cada paquete llamado el 'ttl' o
tiempo de vida (time to live). La estacion que crea el paquete le da un valor
original, por ejemplo 25. Por cada estacion IP que pasa el paquete, este valor
se decrementa (normalmente en 1). Si al decrementarlo, el valor es 0, ese
paquete se descarta.

   Por ello, aun en la peor situacion de que se produzcan ciclos, los paquetes
se quedan "rebotando", o "dando vueltas", hasta agotar su existencia, momento
en el que desaparecen.

   Si el "gateway" hubiera sido EA2YY-2, tampoco arreglariamos nada. Los
paquetes de EA2XXX a EA2YYY si llegarian, pero los de EA2YYY a EA2XXX no, al
producirse un ciclo en el enlace EA2XY-2 <=> EA2YY-2.

   Y es que el problema es que el nodo no sabe adonde enviar el paquete cuando
la estacion destino no esta en ninguno de sus puertos. Para eso, no solo
necesita tener un "gateway" (para los mensajes, por ejemplo que no sean ni
para la red de 44.133.1.0 ni la 44.133.2.0), sino que tiene que saber que
estaciones hay en cada subred, para determinar por donde enviar los paquetes.

   La mision de los nodos no es tan sencilla como nos parecia en un principio:
no es buena idean que cada nodo guarde en una lista todas las estaciones
de todas las subredes. Imaginaos el caso de Internet!.

   Esta claro que este no es el metodo escogido. Cada nodo tiene una lista
unicamente con el "gateway" para un tipo de direcciones. Por ejemplo, todo lo
que vaya hacia la provincia 3, es decir todas las 44.133.3.x, van hacia
44.133.3.2, el "gateway". Esta estacion es la que sabe como hacer llegar el
paquete a las diferentes estaciones de la provincia.

   Tampoco se guardan todos los "gateways": si mandamos un paquete al pais
44.1, no nos interesa saber que redes o "gateways" hay alli. Lo mandamos a un
"gateway" nacional, y el se encargara de enviarlo donde deba.

   Por lo tanto el nodo no necesita saber todas las rutas, solo:

a) las de las estaciones de su subred
b) los "gateways" de ciertas redes bajo su jurisdiccion
c) el "gateway" por defecto adonde va todo lo que no va a otro sitio

   La tabla del nodo 44.133.1.1. puede ser

      los de la red 44.133.1.0   por 44.133.1.15
      los de la red 44.133.2.0   por 44.133.2.8
      "el resto"                 por 44.133.3.1  # este seria el "gateway"

   Podemos elegir algunas rutas adicionales, como que ciertas provincias (por
ejemplo cercanas) no vayan al "gateway". Si sabemos que la provincia 4 esta al
lado de la 2, podemos aadir una entrada como:

      los de la red 44.133.4.0   por 44.133.2.8

   Vemos se establece una estructura de nodos piramidal: si un nodo no lo puede
resolver, se lo pasa a uno de la misma o mayor entidad para que lo resuelva.
Arriba del todo no habra "gateways" por defecto, y la direccion tendra que
resolverse. Pero en estos niveles (paises o continentes) el numero de nodos, y
por lo tanto el tamao de las tablas, es pequeo. 

   ENCAMINAMIENTO DINAMICO

   Os imaginais ahora a los gestores de los nodos tratando de configurar bien
los nodos? Una locura de numeros, malas configuraciones, peleas...  sin una
buena organizacion en seguida seria el caos.

   Los desarrolladores de IP no querian preocuparse de estos lios: nodos que se
abren, otros se caen... la red cambia constantemente, es algo dinamico. Por lo
tanto propusieron que esas tablas de los nodos se actualizaran automaticamente.
De hecho, esto no es nuevo, es lo que hace NET/ROM.

   Pero NET/ROM solo gestiona las estaciones que son NET/ROM, y ademas no es
transparente: no se le da simplemente el paquete para que lo pase, sino que hay
que conectarse a el, y decirle a que nodo quieres conectarte. Entonces puedes
hablar con ese nodo, mientras no se corte alguna de las conexiones intermedias.
NET/ROM ha demostrado ser una mala solucion.

   En cambio TCP/IP si funciona, porque los paquetes son pequeas unidades
que van "dando saltos" por los nodos, sin estar suficiente tiempo en ninguno
y sin consumir recursos ni tener tiempos limites de confirmaciones.

   Para terminar hay que decir que el encaminamiento dinamico se basa en
una serie de informaciones de rutas de "gateways" que los nodos se pasan
cada cierto tiempo. Su funcionamiento esta fuera del alcance de este
trabajo: solo decir que son complejos, pero que funcionan, como demuestra
Internet y sus mas de 10 millones de estaciones.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (4)

   Hola a todos:

   De nuevo con vosotros para proseguir con lo que pretendo sea una
explicacion practica de las capacidades del TCP/IP.

   Hagamos un repaso. Tras todo lo leido, tenemos una red formada por una
serie de estaciones con TCP/IP + AX.25. Las estaciones tiene por tanto un
numero IP y un indicativo AX.25. Los paquetes IP se pasan entre estaciones
con "conexion directa" en el modo desconectado de AX.25. Ademas, hay una
serie de estaciones especiales que, con ayuda de unas tablas, consiguen que
los paquetes lleguen a estaciones con las que no tenemos "conexion directa".
Esas tablas se actualizan automaticamente, sin que haga falta intervencion
de nadie.

   Asi, si EA2XXX [44.133.1.31] quiere mandar un paquete IP a EA4YYY
[44.133.28.178], si hay alguna forma posible para que llegue a tal estacion,
el paquete llegara por donde sea (siempre que no mas "saltos" que su 'ttl').

   Asi que tenemos una red formada por una serie de estaciones mandandose
montones de paquetes como energumenos. Algunos llegaran. Otros, victimas
del ruido o de la congestion, pereceran. No es una vision muy alentadora,
despues del "tinglado" que hemos montado.

   Pero tranquilos, para solucionar nuestros problemas llega TCP.

   ==========
      TCP
   ==========

   Imaginemos que tenemos que enviar una informacion de nuestra estacion
ejemplo 44.133.1.31 a 44.133.2.36, via IP. Aunque el limite de un paquete
para IP es de 64 kilobytes, para el protocolo inferior (AX.25 en este caso)
la limitacion suele ser menor. Asi que nuestra informacion tiene que ser
mandada en varios paquetes IP, que van en varios paquetes AX.25.

   Ya hablamos en la anterior entrega de que IP no era fiable, y sus paquetes
podian perderse o llegar en otro orden al original. Como asegurar que la 
informacion llegue intacta al otro extremo de la comunicacion? -44.133.2.36
en este caso-. 

   Podriamos pensar en que fuera las propia aplicacion que enviara la
informacion la que aportaran sus propios mecanismos de fiabilidad (numeracion
de paquetes, confirmacion de llegada y repeticion de los no llegados). Sin
embargo los programadores de las aplicaciones tendrian que ocuparse de estos
detalles que muchas veces serian iguales. Por otro lado, unos y otros
protocolos, serian diferentes, y por lo tanto incompatibles.

   Por lo tanto, lo ideal es crear un protocolo que ira dentro de IP y que sera
el encargado de que la informacion llegue intacta al otro lado.

   Para IP sera tan indiferente como el resto de la informacion que translada.
Es lo mismo que cuando AX.25 translada un paquete IP. El no sabe si la
informacion que translada es un texto de un mensaje, un trozo de un fichero, un
paquete de otro protocolo, u otro tipo de informacion. Simplemente le mandan
transmitir una serie de bytes y el lo hace.

    Los creadores de IP hicieron entonces TCP, Trasmission Control Protocol o
protocolo para el control de la transmision. TCP funciona al estilo de AX.25
pero a otro nivel. Tambien tiene comandos para apertura de una conexion y su
cierre (AX.25 tiene el SAMB y el DISC), tiene confirmaciones y no
confirmaciones (AX.25 tiene UA, RR, REJ, RNR) y paquetes de informacion, y la
informacion es bidireccional (va en ambos sentidos). Un paquete TCP va dentro
de un paquete IP, como ya hemos dicho.

    Sin embargo hay una diferencia notable entre TCP y AX.25, y es que
mientras AX.25 funciona entre 2 estaciones que se conectan directamente,
TCP funciona entre 2 estaciones IP, asi que no tienen porque estar conectados
directamente. IP ya se encargara que los paquetes lleguen entre ellos.

    Fijaos la diferencia en el esquema del ejemplo:

                                44.133.1.1
  44.133.1.31   44.133.1.15  /==> EA2XY-2 <==\    44.133.2.8    44.133.2.36
    EA2XXX <--> EA2XX-2 <==/       /"""\       \==> EA2YY-2  <--> EA2YYY
    _____________________________/       \________________________________

    Antes la confirmaciones parciales, repeticiones, conexiones y
desconexiones se producian una por cada enlace real, 4 en total entre las
5 estaciones implicadas. Cualquier fallo en una de las conexiones, o un
temporizador que salta, provocaba que toda la conexion cayera.

    Con TCP/IP, es decir, con TCP + IP como ahora ya sabemos, entre enlaces
solo hay translado de paquetes IP. Es TCP, con sus numeros de paquete y sus
temporizadores el que se encarga que entre 44.133.1.31 y 44.133.2.36 se abra
la conexion y la informacion fluya correctamente hasta la desconexion. Como
consecuencia, a menos que los enlaces parciales no funcionen, la conexion
avanzara (limitado tanto por la velocidad de los enlaces como por la calidad
de los mismos, ya que su uno de ellos hace perder muchos paquetes, ralentizara
mucho el sistema).

   Alguno me dira que en redes donde se pueden producir muchos fallos, como
AX.25, esto de no confimar cada enlace no es buena idea, ya que los fallos
no se detectan sino en los extremos de la comunicacion. Pero el fracaso de
las redes X.25 frente a TCP/IP han demostrado que esto no es asi, porque
el cargar a la red con la responsabilidad de hacer que el paquete vaya
pasando solo consigue nodos mas complejos, normalmente mas lentos y con
recursos limitados, lo que significa que unos pocos, y solo en buenas
condiciones logran aprovechar las posibilidades de una red, por otro lado
mas compleja y cara.

   Por supuesto, si los enlaces son buenos, miel sobre hojuelas para TCP/IP.
Es por ello que se impone este protocolo en el mundo actual de la fibra optica,
donde la tasa de fallo media es de 1 cada 10 billones de bits transmitidos.

   RELACIONES ENTRE PROTOCOLOS

   TCP se dice que es un protocolo de TRANSPORTE de informacion, mientras
que IP es un protocolo de RED, y AX.25 es un protocolo de ENLACE. Cada uno
se encarga de una faceta o aspecto de todo lo que hay que hacer para la
comunicacion de dos ordenadores. Normalmente, se dibujan apilados. Si el
protocolo A esta sobre el protocolo B, significa que A utiliza B para
transmitirse. Asi, tenemos hasta ahora:

                                 ----------------------
       Protocolo de transporte   |        TCP         |
                                 ----------------------
       Protocolo de red          |     IP y ICMP      |
                                 ----------------------
       Protocolo de enlace       |       AX.25        |
                                 ----------------------
                                 |      HARDWARE      |

    TCP Y LOS USUARIOS

    Un aspecto mas que hay que destacar de TCP es su relacion con los usuarios.
Cuantas conexiones TCP se pueden establecer en una misma maquina?  Como se
distinguen?

    Cuando se creo TCP/IP los ordenadores eran maquinas caras que daban
sevicios a muchos usuarios a la vez. Por lo tanto si varios querian utilizar la
red, como solo hay un numero IP por maquina, los paquetes de todos se
mezclarian. No valdria distinguirlos por el numero IP de destino, ya que
entonces entre 2 maquinas distintas solo podria haber una conexion.

    Por lo tanto hace falta algo mas para distinguir cada conexion TCP abierta
desde una misma maquina. Esto se hace mediante un numero llamado "puerto"
(port). Entonces cada conexion TCP se establece entre un puerto de una
determinada maquina y el puerto de otra. Esto se denota asi, con el numero IP y
el numero de puerto de cada lado de la conexion, como en:

		(44.133.1.31:1025, 44.133.2.36:25)

donde un usuario o aplicacion en el puerto 1024 de la maquina 44.133.1.31 esta
conectada con el puerto 25 de la maquina 44.133.2.36.

   Con este sistema, puede haber muchas conexiones (hasta 65536, que es el
numero maximo de puertos disponible) entre dos maquinas. Cada usuario tomaria
un puerto no ocupado ya para hablar con un puerto que quisiera de la otra
maquina, incluido el 25, ya que las conexiones se distinguen por numero IP y
puerto de ambos extremos. Asi, la siguiente conexion si puede establecerse,
ya que es diferente de la anterior (el puerto 1100 es distinto del 1025):

		(44.133.1.31:1100, 44.133.2.36:25)

    Finalmente, destacar que las estaciones intermedias entre ambas estaciones
no se indican sus puertos, porque no se utilizan. Ellas solo sirven de
"repetidores" de los paquetes IP y no saben nada de la comunicacion TCP. Eso
no significa que no tengan puertos en TCP, sino que estos solo se utilizan
en las comunicaciones TCP de esas maquinas con otras.


                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (5)

   Hola a todos:

   De nuevo con vosotros para proseguir explicacion practica de las
capacidades del TCP/IP.

   Hemos visto en los 4 mensajes anteriores como funciona IP, cuales son
sus ventajas, y tambien un poco sobre el funcionamiento de TCP sobre IP
y el concepto de puerto.

   A lo que es TCP/IP vamos a aadirle ahora otro protocolo: UDP. Hablaremos
del concepto de socket, y el de cliente/servidor. Eso nos servira de entrada
a lo que verdaderamente nos interesa de esta serie: los servicios de
TCP/IP.

   ==========
      UDP
   ==========

   Cuando hablamos de IP, mencionamos como una ventaja que no controlara si los
paquetes se perdian o desordenaban: hacia el protocolo sencillo y rapido.
Posteriormente, al querer aadir fiabilidad necesitabamos de un protocolo que
complicaba la comunicacion, aunque fuera menos que si teniamos que tener
conexiones parciales entre todos los enlaces de la comunicacion en AX.25.  Sin
embargo, TCP sigue siendo costoso. Imaginenos que tenemos que mandar una
pequea informacion a otra estacion de la red que nos cabe en un paquete.

   Podriamos:

a) abrir una conexion TCP con esa estacion y pasarle la informacion. Este
metodo es muy costoso. Primero un paquete IP va del origen al destino para
pedir una apertura de conexion. Otro de vuelta lo concede. Luego se transmite
la informacion y luego hay otros dos para cerrarla (en realidad, abrir y cerrar
cuestan 3 paquetes). En total, se han movido 5 paquetes por toda la ruta cuando
solo queriamos enviar 1.

b) enviar un paquete IP directamente con la informacion. Pero en este caso no
hay puertos, con lo que nos sucede lo mismo que nos pasaba con TCP.

c) algo que fuera como IP, pero con puertos. Este "algo" es lo que llamamos
UDP. El protocolo de datagramas de usuario (User Datagram Protocol) permite a
los usuarios enviarse informacion en paquetes sueltos. UDP lo unico que aade a
IP es los dos numeros de puerto, el de origen y el de destino, tal y como tenia
TCP, pero no aade nada mas (estos puertos son independientes de los de TCP).

  Esto hace que:

* Mutiples usuarios puedan intercambiar paquetes UDP entre dos maquinas a la
  vez sin problemas.

* UDP no proporciona mecanismos de fiabilidad, asi que los paquetes pueden
  llegar desordenados o incluso no llegar. Es por tanto, un protocolo no
  fiable.

   Para que nos puede servir un protocolo no fiable? Pues en radio, por ejemplo
para la red de cluster.

   La red de cluster es una red paralela que se ha estado intentando montar
desde hace mucho tiempo, para los que practican el DX tanto en HF como en otras
bandas. Se basa en que si oyes una estacion y haces un contacto, envies la
informacion al resto de los usuarios del cluster de que estacion y en que
frecuencia has oido. De esta forma otros podran hacer tambien el contacto.

   Lo interesante es tener todos los cluster nacionales, o incluso
internacionales, conectados (a nivel local no hace falta mas que quedar con el
equipo de dos metros en una frecuencia e ir pasandose la informacion, no hace
falta tanto lio).

   Pero lo fundamental es que esa red exige velocidad por encima de fiabilidad.
Es mas interesante que el mensaje llegue rapido, a garantizar que llegue bien.
Porque tratar de garantizar que llegue bien puede significar un retraso en ese
mensaje, de tal forma que cuando llegue la informacion es inutil, media hora
despues.

   Asi vemos dos ventajas de TCP/IP: con la misma infraestructura, multiples
servicios, cada uno con sus caracteristicas. De todas formas, para que no todo
sean alabanzas, en este caso IP tiene un problema: no existe prioridad en los
paquetes: un paquete TCP tiene la misma que uno UDP, asi que la congestion de
TCP afecta a la velocidad de los paquetes UDP. La practica, ha demostrado sin
embargo que los servicios basados en UDP a veces funcionan cuando los de TCP
por el colapso es imposible.

   Con UDP, nuestra pila de protocolos queda:

                                 ----------------------
       Protocolo de transporte   |     TCP o UDP      |
                                 ----------------------
       Protocolo de red          |     IP y ICMP      |
                                 ----------------------
       Protocolo de enlace       |       AX.25        |
                                 ----------------------
                                 |      HARDWARE      |

   SOCKETS

   Un socket, traducido comunmente como "enchufe" es un modo abstracto de
tratar las conexiones de red en el sistema operativo. Historicamente se han
relacionado con el TCP/IP aunque no tiene porque ser asi. El concepto de socket
permite a los programadores construir aplicaciones TCP/IP facilmente, ya que
solo con unas cuantas instrucciones le dicen al sistema operativo que abra o
cierre o una conexion TCP o UDP desde un puerto de nuestra maquina a otro
puerto de otra maquina, y otras instrucciones permiten enviar o recibir un
flujo de informacion TCP o un paquete UDP.

   La "sencillez" de este mecanismo es uno de los propulsores del exito del
TCP/IP, ya que permite la construccion de aplicaciones de red de una forma
sencilla.

   CLIENTE / SERVIDOR

   Asi como "socket" es un concepto mas destinado a los programadores, el
paradigma cliente/servidor es un concepto importante para los usuarios.

   Hasta ahora hemos visto las comunicaciones TCP/IP como algo bilateral, un
aficionado se ponia a charlar via teclado con otro. En este caso, sea quien sea
el que inicie la llamada es lo de menos.

   No nos hemos preguntado quien hay en cada puerto, o como averiguar la
maquina y/o el puerto en que esta un usuario. Tal vez habreis supuesto que a
cada uno se le asigna un numero de puerto en cada maquina, algo fijo. Y le
teneis que dar a vuestras amistades el numero IP y el de puerto para que
charlen con vosotros, algo asi como el que da el numero de telefono, solo que
con mas numeros. Nada mas lejos de la realidad.

   Los numeros de puerto te los concede al instante el sistema operativo cada
vez que abres una conexion. Cuando la cierras, ese puerto queda por un tiempo
sin uso hasta que pueda ser adjudicado a otro usuario, incluso a ti mismo. El
puerto de destino si hay que indicarlo siempre.

   Un usuario puede o bien pedir un numero que el quiera (y se le concedera si
no esta ocupado) o, lo mas habitual, dejar que el sistema elija uno al azar que
este libre.

   En el caso de UDP, no es necesario abrir la conexion, pero el puerto de
destino y si quieres el de origen, se indican a la vez que se ordena mandar el
paquete.

   Pero, si el numero de puerto es aleatorio, como saber adonde conectarse?  La
respuesta es: no es necesario.

   Lo que los usuarios de TCP/IP van a hacer es conectarse a una serie de
puertos "bien conocidos", que son fijos y donde se ofrecen una serie de
servicios (que son los que ofrece Internet basicamente) y que son adonde se van
a conectar los usuarios.

   Estos puertos "estandar" son determinados por las organizaciones de Internet
encargadas de esa tarea, y podemos mencionar algunos famosos (la lista es
bastante grande). En ellos, hay programas especificos que son lo que hasta
ahora he llamado servicios o aplicaciones, y que se encargan de diversas tareas
-algunas utiles, otras curiosas- :

servicio   puerto/protocolo (la mayoria de los servicios en ambos, TCP y UDP)
--------   ----------------
echo		7/tcp    # "echo" devuelve lo mismo que envias: sirve para
echo		7/udp    # testear la conexion
discard		9/tcp    # "discard" se traga todo lo que le envias sin
discard		9/udp    # devolver nada. Tambien para pruebas.
daytime		13/tcp   # "daytime" devuelve fecha y hora de la otra maquina
daytime		13/udp
chargen		19/tcp   # "chargen" envia caracteres sin parar hasta que
chargen		19/udp   # cierres la conexion. Tambien para test.
ftp-data	20/tcp   # De FTP hablaremos proximamente. Utiliza estos 
ftp		21/tcp   # puertos para la transferencia de ficheros
fsp		21/udp   # En UDP se llama FSP.
telnet		23/tcp   # De TELNET hablaremos proximamente.
smtp		25/tcp   # El punto de entrada del correo. Tambien proximamente.
gopher		70/tcp   # "gopher" es un servicio interactivo. 
gopher		70/udp
finger		79/tcp   # "informacion" del ordenador remoto.
www		80/tcp   # "www" es otro servicion interactivo, el famoso Web
www		80/udp
link		87/tcp   # "link" para cruzar teclado con la otra maquina.

   De los servicios mas importantes, como FTP, TELNET, correo, WWW y otros
hablare individualmente en proximos mensajes. Entonces veremos como esta
interaccion entre usuario-programa se transforma en una interaccion entre
usuarios a otro nivel.

   Estos puertos no pueden ser ocupados por cualquier usuario. Son servicios
basicos y estan reservados para los programas especificos que los proporcionan.
De hecho, todos los puertos por debajo del 1024 estan reservados para el
administrador de la maquina, para que no se produzcan usurpaciones de estos
servicios no estandar. No todos estan asignados, muchos son para futuras
ampliaciones. Lo que no hay son puertos estandar por encima del 1024: son los
puertos para los usuarios.

   Un SERVIDOR, un programa que esta continuamente escuchando en su puerto
asignado para proporcionar un servicio, no necesita conocer el puerto del
usuario que pide el servicio (llamado el CLIENTE). El acepta toda las
peticiones de conexion mientras pueda, y al aceptarlas envia las respuestas por
la conexion bidireccional que el cliente ha abierto.

   En resumen, un sistema cliente/servidor esta formado por:

* clientes que abren conexiones en puertos aleatorios hacia servicios en
  puertos estandar.

* servidores escuchando en puertos estandar para atender las peticiones de
  servicio de uno o varios clientes.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (6)

   Hola a todos:

   Hasta ahora hemos hablado mucho mas de teoria que de cosas practicas
como en que puede beneficiar una red de TCP/IP a sus usuarios y gestores.
A partir de ahora espero que sea mucho mas ameno, ya que estamos llegando
a las aplicaciones de usuario.

   Como resumen, hemos visto las capacidad de IP para convertir la red de
BBS's AX.25 en una verdadera red nacional e incluso internacional, donde
cualquier estacion puede acceder a cualquier otra "en tiempo real" para
multiples servicios (ahora mismo el unico servicio que tenemos en red es
el correo electronico). Vimos que necesitabamos TCP entre las dos estaciones
si queriamos una comunicacion fiable. Y vimos que si no era necesario una
comunicacion fiable, podiamos utilizar UDP que era mas eficiente, aunque
no fiable. Pusimos el ejemplo de la red de packet cluster, como una
aplicacion tipica para usar UDP. Ambos protocolos utilizan el concepto de
puerto para permitir mas de una comunicacion en cada ordenador. Vimos
tambien una lista con algunos puertos tipicos.

   Finalmente, mencionamos el concepto de socket -de interes para los
programadores- y explicamos lo que significa cliente/servidor: una serie
de usuarios (clientes) accediendo a una serie de programas que ofrecen
servicios (servidores).

   Ahora llega la hora de hablar de las aplicaciones que utilizan todo
esto para proporcionarnos los servicios, que son los que realmente
utiliza el usuario. Hablaremos de los siguientes:

   * FTP: transferencia de ficheros
   * TELNET: acceso remoto
   * SMTP: correo electronico
   * NNTP: grupos de noticias
   * CHAT/IRC: modo conferencia
   * WWW: servidores de informacion

   Estas no son las unicas aplicaciones o servicios del TCP/IP. Sin embargo
si son los servicios mas utilizados o mas comunes para los usuarios de
Internet.

   NOMBRES Y DOMINIOS: DNS

   Antes de avanzar mas, hay que resolver una "pega" mas del TCP/IP: los
numeros IP. Todos os habreis dado cuenta que el uso de numeros IP es bastante
engorroso. A la maquina le viene bien esa representacion, sin embargo los
humanos preferimos nombres para acordarnos de las estaciones. Para ello
surgieron los nombres de maquinas y los dominios.

   Cada ordenador tiene su nombre y apellidos, por ejemplo "eb2dsn.ampr.org"
es el nombre de mi ordenador. El nombre, eb2dsn, lo es por razones obvias.
El apellido "ampr.org" es el DOMINIO y significa AMateur Packet Radio y
el org es el dominio superior de las organizaciones no lucrativas. El dominio
"ampr.org" es el concedido a los radioaficionados de la red 44.x.x.x, y
al recibir tu numero IP, por defecto incluyen como nombre <indicativo>.ampr.org
de tu ordenador. En Internet, los nombres son de otros dominios, como en
www.microsoft.com o ftp.fi.upm.es.

   De esta forma, en vez de tener que hacer un "ping 44.133.1.31", puedes
hacer un "ping eb2dsn.ampr.org", que para la maquina sera lo mismo, pero
para las personas no lo es.

   Esta claro que el ordenador no se inventa el numero IP a partir del
nombre del ordenador. Necesita "algo" que traduzca nombres de maquinas en
numeros IP. El metodo mas sencillo es tener un fichero que tenga pares
nombre - numero IP. Tal fichero es el fichero de "hosts", y teniendo en
cuenta el tamao de la posible red actual, seria un metodo mas que
suficiente, ya que los nombres no suelen estar sujetos a muchos cambios.

   Sin embargo existen otros metodos como las "yellow pages" (paginas
amarillas) o el DNS (sistema de nombres de dominio) que permiten que esos
nombres se almacenen en ordenadores de la propia red, de forma que cuando
necesitamos un nombre nos conectamos al servidor de tal servicio, y le
preguntamos el numero IP de una maquina con tal nombre.

   DNS es ademas un servicio muy complejo pero muy importante, porque no
se guardan todos los ( nombres - numero IP ) sino que existe una estructura
parecida a la del encaminamiento por la cual solo se guardan los nombres
en el ordenador encargado de esa parte de la red, y las preguntas se
propagan a traves de la propia red hasta encontrar el ordenador que las
pueda responder.

   Sin embargo este metodo es de momento poco operativo: resolver el
nombre puede ser costoso, sobre todo a bajas velocidades.

   Asi que imaginaremos que los nombres a partir de ahora estan en nuestro
fichero de "hosts".

   =======
     FTP
   =======

   Con el protocolo de transferencia de ficheros, FTP, comenzamos nuestro
repaso a los servicios mas comunes y que mas nos pueden interesar del TCP/IP.
FTP, como su nombre indica, sirve para transferencia de ficheros: tanto para
obtenerlos desde otro ordenador ('bajarlos') como para dejar ficheros en
otro ordenador ('subirlos'). Los ficheros pueden ser binarios o de texto
('image' o 'ascii').

   Veamos un ejemplo. Queremos bajar el fichero tcpip.txt del directorio
/pub/docs de eb2dsn.ampr.org (por razones historicas los directorios se
indican con / y no con \).

   C:\> ftp eb2dsn.ampr.org
   Connected to eb2dsn.ampr.org.
   220 FTP server ready.
   Name: anonymous
   Password: eb2dsn@eb2dsn.ampr.org
   230 User anonymous logged in.
   Remote system type is UNIX.
   Using binary mode to transfer files.
   ftp>

   Nos conectamos, y luego tenemos que teclear nuestro nombre de usuario y
contrasea para entrar en la maquina. Pero este servicio entonces no seria
muy util, asi que suele haber un usuario 'anonimo' sin contrasea (password)
que te deja entrar en un directorio de donde cualquiera puede sacar programas:
es lo que se llama ftp anonimo.

   Ese usuario suele ser 'anonymous' y de password se suele introducir tu
direccion de correo. Una vez hemos entrado, nos sale el prompt "ftp>".
Introduciremos el comando de cambio de directorio (cd) y luego el de
bajarse el fichero (hay muchos mas, pero no es del interes de estos mensajes
ensear a manejar ftp)

   ftp> cd /pub/docs
   250 CWD command successful.
   ftp> get tcpip.exe
   200 PORT command successful.
   150 Opening BINARY mode data connection for tcpip.txt (3300 bytes).
   226 Transfer complete.
   300 bytes received in 21.17 secs (0.13 Kbytes/sec)
   ftp> close
   221 Goodbye.
   ftp> quit

   Al final cerramos la conexion con 'close' y salimos del programa con
'quit'. 

   Lo importante es como funciona el sistema. Tenemos dos programas: el
cliente FTP, que residira en mi maquina, y el servidor FTP que residira en
la maquina eb2dsn.ampr.org. El primer programa, el cliente, lo arrancamos
ejecutando 'ftp <maquina>'. El servidor esta constantemente funcionando y
habra sido lanzado al arrancar la maquina eb2dsn.ampr.org.

   El servidor, nada mas comenzar, abre una conexion "de escucha" en el
puerto 21 (que es el estandar para el FTP). El protocolo utilizado es el TCP,
pero el funcionamiento es el mismo si fuera UDP. Si alguna estacion abre
una conexion TCP con el puerto 21 de eb2dsn.ampr.org, el sistema operativo
"despierta" al servidor de FTP y entonces se establece la comunicacion entre
estacion cliente y servidor. La forma de comunicarse (el protocolo) es el
establecido por el estandar FTP: cualquiera puede hacer un cliente o un
servidor, solo debe saber los comandos que cada uno puede enviar y que debe
responder el otro. Estos comandos son generalmente instrucciones en modo
texto, terminadas por el caracter de fin de linea habitual ('Return' o
'Enter').

   La mayoria de los protocolos que vamos a ver funcionan asi, solo que
su repertorio de instrucciones es diferente, ya que se usan para otro tipo
de servicios. Sin embargo, FTP tiene una pequea particularidad. A diferencia
de otros, en FTP se abre una segunda conexion TCP entre el cliente y el
puerto 20 del servidor, y esta conexion es por donde realmente se transfieren
los datos del fichero pedido o llevado. Este puerto es el llamado 'ftp-data'. 

   En la pila de protocolos, los protocolos de aplicacion o de servicios, como
FTP, quedan asi: 

                                 ----------------------
       Protocolo de aplicacion   |        FTP         |
                                 ----------------------
       Protocolo de transporte   |     TCP o UDP      |
                                 ----------------------
       Protocolo de red          |     IP y ICMP      |
                                 ----------------------
       Protocolo de enlace       |       AX.25        |
                                 ----------------------
                                 |      HARDWARE      |

   VENTAJAS DEL FTP

   Hemos visto el funcionamiento, que puede ser interesante o no. Pero el
motivo de explicarlos era justificar las ventajas de TCP/IP. Veamos pues
esas ventajas en el campo de la transferencia de ficheros.

   Al principio la transferencia de ficheros era "manual". Dos corresponsales
se ponian de acuerdo en enviarse un fichero. Ponian ambos la instruccion de la
TNC para transferir 8bits, y entonces el que tenia el fichero, le decia
(tecleaba) "Estas preparado?" "Si." "Pues alla va". En ese momento el
receptor tecleaba la instruccion para recoger un fichero binario, con el
nombre que queria para el mismo, y el emisor tecleaba la instruccion para
mandar el fichero binario. Al final, se comunicaban el tamao que tenia que
tener para saber si la transferencia habia sido buena.

   Posteriormente aparecio el programa YAPP. Este incluia un pseudo-protocolo
para pasar ficheros. Al YAPP se le aadio la capacidad de si la conexion
fallaba, se podia retomar desde donde se perdio, sin tener que comenzar desde
el principio. El protocolo YAPP se ha utilizado mucho en las BBS's siendo casi
un estandar para bajarse ficheros. Otros programas terminal mas modernos,
utilizan YAPP o sus propios protocolos. El metodo mas moderno que he visto
es el AUTOBIN, que hace todo automaticamente.

   Es FTP mejor que estos sistemas? Primero hay que decir que FTP se encarga
del intercambio de los ficheros, asi que nada de hacerlo de forma manual.
Segundo, hay versiones que pueden recuperarse de las conexiones interrumpidas.
Sin embargo no es habitual utilizarlo (por la sencilla razon de las
velocidades de transferencia actuales en Internet lo hacen innecesario).

   Tercero, FTP permite la navegacion por directorios y el listado EN EL PROPIO
PROTOCOLO. Otros sistemas te permiten la navegacion, y adicionalmente, te
permiten bajarte los ficheros. Cuarto, FTP permite la transferencia entre dos
maquinas ninguna de las cuales somos nosotros. Imaginad que queremos pasar un
fichero de otra BBS a la nuestra (no a nuestra estacion, que es lo habitual).

   Quinto, que FTP exige la identificacion del usuario, asi unos pueden tener
acceso a una serie de ficheros (propios o generales) y otros a otros. El
sistema de envio de password tendria que ser mas seguro, pero es posible
hacerlo.

   Y lo ultimo, como FTP funciona sobre TCP/IP, el intercambio no esta
limitado a las estaciones con las que tenemos conexion directa -siempre
hablando en teoria, luego la velocidad y capacidad de la red marcaran las
verdaderas posibilidades-.

   Esto no solo sirve para intercambiar ficheros con cualquier colega, o
que haya sitios especificos donde podamos conseguir ese software que tanto
nos interesa: ya no hara falta mandar interminables trozos de 7plus, con
enviar un mensaje que diga "El programa XXX que hace xxxxxxx esta en yyyyyy".
Tambien sirve para hacer "sitios" especialmente dedicados a la acumulacion
de software, tal y como hacen en Internet las universidades. En vez de tener
en cada BBS un area DOS o YAPP que se actualiza lentamente, se pueden tener
por ejemplo unas cuantas maquinas potentes, con bastantes Gigas de disco donde
se guarde todo el software que se pueda. Con sistemas de mirroring (muy
empleados en Internet) se mantienen automaticamente actualizados entre ellos
cualquier cambio que haya en uno. De esta forma, cualquiera, sin muchos
retrasos (porque los "sitios" estaran a pocos saltos) puede bajarse el ultimo
software sin tener que andar pidiendo por favor en boletines, mandando discos
o copiando de los colegas cuando los pillas. Entonces si estarias disfrutando
de la red, y no sufriendola, como ahora.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (7)

   Hola a todos:

   Hemos hablado mucho ya de TCP/IP. Hemos visto los fundamentos para
comprender porque TCP/IP mantiene una verdadera red, mientras que la red de
BBS's mantienen solo una red de correo electronico.

   En el numero anterior, vimos el protocolo de transferencia de ficheros, FTP,
contamos como funcionaba, vimos sus ventajas, y al final hice un poco de
ciencia-ficcion con las posibilidades que aporta.

   Ahora nos toca hablar de otro protocolo igual de importante e interesante.

   ==========
     TELNET
   ==========

   En la pila de protocolos, TELNET esta situado en la misma situacion que FTP
y que el resto de protocolos que vamos a ver: por encima de TCP y por debajo de
los usuarios:

                                 ----------------------
       Protocolo de aplicacion   |      TELNET        |
                                 ----------------------
       Protocolo de transporte   |     TCP o UDP      |
                                 ----------------------
       Protocolo de red          |     IP y ICMP      |
                                 ----------------------
       Protocolo de enlace       |       AX.25        |
                                 ----------------------
                                 |      HARDWARE      |

   TELNET tambien funciona sobre TCP, y tambien tiene una parte cliente y una
parte servidor, escuchando continuamente en un puerto, en este caso el 23, de
la maquina destino.

   O sea que tecnicamente, no se va a diferenciar de FTP o de los posteriores.
El protocolo entre cliente y servidor es diferente, porque TELNET no se usa
para transferencia de ficheros (al menos tal y como lo hace FTP). Que hace
entonces TELNET?

   La respuesta es: acceso remoto. Ahora queda por explicar que es eso y que
ventajas ofrece.

   Imaginemos que queremos trabajar con un programa que esta en otra maquina (a
la cual tenemos alcance directo o no). Por ejemplo, una aplicacion de calculo
de keplerianos. La primera opcion puede ser bajarse el programa: para ello
deberia estar en el area publica (la que se entra con "anonymous") de FTP.
Supongamos que el programa comprimido es enorme, porque trae unos inmensos
ficheros de datos para hacer su trabajo, y en realidad nosotros solo lo vamos a
utilizar muy de vez en cuando.

   Lo que nos gustaria es ejecutar ese programa en esa maquina y que nuestra
pantalla se convirtiera en la pantalla de entrada de datos y salida de
resultados de ese programa. Si los datos que usuario y programa se van a pasar
son pocos, y ademas no vamos usarlo habitualmente, este metodo presenta la
ventaja que es mas rapido (que bajarse el enorme programa) y no ocupa espacio
en nuestro ya saturado disco duro.

   Por acceso remoto se entiende la capacidad de entrar en otro ordenador y
actuar como si estuvieramos en el, siendo posible ejecutar tanto comandos del
sistema como programas que el gestor de la maquina nos de permiso.

   Para tener acceso remoto en 'modo texto' (es decir, nada de ventanas
graficas ni programas "windows") existe el protocolo TELNET.

   Las maquinas que tienen servidores TELNET (permiten el acceso remoto) suelen
ser ordenadores con sistemas operativos multiusuario: permiten el acceso al
ordenador a varios usuarios a la vez, cada uno desde su terminal (local o
remota a traves de modem). Cada usuario tiene un nombre de usuario y una
contrasea o "password" para identificarse antes de entrar al sistema.  Los
ficheros tienen un sistema de permisos para que puedan acceder, o escribir, o
ejecutarlos solo los que deban. En definitiva, son ordenadores preparados para
varios usuarios.

   El sistema operativo mas tipico, aunque no unico, que hace esto es Unix (y
derivados). El manejo de Unix no es igual que el de MS-DOS (aunque tampoco es
radicalmente diferente), asi que los usuarios deberian aprender algo de los
sistemas. Por otro lado Unix es mucho mas potente, asi que compensaria el
aprendizaje con las posibilidades. No estoy hablando de ejecutar un programa:
eso es igual en los dos, es decir, poner el nombre del programa en la linea de
comandos. Pero si queremos hacer cosas como copiar, mover, borrar ficheros, o
aun mas dificiles como ejecutar varios programas a la vez, o hacer ficheros de
proceso por lotes (.BAT), si que es diferente de lo que estamos habituados.

   Alguien se preguntara: "es capaz de emular cualquier programa en modo
texto?" (hay programas en modo texto que despliegan menus, etc). Pues...
depende. TELNET es capaz de emular muchas terminales. Las primeras terminales
(por cierto, una terminal no es mas que un monitor y una pantalla que funcionan
coordinados y que son los "puestos de trabajo" de los medianos y grandes
ordenadores) eran muy simples: imprimian lineas de texto en pantalla y enviaban
lo tecleado al usuario. Posteriormente se fueron perfeccionando y permitieron
movimientos por pantalla con el cursor, colores, etc. Depende de los tipos de
terminales que soporte tanto el cliente como el servidor, se podran emular
estos aadidos y por lo tanto se podran ejecutar programas mas o menos
vistosos.

   "Y los programas graficos? Hay alguna posibilidad?" Pues si, si la hay,
aunque no al alcance de cualquiera. El sistema grafico de los sistemas Unix,
llamado X Windows, es un sistema de ventanas cliente/servidor a traves de
redes TCP/IP. Asi que en teoria, si podrian ejecutarse. Pero dado la velocidad
necesaria, solo es operativo en redes muy rapidas (como en redes locales
de 10 megabits por segundo). Ademas la estacion deberia tener capacidades
graficas, asi que o se usa un sistema Unix con X Windows, o un emulador de
X Windows bajo alguna version de Windows. Aunque todo esto es posible, repito,
no es ni mucho menos realizable en TCP/IP sobre AX.25.

   TELNET: ACCESO A LA BBS

   Hemos dicho que TELNET permite ejecutar programas en la maquina remota.
Pero... Cual es el programa que mas ejecutamos en otras maquinas en AX.25 ?
Pues el programa de la BBS, por supuesto. Asi, para acceder a la BBS lo que
hariamos es abrir una conexion TELNET, entrar nuestro login y 'password', y
una vez dentro del sistema, ejecutar algun comando de entrada a la BBS, por
ejemplo:

      $ bbs
      Hola eb2dsn en Vitoria.
      Bienvenido al BBS de EA2RCF en Gasteiz
      Son nuevos los mensajes del XXXXXX al YYYYYY
      Port: 4/TELNET Via: 4
      Hay X estaciones conectadas.
      4:EA2RCF BBS>

   De esta forma, si uno quiere entrar en la BBS, no tiene mas que indicarlo.
Si lo que quiere es ejecutar otro programa, tambien lo puede hacer. Si le
gusta un tipo de forma de trabajar con la BBS en vez de otro, se pueden
preparar varios y que cada uno escoja el que prefiera. E incluso el usuario
puede personalizarlo todo.

   TELNET COMO CLIENTE UNIVERSAL

   El cliente TELNET ademas nos puede sirve como "cliente" para cualquier otro
protocolo, ya que lo que hace TELNET es conectarse a un puerto al que le manda
en modo texto lo que el usuario teclea, y muestra al usuario el texto que el
otro extremo de la conexion envia. Esto nos puede servir para "hablar" con
los servidores de otros protocolos manualmente, si sabemos como "hablarles"
(el protocolo). Para ello, TELNET permite no solo la conexion con el puerto
23 estandar, sino que se le puede indicar el puerto al que se desea conectar:

      C:\> telnet eb2dsn.ampr.org 25

   El puerto 25 es el puerto de SMTP (que veremos) y podriamos "hablarle" al
servidor SMTP hasta lograr poner un mensaje si conocemos el protocolo SMTP.

   CONVERSANDO CON OTROS

   El cliente TELNET es, por tanto, un programa de terminal como cualquiera
que pueda usarse en AX.25 (aunque no esta dividida la recepcion y la emision
en dos pantallas sino que se entremezclan en una). Por ello, un usuario
puede esperar que el programa funcione como un terminal AX.25, y le permita
conectarse con otra estacion amiga y charlar "de teclado a teclado".

   Esto es posible, pero vamos a ver que el funcionamiento interno no es tan
sencillo como en AX.25, donde los dos programas se conectan, y ya esta.

   El primer metodo es aprovechar un servicio de TCP/IP que es 'ttylink'.
Este servicio presente en el puerto TCP 87, permite charlar con el
'administrador' del sistema TCP/IP, que sera el sysop en las BBS pero que
sera el dueo del ordenador en cualquier estacion individual. En caso de
no estar, se da un mensaje de aviso con tal incidencia. Con esto, podemos
charlar con cualquier estacion TCP/IP activa en la red, podamos o no
conectarnos con ella directamente.

   Tecnicamente, podemos tener un cliente especifico, o un comando especifico,
para conectarnos a esa estacion, como:

      C:\> ttylink eb2dsn.ampr.org
      Bienvenido a eb2dsn.ampr.org
      Estas charlando con Javier EB2DSN, responsable de eb2dsn.ampr.org
      ^] para finalizar.

      Buenos dias, chavalote

   Tambien podemos hacer uso del telnet, como antes hemos explicado, tecleando

      C:\> telnet eb2dsn.ampr.org 87

   Con este metodo podemos charlar con la estacion que queramos, si esta
activa. Sin embargo, debemos conocer de antemano que tal estacion existe.
Pero uno no saber que personas estan activas en este mismo momento: tiene
que ir probando estacion por estacion.

   Otra posibilidad es conectarse a una estacion Unix, y charlar con algun
usuario conectado a tal estacion. Para eso, Unix proporciona el comando
'talk'. Con 'who' (quien) podemos saber que usuarios hay conectados en
esa estacion, y con 'talk <usuario>' podemos charlar con el.

      $ who
      javier   tty1     Dec  2 10:07
      $ talk javier
   
   Ahora aparecera una pantalla partida donde podras charlar con el otro
usuario.

   Con esto podemos saber los usuarios que hay en un sistema al que tengamos
permiso acceder (tenemos una cuenta de usuario, a la que entramos con nuestro
nombre de usuario y 'password' a traves de TELNET). Sin embargo, con 'talk'
podemos hablar con usuarios de otras estaciones, como:

      talk eb2dsn@ea2rcf.ampr.org

y podremos charlar con el usuario 'eb2dsn' de ea2rcf.ampr.org si este esta
conectado al sistema. Ahora, como saber si tal usuario esta conectado, si no
tenemos acceso a la estacion, en nuestro caso ea2rcf.ampr.org ? Para eso hay
otro servicio, en el puerto 79 de TCP, llamado 'finger'. Este es un servidor
que proporciona informacion del sistema y sus usuarios, de forma parecida a la
instruccion 'who'. De esta forma, para saber los usuarios en una maquina:

      C:\> finger ea2rcf.ampr.org

para saber informacion sobre el usuario 'eb2dsn':

      C:\> finger eb2dsn@ea2rcf.ampr.org

   El formato de la informacion dependera del servidor finger. Por supuesto,
al ejecutar 'finger' en nuestra maquina estamos ejecutando el cliente 'finger'
para que se ponga en contacto con el servidor 'finger' de la maquina.

   Pero basta por hoy. En el proximo mensaje terminaremos el tema de las
'charlas' con el sistema de conversaciones por excelencia: CHAT / IRC.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (8)

   Hola a todos:

   En los primeros mensajes hablamos del funcionamiento basico de TCP/IP y las
ventajas que ello aporta sobre la red de packet actual. Posteriormente hemos
pasado a analizar sus aplicaciones, teniendo en cuenta tambien sus ventajas
para los radioaficionados. Estudiamos algo de transferencia de ficheros con
FTP. Despues entramos en el mundo del acceso remoto y sus interminables
posibilidades con TELNET.

   ==============
     CHAT / IRC
   ==============

   En ese momento estabamos hablando de conversaciones "teclado a teclado", lo
que ahora llamare "en tiempo real", ya que se producen en ese mismo momento, a
diferencia del correo electronico, por ejemplo, que es "en diferido": la
escritura y lectura del mensaje no se producen en el mismo momento.

   Sin embargo, este tipo de conversacion en tiempo real es tambien interesante
sobre todo si mas de dos personas pueden participar en la misma. Con esa idea
surgio lo que se llama el 'chat' (chat= charlar, conversar).

   Voy a prescindir de todo aspecto tecnico. Solamente decir que en los
programas NOS y afines el 'chat' aparece como 'convers'.

   Veamos un ejemplo (totalmente imaginario). Nos conectamos al 'chat', ya
sea con un programa especifico de 'chat', con un TELNET a un puerto
determinado, o invocando el programa en un acceso remoto. Nos aparecera una
serie de "canales". En el convers los canales son numeros, pero en Internet
podemos encontrar sistemas donde cada canal el un nombre, por ejemplo:

    tnc         TNC-2, Kantronics, ...
    baycom      El famoso modem baycom y su uso
    tsthost     Unete al activo grupo de tsthost-eros en EA
    #alta       Para los que quieren ir rapidos
    tcpip       Charla de los tcpip-eros espaoles
    mods        Solicita y ofrece tus mods en este canal

Como vemos, tras el nombre del canal hay una breve descripcion de sobre que
se trata.  Con el comando adecuado, entraremos en el canal que nos apetezca.

   Imaginemos que queremos entrar al canal de altas velocidades:

      > join #alta
      Has entrado en el canal #alta.
      Estan presentes ea2xxx, ea2yyy, ea1xyz, eb7zxy.
      <eb7zxy>: Prefiero utilizar el G3RUH. He hecho pruebas y va mejor.
      <ea2yyy>: Tu corresponsal tenia un modem G3RUH tambien?
      <ea2xxx>: Alguien ha subido el G3RUH a 19200 ?
      ea4ttt se une al canal
      <eb7zxy>: Asi es.
      <ea2yyy>: Si pruebas con un Baycom (96 o 97) no ira mejor.
      ea1xyz se va del canal
      eb2dsn te invita a unirte al canal tcpip
      <eb2zxy>: Es que no son compatibles?

   Puede parecer un autentico caos: conversaciones que se cruzan, gente que
sale y entra. Al principio puede costar acostumbrarse. Sin embargo tambien
tenemos una serie de comandos del 'chat', como saber en un momento dado los
usuarios que hay en un canal o en todos los canales, el enviar lineas privadas
(que solo las lea el receptor), entrar en canales privados, invitar a usuarios
que esten en otros canales a tu canal, etc.  

   Ya vemos que con este sistema pueden hablar varios usuarios en directo.
Sin embargo, tienen que conectarse todos a la misma maquina. Para evitar ello
se creo el IRC (Internet Relay Chat) que une varios chats en varios nodos
convirtiendolos en un unico super-chat.

   Por ejemplo, una aplicacion tipica del IRC es la red de packet cluster
(ahora no entramos en si lo hace sobre TCP o UDP, sino en el propio uso de
la utilidad). Montando un IRC en el que participen todas las BBS's, se
puede montar una serie de canales 'chat' dedicados cada uno a un segmento
de la banda o a varios. Ejemplo hipotetico:

    10m-DX       El canal de los 10 metristas
    15m-DX       El mejor DX internacional en 15 metros
    20m-DX       La banda reina del DX
    40m-DX       Todo lo escuchado en 40m 
    80m-DX       Todo lo que se escucha en 80m
    160m-DX      Solo para los DX mas especiales
    12-17-30m-DX Las ultimas bandas de la HF
    10a20m-DX    Lo mejor de las altas frecuencias
    30a80m-DX    Lo mejor de las bajas frecuencias
    HF-DX        El mejor canal para el DX en HF en castellano   
    VHF-DX       Esporadica, FAI, lo mejor de la VHF
    UHF-DX       Tambien la UHF-
    SHF-DX       Solo para superespecialistas
    VUSHF-DX     Citas, contactos, EME, lo mejor de las microondas
    satel-DX     Trabajas satelites? Este es tu canal
    intruder     Avisos de intrusos en las frecuencias

   Por supuesto, podria haber canales dedicados no al cluster, sino a comentar
sobre cada banda. Ya veis que algunos canales se solapan, pero es que cada uno
desea que sus preferencias sean atendidas. Si estas esperando avisos de todas
las bandas, tu canal seria HF-DX. Si solo quieres 10 metros, tu canal seria
10m-DX. Si quieres 10 y 15 metros, tienes la opcion de ponerte en HF-DX, o en
10m-DX y 15m-DX alternativamente, o, si hay mas interesados, crear un canal
especifico para ello. El proposito de los canales debe responder a las
necesidades de los usuarios, porque no hay nada mas tonto que un canal al que
no se conecta nadie.

    El manejo dentro del canal, con sus comandos especificos, es similar al
manejo en un packet cluster. De todas formas, tambien se puede montar una
red de cluster con aplicaciones especificamente para cluster, utilizando algun
puerto no estandar para hacerlo. Esto son solo ejemplos de las posibilidades
que nos ofrece TCP/IP, no pretendo decir cual es el metodo mas adecuado.

---------------------------------------------------------------------------

   Aprovechando que este mensaje es mas corto de lo habitual me gustaria
hacer algunos comentarios.

   El primero, que ya nos queda poco, pero lo mas interesante, para terminar:
el correo electronico, las news, y el archiconocido Web.

   Segundo, que he recibido algunas preguntas sobre temas que en principio
no iba a comentar por aqui (donde conseguir los numeros? que software hay?
existe alguna red TCP/IP por aqui?). Asi que al final, tratare de responder
a todas estas cuestiones y otras que querais hacer, si puedo.

   Tercero, que las respuestas solicitando que continuara me han llegado
(aparte de mi BBS en Alava) de Vizcaya, Cantabria y Asturias. Asi que no se si
mis mensajes no llegan mas lejos porque estamos en una "isla" de forward aqui
en la Cornisa Cantabrica, si lo que no llegan son los mensajes de vuelta, o si
simplemente, fuera de aqui el tema no interesa. En todo caso he tratado de
responder todos los mensajes que me han llegado de los sitios citados. Si a
alguien no le ha llegado, puede ser porque no me haya llegado a mi, o porque mi
respuesta se haya perdido. En todo caso pido disculpas, y si me lo volveis
a enviar y me llega, lo tratare de responder otra vez.

   Como veis, no estamos en una red de TCP/IP precisamente.


                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (9)

   Hola a todos:

   Despues de un breve paron, continuo con esta serie de articulos sobre
aspectos practicos del TCP/IP.

   Hoy nos toca hablar de la aplicacion con la que estamos mas habituados:
el correo electronico (e-mail).

   ========
     SMTP
   ========

   El Protocolo Simple de Transferencia de Correo (SMTP= Simple Mail Transfer
Protocol) es el protocolo de aplicacion mas conocido de Internet y el mas
usado hasta ahora. Tecnicamente no es diferente de otros que hemos visto:
hay un cliente, que es el que quiere enviar ('poner' o 'dejar') el mensaje
y hay un receptor que es el servidor, encargado de su distribucion. Pero
su funcionamiento es muy diferente a lo que estamos habituados, asi que
lo explicaremos paso a paso para que no nos suene "raro".

   EL ESTANDAR RCF-822

   Lo primero que hay que explicar es que los mensajes en TCP/IP (y por
lo tanto en Internet) no son simplemente un fichero de texto que hay que
enviar un destino. Los mensajes tienen un formato definido claramente en
un estandar denominado 'RFC-822'. El estandar define un mensaje como un
texto dividido en dos partes: la cabecera y el cuerpo. En la cabecera hay
una serie de campos, algunos obligatorios, otros opcionales pero definidos,
y otros de formato libre. En el cuerpo viaja el mensaje propiamente dicho,
en formato texto.

   Veamos un mensaje como ejemplo:

>From eb2dsn@eb2dsn.ampr.org Wed Dec 10 19:03:06 1997
Received: by debian
	id m0xfqTR-000DnNC
	(Debian Smail-3.2 1996-Jul-4 #2); Wed, 10 Dec 1997 19:03:05 +0100 (CET)
Message-Id: <m0xfqTR-000DnNC@debian>
Date: Wed, 10 Dec 1997 19:03:05 +0100 (CET)
From: eb2dsn@eb2dsn.ampr.org (Javier EB2DSN)
To: eb2ebu@ea2rcf.ampr.org (Ignacio EB2EBU)
Subject: Pruebas

Esto es una prueba de correo electronico

   La primera linea "From " la pone el lector de correo para indicar que
comienza un nuevo mensaje (el lector de correo guarda todos los mensajes uno
tras otro en el mismo fichero, y estas lineas sirven para separar e identificar
los diferentes mensajes).

   Despues comienza la cabecera, formada por varios campos. Cada campo tiene un
nombre, seguido por ":" seguido por la informacion de dicho campo. Por ejemplo,
el campo "From:" es el campo donde se guarda la informacion del remitente del
mensaje, es en el mensaje:

From: eb2dsn@eb2dsn.ampr.org (Javier EB2DSN)

   El contenido de este campo "From:" es la direccion de origen del mensaje,
formada por el nombre del usuario, y el nombre y dominio del sistema donde
esta, separados por el signo de arroba "@" (este simbolo significa "at", que
quiere decir "en", asi que la direccion de procedencia es de "eb2dsn" en la
estacion TCP/IP "eb2dsn.ampr.org" -no tiene porque coincidir nombre del usuario
con nombre de la estacion- ). Lo que aparece entre parentesis es ignorado por
el gestor de correo, y se utiliza para poner el nombre completo o en algunos
casos el apodo, ya que muchos gestores de correo muestran esta informacion como
el emisor del mensaje en vez de la direccion.

   Otros campos interesantes son el "To:" que es la direccion de destino (de
nuevo, entre parentesis se puede poner lo que se desee, ya que el sistema de
correo no lo tiene en cuenta). El campo "Date: es la fecha de creacion del
mensaje (la fecha de llegada del mensaje la apunta el gestor de correo en la
linea "From ", detras del emisor del mensaje). El campo "Message-Id:" o MID es
una informacion que el sistema genera y que es unica para cada mensaje (o
deberia serlo), y funciona como el BID de los mensajes en AX.25.  Finalmente,
el campo "Subject:" es el tema (el titulo) del mensaje.

   Los campos mencionados hasta ahora son considerados "obligatorios". Pero
existen bastantes otros que son opcionales. Por ejemplo, los campos "Received:"
son como las lineas R: de los mensajes AX.25 (solo que pueden ocupar mas de una
linea, y normalmente lo hacen). Cada vez que se pasa por un sitio de correo
este le aade una linea "Received:" con informacion de cuando paso por alli,
etc. Tambien, como en la mensajeria AX.25 (la mensajeria no es AX.25, es en
realidad un estandar de las BBS's, pero voy a seguir con esta denominacion)
todas estas lineas pueden ser sustituidas por un campo "Path:".

   Hasta ahora hemos visto las similitudes, veamos ahora las diferencias.
Por ejemplo, existe un campo llamado "Reply-To:" donde el emisor pone la
direccion de destino a la que quiere que se le manden las replicas. En FBB
se hace con el comando 'SR' y se utiliza la direccion de origen para replicar.
Pero si, por ejemplo, estas enviando el correo desde cualquier otro sitio que
no es el habitual, y quieres que las respuestas vayan a tu sitio habitual,
puedes utilizar este campo. El gestor de correo comprobara primero si existe
este campo, y si no existe enviara la replica a la direccion de origen. Otros
gestores al enviar el correo ponen siempre esta linea con la misma direccion
que la de origen, por si el usuario la quiere cambiar.

   Hay otros campos opcionales, pero tal vez los mas interesantes de cara al
usuario son los campos "X-". Estos son campos que los usuarios aaden para su
propio uso. Para ello tiene que haber varios usuarios que los utilicen; pero
como estos campos son utilizados sobre todo por gestores de correo y listas de
correo suele haber algunos estandar, como el "X-Mailer:", donde el propio
gestor de correo (Mailer), pone su nombre y version.

   Otros campos opcionales interesantes son el "Cc:" y el "Bcc:". Estos campos
permiten enviar un mensaje a mas de un destino. En "Cc:" (Carbon Copy) se
puede incluir una lista de destinos separados por comas a los que se quiere
que se mande una copia del mensaje original. Los usuarios receptores del
mensaje sabran que es una copia, y sabran a quienes mas se le ha enviado, ya
que el campo "Cc:" se conserva hasta el destino. En cambio, el campo "Bcc:"
(Blind Carbon Copy) funciona igual, pero el campo desaparece, de forma que el
receptor no tiene informacion sobre si el mensaje se ha mandado a mas usuarios
o no. Por lo menos con la informacion que aporta la cabecera del mensaje.


   Hemos visto unos cuantos campos cabecera de los mas conocidos. Hay muchos
mas, tanto libres (con el prefijo "X-") como optativos. Despues de todos los
campos de la cabecera, debera haber una linea en blanco que marca el comienzo
del cuerpo del mensaje (el mensaje en si).

   Dentro de los que es el cuerpo del mensaje, podemos optar por escribir
el mensaje ascii. Algunos gestores de correo aaden campos identifican la
codificacion empleada en el mensajes (ibm850, ibm437, latin-1, etc) de forma
que uno no tiene que preocuparse de la conversion de acentos y simbolos: el
gestor de correo lo hara por el.

   Tambien se pueden enviar ficheros binarios codificados como texto, tal
y como se hace con el 7plus en AX.25. Sin embargo en Internet se emplea como
estandares uuencode y uudecode para la misma tarea.

   Como aadido a este sistema, se creo el estandar MIME: Extensiones Multi-
proposito del Correo de Internet. Este estandar establece un formato de
texto en el que se pueden incluir tanto texto como ficheros binarios que se
asocian con aplicaciones: de esta forma se pueden incluir texto con formato,
o comprimido, graficos, sonidos, animaciones y ficheros binarios dentro de un
mensaje (con el tamao de mensaje que eso supone, pero es que en Internet no
hay limite).

   La ventaja de tener un estandar en los mensajes es obvia: todos los lectores
y/o escritores de mensajes que se quieran hacer son compatibles, ya que se
deben adaptar al estandar. Ademas, esto aporta otras ventajas para los usuarios
ya que algunos de las cosas vistas, asi como otras no vistas, facilitan tareas
tipicas del correo electronico que no disponemos en el correo AX.25.

   INTERCAMBIO DE MENSAJES CON SMTP

   Hemos hablado del formato del correo, ahora nos queda ver como se realiza
la transferencia de mensajes. Para empezar, el intercambio de correo se
realiza entre un cliente y un servidor que hablan el protocolo SMTP a traves
de TCP (el servidor estara en el puerto 25). El cliente abre la conexion,
saluda al servidor y se identifica, y a continuacion avisa de que va a enviar
un mensaje, y lo envia, asi repetidamente hasta transferir todo el correo
que tenga pendiente con esa maquina. El servidor va reportando si sus comandos
han tenido exito o no al cliente. Al final hay una despedida y cierre de
conexion.

   Hasta ahora nada nos ha chocado, pero hay que sealar varias diferencias
con AX.25:

   * El intercambio de correo no funciona en el mismo "lugar" que una
conexion a la BBS (que seria via TELNET u otro puerto especifico), eso
significa que no hace falta ni cabeceras [H$-NOS], ni comandos especiales
tipo SF, accesibles a los usuarios. Todo lo que sea necesario lo negociara
SMTP pero de una forma transparente: el usuario no se entera.

   * Los mensajes son hechos en la estacion de cada uno: no hay ocupacion
del canal por estaciones que estan poniendo el mensaje directamente (esta
mala practica cada vez esta mas en desuso con programas como TPK, TSTHOST
o WINPACK, pero hasta ahora se mezclaba la conexion a la BBS con el envio
de mensajes, con la consiguiente complejidad de estos programas a la hora
de poner mensajes -que si macros, que si espera cierto tiempo a recibir
ciertos caracteres, etc).

   * Al haber un lugar para intercambio de correo, este es rapido (no hay
que esperar a los tipicos mensajes de bienvenida o informacion de la BBS,
ni sincronizarse por cierto tipo de prompt -que habra que definir-, etc).

   * Un inconveniente es que el estandar no define un intercambio de mensajes
comprimido (tampoco costaria mucho, la verdad).

   * Sin embargo, tiene la ventaja de la conectividad IP: el usuario se conecta
directamente con la maquina receptora del mensaje y lo deja alli. No es
necesario el famoso '/ACK': si el mensaje ha sido transferido, lo ha sido
directamente a la maquina destino, y el usuario lo va a recibir seguro.

   * Esto no significa que desaparezcan las BBS's o el "forward" de correo.
Por un lado, para recibir sino el correo o tenemos las 24 h el ordenador
conectado, o limitamos a recibir el correo entre ciertas horas y/o dias, o
utilizamos una estacion que si este las 24 horas en marcha (la tipica BBS de
la provincia) de la que bajaremos nuestros mensajes automaticamente con el
protocolo de recogida de correo POP (Post Office Protocol = Protocolo de la
Oficina de Correos). En cuanto al "forward" hay que decir que tambien en
Internet hay sitios que actuan como BBS's intermedias, de forma que un mensaje
puede pasar por varios sitios antes de llegar. Lo que pasa es que el numero de
sitios por donde pasa se reduce mucho, ya que en cada "salto" puede suponer
que la conexion TCP pase por varias estaciones IP.

   Ademas de todo esto, la principal ventaja de utilizar este sistema es su
compatibilidad con Internet: podemos utilizar cualquier herramienta de gestion
de correo de Internet, tanto esa gratuita como aquella que nos costo tan cara,
y gestionar ambos correos de igual forma. Y hay que reconocer que hay
aplicaciones graficas muy comodas actualmente para la gestion del correo, por
ejemplo acompaando a ciertos sistemas operativos o a ciertos navegadores de
Internet, ademas de otras gratuitas, de shareware, o simplemente comerciales
(hay que pagar, pero con pagar un programa en vez de dos es suficiente).

   En el siguiente mensaje seguire hablando del correo, pero esta vez del
correo general: las news.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (10)

   Hola a todos:

   Siguiendo con las aplicaciones TCP/IP vamos a tratar el tema de los mensajes
generales o boletines. Sin embargo, antes de pasar al mecanismo tipico de las
news, hare un breve repaso historico centrandome en otro mecanismo similar
basado en el correo personal (SMTP): las listas de correo.

   EL PRINCIPIO: LAS LISTAS DE CORREO

   En un principio solo existia el correo electronico. En un principio del
TCP/IP y de Internet, claro. Si uno queria mandar el mensaje a varias personas,
enviaba varios mensajes (Entonces no existia siquiera el campo Cc:). En seguida
se aadio a los gestores de correo ('mailers') la posibilidad de escribir un
destino especial, un alias, que correspondia a varias direcciones introducidas
previamente por el usuario. Por ejemplo:

   tcpiperos :  juan@hola.org pepe@adios.com ea4dqx@qsl.net

hace que si yo envio un mensaje con destino "tcpiperos" el sistema me envie el
mismo mensaje a todos los que tengo definidos a continuacion en el fichero de
alias. Este mecanismo sigue estando presente en la mayoria de los 'mailers'.

   De esta forma, si cada uno de ellos tenia a su vez un alias con las
direcciones de los otros tres, es posible enviarse correo general, aunque en
este caso lo de 'general' queda reducido a 4 personas. Imaginaos cambiar
mensajeria entre 100 personas con este sistema. Primero, hay que tener una
lista muy grande, de 99 personas cada uno. Por lo tanto, las 100 personas
tienen que haberse puesto de acuerdo previamente enviando sus direcciones.

   Pensar ahora en los mecanismos para aadir uno mas a los que ya hay, que
otro se vaya, que otro cambie de direccion... La gente tendria que cambiar cada
uno en su fichero de alias todas estas variaciones. Es seguro que algunos lo
harian, otros no, otros mal... el sistema empieza a funcionar mal y es
incoherente. A la larga los ficheros estarian tan inconsistentes que seria un
fracaso. Pretender que tanta gente este preocupados de estos 'detalles
administrativos' es una pretension vana. Asi que este metodo solo funciona con
el grupo de amigos pequeo y estable, es decir, que rara vez cambia.

   Por otro lado fijaos la carga del sistema: por cada mensaje tenemos que
enviar en realidad 100.

   El problema de este metodo es que es un sistema distribuido: todos los
usuarios tienen que tener la lista de los participantes, y esta lista tiene que
mantenerse coherente (todos tienen que tener la misma lista a lo largo del
tiempo). Como los usuarios no van a permitir que nadie ande tocando
directamente su fichero de 'alias' desde el exterior, se impone que esta lista
de direcciones sea unica, es decir, que resida en un unico sitio. Entonces los
usuarios envian su correo a una direccion especial, por ejemplo
tcpiperos@eb2dsn.ampr.org. En esta estacion no existe un usuario llamado
"tcpiperos", pero el servidor de correo, que tiene un mecanismo propio de
'alias', envia a todas las direcciones que aparecen tras el alias el mensaje.
Por ejemplo, en eb2dsn.ampr.org habra una linea:

   tcpiperos : eb2dsn juan@hola.org pepe@adios.com ea4dqx@qsl.net

El primer usuario no necesita estacion destino ya que es un usuario de la
maquina actual (eb2dsn.ampr.org) y se le envia el mensaje localmente (sin salir
a la red).

   El mecanismo de actualizacion es muy sencillo. El administrador de la
estacion, eb2dsn.ampr.org en este caso, sera el unico que aada mas direcciones
o las quite o las modifique. El resto de la gente no tiene porque preocuparse,
con mandar el mensaje a la direccion de la lista es suficiente. Esto es lo que
se llama una LISTA DE CORREO.

   Las listas de correo son muy populares en Internet. Primero porque se
desarrollaron muy pronto. Y segundo porque fueron los primeros foros donde mas
de dos personas compartian sus experiencias y comentarios. Como curiosidad
historica hay que decir que la primera lista de correo no tecnica que hubo en
la entonces ARPANET (ahora Internet) fue la de S.F. (Ciencia-Ficcion) y al
permitirla los administradores de la red de entonces, crearon un precedente de
libertad y tolerancia que ha perdurado y ha sido el signo de identidad de
Internet hasta ahora.

   Pronto hubo muchas listas de correo en Internet (cada una hablaba de un tema
especifico), y la gente se apuntaba y se desapuntaba a una velocidad creciente.
Estaba claro que que era un engorro cada vez que uno queria apuntarse o
desapuntarse (lo que se dice 'suscribirse' o 'desuscribirse' en el argot de las
listas) para el administrador del sistema o gestor de la lista (que podian ya
ser personas diferentes, por el numero de listas y el interes que cada uno
tenia en ellas). Se imponia un sistema automatico.

   Asi aparecieron los "mayordomos", "robots" y los "listservers" (servidores
de listas). Estos no son mas que diferentes sistemas (software) para gestionar
varias listas de correo en una misma direccion de correo, de forma automatica.
Veamos un hipotetico ejemplo para que todo quede mas claro:

   Tenemos un mayordomo en eb2dsn.ampr.org. Esto quiere decir que tenemos la
direccion de correo mayordomo@eb2dsn.ampr.org para saber que listas de correo
hay disponibles, suscribirnos a las que queramos, desuscribirnos, pedir ayuda u
otros servicios de la lista. Para suscribirnos por ejemplo a la lista 'tcpip'
enviamos un mensaje a mayordomo@eb2dsn.ampr.org poniendo en el cuerpo:

      subscribe tcpip juan@hola.org

si somos juan en hola.org. A partir de ahora podemos mandar todos los mensajes
que queramos a la lista a traves de la direccion tcpip@eb2dsn.ampr.org. Para
desuscribirnos, envia a la misma direccion 'unsubscribe tcpip juan@hola.org'.

   Estos comandos y direcciones pueden cambiar dependiendo si utilizas
listserv, mayordomo u otro sistema, pero en esencia son todos similares.

   Aunque con este sistema es posible una comunicacion general entre los
interesados a un tema, el sistema no es perfecto. Primero, uno tiene que saber
que la lista existe.  Hay en algunos sitios ficheros de texto con una lista
enorme de las que existen. Pero las listas aparecen y desaparecen con rapidez
por lo que no estan actualizados ni estan todas las listas.

   Ademas muchas listas eran "cerradas" en el sentido que eran un grupo de
amigos entusiastas en un tema, y no se preocupaban de dar publicidad a la lista
porque no les interesaban los "extraos" (otras veces la lista era "privada" y
no existian mecanismos de suscribirse).

   Otro problema era que habia a veces muchas listas sobre un mismo tema.  Uno
podia apuntarse a varias, pero el lio en su buzon de correos y sobre todo en su
cabeza era mayusculo.

   Por otro lado, el problema de la carga del sistema sigue estando ahi. Un
mensaje a una lista de 100 personas genera un trafico de 101 mensajes. Ahora no
es una carga para la maquina del usuario, pero si lo es para la maquina donde
esta la lista que debe enviar diariamente cantidades ingentes de correo (100
mensajes de entrada pueden significar 5.000 mensajes de salida para una media
de 50 personas por lista).

   Por todo esto hay un limite practico del tamao de una lista de correos, a
partir del cual o hay demasiado correo, o la maquina distribuidora esta
sobrecargada.  

   Tambien hay que contar que los mensajes se transmiten enteros a los usuarios
cuando estos tal vez ese mensaje no le interesaba solo con leer el titulo y/o
el remitente. No hay listados de mensajes donde elegir los mensajes, ya que el
sistema esta basado todo en el correo personal.

   Se vio claramente que las listas de correo no eran un buen sistema. Pero
hasta los finales de los 70 el numero de usuarios de ARPANET/Internet fue
insuficiente para que se planteara una alternativa. Fueron unos estudiantes
americanos los que crearon el primer sistema de 'news'.

   Esto no significa que las listas de correo hayan desaparecido. Las listas
siguen siendo una herramienta bastante utilizada para crear foros de tamao
medio (entre 10 y 1000 personas) sobre temas lo suficientemente especificos
para no ser tratados en las 'news' o por deseo de sus participantes.

   Las listas de correo pueden ser implementadas en cualquier sistema de correo
personal mediante software adicional si no es directamente. Por lo tanto lo
pueden ser en el correo de las BBS's AX.25. Pero, son un sistema adecuado para
la red AX.25? En principio, si los receptores de la informacion son unos pocos
interesados, es mas eficiente enviar el mensaje a 10 o 15, que enviarlo a @EA,
que es enviarlo a las mas de 100 BBS's de EA. Pero por otro lado, en cuanto ese
numero aumenta, estaremos utilizando mas ancho de banda que si fuera un
boletin, aunque siempre con la ventaja de no interferir en los que no les
interesa. El inconveniente mas grande es el propio funcionamiento de la red con
la mensajeria personal. El poco interes por hacer funcionar bien este sistema
impide el desarrollo de por otro lado tan conveniente habito de las listas de
correo.

   UN SISTEMA MAS ADECUADO: NEWS

   Se llama 'news' a un sistema de translado de 'articulos' (lo que nosotros
llamamos boletines) de caracter general. Es decir, los 'articulos' son mensajes
pero que no tienen un destinatario especifico, sino que son publicos. En cierta
forma se les llama articulos porque "son publicados" (hechos publicos) en las
'news' para quien le interese leerlos.

   El sistema de 'news' han pretendido solucionar los problemas de las listas
de correo en el campo de la distribucion de mensajes a gran escala de una forma
lo mas eficiente posible. Ha sido diseado e implementado pensando en grandes
volumenes de mensajeria. Actualmente el volumen de la mensajeria de las 'news'
se calcula de varios Gigabytes (miles de Megabytes) diarios.

   Las 'news' se convirtieron, antes de la aparicion del Web, en el principal
medio de comunicacion de Internet. Pero el sistema puede superar y de hecho
supera los limites de Internet, propagandose a otras redes. Por ello, se le ha
denominado USENET, como si fuera una red independiente montada sobre Internet.

   En el proximo mensaje veremos en profundidad las 'news'.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (11)

   Hola a todos:

   Ahora que todos conocemos algo mas sobre el funcionamiento de las listas de
correo, entramos de lleno en el apasionante mundo de las 'news'.

   'News' significa "noticias", pero tambien "nuevos". Y es que los articulos ,
por su volumen, despues de estar presentes unos (pocos) dias son borrados (se
dice en el argot que "expiran"). Asi que, sin ser un medio "en tiempo real"
(como el IRC), las 'news' son foros de opinion y conversacion muy dinamicos, y
siempre a la ultima. Articulos de respuesta a los tuyos pueden aparecer en
horas o minutos.

   La forma de funcionar en las 'news' es completamente diferente de los
boletines de la red de packet. No hay una lista con todos los mensajes porque
diariamente podrian aparecernos UN MILLON de mensajes.

   Para ser operativos, esta mensajeria tiene que ser dividida. El sistema de
'news' se halla dividido actualmente en unos 20.000 grupos diferentes, de los
cuales unos 10.000 son de ambito mundial, mientras el resto son de ambito
regional (lo cual no significa que no puedan ser leidos desde cualquier otra
parte del globo).

   Estos grupos, llamados grupos de noticias, 'newsgroups', foros de opinion y
otros nombres mas, son similares a listas de correo, pero con la diferencia de
que todas las listas son conocidas y de acceso publico. Ademas, suele haber un
solo grupo para cada tema -en general-. Los grupos pueden ir creandose o
desaparecer a lo largo del tiempo, pero el usuario es avisado de estos hechos
de forma que puede suscribirse a nuevos grupos que surjan con el tiempo.

   La primera vez que entremos en el sistema de 'news' o noticias, lo cual
haremos con cualquier 'lector de noticias' (un tipo de programas especifico
para esta tarea) nos aparecera una lista con todos los grupos de noticias
existentes en ese momento. Podremos elegir entonces, a traves del nombre, los
grupos de los cuales queremos que el 'lector de noticias' nos muestre los
articulos.

   A partir de ese momento podremos entrar en el lector y elegir uno de los
grupos seleccionados del cual nos aparecera una lista de los articulos
disponibles. Entonces podremos seleccionar los que, a nuestro juicio, por su
titulo, remitente, fecha,... nos interese leer. Por otro lado, los modernos
lectores de noticias tienen la capacidad de seguir 'threads' (hilos), que son
las respuestas, contrarespuestas y recontrarespuestas originadas por un
mensaje, de forma que se puede seguir el hilo -de hay su nombre- de la
conversacion comodamente. Tambien podemos enviar respuestas a los articulos
aparecidos, tanto a traves del correo personal (para ello se utiliza el gestor
de correo del usuario) como a traves otro articulo publicado en ese mismo grupo
o en otros. Otras facilidades del sistema de 'news' las dejamos para los
lectores interesados.

   Los articulos de las 'news' son mensajes con un formato parecido al correo
personal. Tambien se dividen en 2 partes, cabecera y cuerpo, separados por una
linea en blanco. La cabecera tambien esta formada por una serie de campos.  Sin
embargo los campos que hay y su funcion varian de un sistema a otro.  Veamos un
ejemplo -real, pero acortado- :

------------
Path: news.sarenet.es!newsfeed.mad.ibernet.es!news.mad.ibernet.es!not-for-mail
From: hernando1@redestbxx.es (Guitito)
Newsgroups: es.comp.os.linux,es.charla.actualidad,es.alt.anuncios
Subject: Re: Pentium error ... Y AHORA QUE ??
Date: Tue, 25 Nov 1997 18:59:22 GMT
Organization: Unisource Espana NEWS SERVER
Lines: 74
Message-ID: <347b1bf4.6152580@news.redestb.es>
References: <347044FF.D1ACD0A4@redestb.es>
NNTP-Posting-Host: ppp8.206.redestb.es
Mime-Version: 1.0
X-Newsreader: Forte Agent 1.0/32.390

On Mon, 17 Nov 1997 14:22:08 +0100, Ivantxuyn <ivantxuyn@redestb.es>
wrote:

>Hola a todos
>Bueno, ahora que la mayoria de los usuarios sabemos que existe
>un error en los microprocesadores Pentium Classic y MMX, ahora
>que vamos a hacer ??

------------

   DENOMINACION DE LOS GRUPOS

   Hemos dicho que un mensaje no se manda a un usuario determinado. Pero si se
debe mandar a un grupo determinado. El mensaje anterior ha sido mandado a los
siguientes grupos: es.comp.os.linux, es.charla.actualidad y es.alt.anuncios.
Por que estos nombres?

   Los grupos de noticias tienen nombres como:

   comp.os.msdos.games.doom
   comp.os.unix.admin
   rec.radio.amateur.packet
   es.sci.matematicas

   Para empezar, el nombre de cada grupo esta formado por varias palabras
separados por puntos. La primera palabra es la jerarquia principal, y hay
siete diferentes oficiales:

   news   temas relacionados con la propia red de noticias USENET
   comp   temas relacionado con los computadores (ordenadores)
   rec    temas recreativos: juegos, hobbys, aficiones, etc
   talk   temas de charla, polemicas, discusiones, debates, etc
   sci    temas relacionados con las ciencias: matematicas, fisica, etc
   soc    temas sociales y relacionados con la sociedad
   misc   miscelanea, es decir, lo que no cabe en los anteriores

   Dentro de estas 7 jerarquias principales hay subjerarquias. Por ejemplo,
dentro de comp (computadores tienes) 'comp.lang' (lenguajes de programacion),
'comp.os' (sistemas operativos). A su vez que dentro de una subjerarquia hay
mas subjerarquias, y asi hasta el infinito (aunque mas de 5 puede considerarse
pedante). Una serie de grupos que comparten la misma jerarquia suele denotarse
con un "*". Por ejemplo, los grupos de sistemas operativos puede ser comp.os.*,
queriendo decir que nos referimos a todos los grupos cuyo nombre empieza por
'comp.os'

   Los temas tratados y la cantidad de divisiones dentro de un tema se
establecen dinamicamente, segun las necesidades de los usuarios. Si un grupo
tiene mucho correo de diversos temas, se subdivide en varios subgrupos. Si
tiene poco trafico puede desaparecer.

   Pero, Quien determina que grupos hay y cuales no? Existen una serie de
reglas que hay que cumplir y una serie de plazos (que no voy a comentar) y al
final hay una votacion, en la que puede participar cualquiera, que el grupo
debe pasar: tiene que alcanzar un numero minimo de votos SI y un cierto numero
mas de SI que de NO. Por eso cuando hay intentos de crear cierto tipo de grupos
(nazis, sectas, etc) hay llamadas generales a votar en contra. La no existencia
de los mismos es una responsabilidad por lo tanto de todos los usuarios.

   Sin embargo existe una jerarquia especial 'alt' fuera de estas 7, que se
hizo para albergar toda serie de grupos 'alternativos'. Los grupos de esta
jerarquia no requieren votacion, pero como contrapartida los sitios de reparto
de 'news' no estan obligados a transportar sus articulos. Dentro de estos
grupos hay desde algunos interesantes hasta otros "poco recomendables".

   Luego estan las jerarquias 'regionales'. Por ejemplo, la jerarquia "es.*"
son los grupos de Espaa. (como 'es.alt.anuncios' o 'es.charla.actualidad').

   Ademas hay otras jerarquias especiales. Algunas por ejemplo son 'copias' de
otros sistemas de mensajeria como los de fidonet, etc.

   Cual es el grupo de 'news' de los radioaficionados? En realidad hay varios,
todos dentro de la jerarquia "rec.radio.amateur.*" a nivel mundial. Dentro de
los grupos espaoles habia un grupo que creo era "es.rec.radioaficionados".

   ========
     NNTP
   ========

   NNTP es el Protocolo de la Red de Transferencia de Noticias (News Network
Transfer Protocol). Sin embargo, el sistema de 'news' no es solo este
protocolo. De hecho, las 'news' no se distribuian originalmente con NNTP, sino
que ha sido la popularizacion de las 'news' la que han hecho la aparicion de un
protocolo especifico y eficiente para ello.

   Ademas del protocolo NNTP hay todo un sistema especifico de almacenamiento y
acceso optimo a mensajes, de intercambio y de muchas cosas mas: es una
verdadera base de datos distribuida de mensajes. De esta forma se puede
conseguir manejar tan grandes volumenes de mensajeria de una forma eficiente.

   Lo primero que hay que remarcar es que cualquiera no tiene un servidor de
'news' (en Internet). Primero esta la cuestion del espacio (puede sobrepasar
los 50 Gigabytes). Segundo, hay que tener el sistema funcionando 24 horas al
dia, 7 dias a la semana. Tercero, hay que tener una conexion "gorda" si
queremos recibir tanto trafico. Cuarto, hay que contratar y pagar para
recibir los articulos a los grandes proovedores como UUnet, y el precio es
realmente caro.

   Esto ha significado que, aunque en teoria cualquiera pueda tener un servidor
de 'news', en la practica solo hay pocas organizaciones que se lo puedan
permitir (miles, frente a millones de usuarios), de forma que el sistema de
intercambio entre sistemas servidores de 'news' se mantiene limitado en numero
y es por tanto manejable.

   Los clientes se encuentran en los 'lectores de noticias' de los usuarios
normales. Los usuarios tienen que configurar en el lector cual es su servidor
(la maquina de la cual se baja los articulos de los grupos). Este servidor sera
en algunos casos el proovedor del usuario, en otros el servidor de RedIris,
el de la empresa, etc.

   Es decir, se sigue el modelo cliente/servidor, pero ahora las maquinas que
son capaces de proporcionar el servicio son solo unas cuantas determinadas. Y
es que el servidor debe guardar los articulos de todos los grupos, para que los
usuarios puedan elegir los que prefieran. En cambio, el cliente solo recibe lo
que pide y ni un grupo mas.

   Ya que lo hemos dicho en el caso de otros protocolos, el servidor de NNTP
se encuentra en el puerto TCP 119.

   NEWS EN TCP/IP+AX.25

   Ahora veamos como se puede utilizar esto en una supuesta "Internet de
radioaficionados", basada en TCP/IP sobre AX.25.

   Esta claro que las 'news' son el sustituto natural de la mensajeria general
(los boletines) de la BBS. Que ventajas aportan sobre esta?

   Por un lado, esta el tema de la organizacion. Como sabeis, en las BBS's tipo
FBB la lista de los mensajes generales es unica, y el usuario es el que debe
decidir sobre que mensajes lee y cuales no, inspeccionando las lineas una a
una. En FBB se utiliza el campo destino para seleccionar los mensajes de un
tema en concreto. Sin embargo, cada uno pone lo que le apetece. Por ejemplo,
para DX tienes campos como DX, DXINFO, DXNEWS, etc, con el consiguiente follon.
Muchos compaeros han hablado de la estandarizacion, consiguiendo solo ser
blanco de la ira de otros "colegas".

    Muchos, benditos ellos, mandan sus boletines a TODOS. Si son boletines,
seran para todos, no? Entonces hay que ir uno a uno y escoger los boletines por
el titulo. Claro, eso si el autor ha puesto un titulo que diga de que trata el
mensaje. Algunas veces, "por si acaso", te bajas mensajes que parece pueden ser
interesantes, pero luego son inutiles (es algo que confieso me fastidia mucho).

   Ninguno de los dos metodos asegura que leamos todos los mensajes emitidos
sobre un tema. Asi que tenemos que perder nuestro precioso tiempo bajandose
listados de mensajes los cuales la mayoria ni nos interesan, y luego
seleccionandolos. Otros sistemas de BBS si tienen el correo separado en areas.
Pero esta areas no estan organizadas jerarquicamente.

   Por lo tanto las ventajas de un sistema son obvias. Primero, para los
administradores, tienen un sistema eficiente, automatico, independiente de
rutas de mensajes (porque todo va sobre IP) y organizado. Los usuarios reducen
su tiempo en la seleccion y la aumentan su interes por lo que aumenta su
participacion en el sistema. Y en general, aumenta el trafico y por lo tanto el
medio es mas util para todos. Y ademas, como uno no recibe lo que no le
interesa, pues menos fricciones. Miel sobre hojuelas.

   Como serian estos grupos? En principio, para los radioaficionados hay una
jerarquia especial: 'ampr'. Por lo tanto, para EA la jerarquia deberia ser
ampr.es.*. Por ejemplo, podria haber grupos o subjerarquias como:

  ampr.es.dx      ampr.es.comp      ampr.es.mercadillo  ampr.es.digital.packet
  ampr.es.news    ampr.es.antenas   ampr.es.equipos     ampr.es.digital.rtty
  ampr.es.debate  ampr.es.binarios  ampr.es.vhf         ampr.es.digital.sstv

y muchos mas...

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red (12)

   Hola a todos:

   LA ESTRELLA ES... EL WEB

   Llevamos ya dos aos de auge de Internet en Espaa. Como todos sabeis, el
protocolo de Internet es el TCP/IP, que es el estamos tratando de describir en
esta serie de articulos. Asi que Internet ha aparecido aqui y alla a lo largo
de la serie.

   La pregunta es: Son las aplicaciones de Internet que hemos visto (FTP, news,
correo SMTP, TELNET, IRC,...) las que la han hecho tan atrayente? Puede que
para algunos si, pero no ha sido ninguna de ellas la aplicacion determinante
para la mayoria.

   Lo que realmente ha enganchado a millones de usuarios de todo el mundo,
muchos de los cuales con escasos conocimientos de informatica, ha sido el
archifamoso World Wide Web, mas conocido por sus siglas 'WWW' (se dice "uve
doble, uve doble, uve doble" o tambien "triple uve doble" y a veces tambien se
escribe como W3 -W elevado al cubo-). Tambien se le conoce simplemente como
Web.

   Seguro que todos habeis visto el Web en funcionamiento, ya sea por propia
experiencia o porque lo hayais visto en la Tele. Una pantalla grafica (suele
ser bajo Windows o sistema similar) donde aparece informacion compuesta por
texto, graficos, sonido, animaciones, y donde hay una serie de palabras o
frases remarcadas, botones, flechas, campos para rellenar datos, y otros
controles graficos. Pulsando con el raton en esos objetos pasaremos a otras
paginas de informacion (a otras hojas web) que pueden estar en la misma
estacion que la original, o en otra en cualquier otra parte del mundo.

   De esta forma nos sumergimos en una "Tela de Araa Mundial" (que es la
traduccion de "World Wide Web") donde, pulsando aqui y alla para leer
informacion relacionada, estamos saltando de un sitio del mundo a otro sin que
tengamos conciencia de ello ni tengamos que teclear o saber direccion alguna.

   Como veis el sistema del Web es parecido a la ayuda de Windows, pero una
ayuda sobre todas los temas que te puedas imaginar, con millones y millones y
millones de topicos a lo largo y ancho de todo el mundo.

   Esta facilidad de uso es lo ha hecho al Web tan popular. Digamos que es un
sistema "para todos los publicos". Ademas es muy espectacular, con el tema de
los graficos, sonido, animaciones, video,... las posibilidades son infinitas.

   URL's

   Seguro que habeis leido u oido hasta la saciedad las direcciones de Internet
de radios, televisiones, productos, marcas de coche, empresas,... Estamos
inundados con la moda!. Pero que es esto del "http://..." ?

   Cuando se hizo el World Wide Web, se penso en integrar todos los recursos de
informacion que hasta ahora aparecian diseminados en distintos protocolos.
Pero entonces, no vale solo con dar la maquina, tambien hay que dar el
protocolo del recurso, para que asi el cliente sepa que protocolo utilizar para
hablar con el servidor. Las URL's (Uniform Resource Locator = Localizador de
Recursos Uniforme) tiene una notacion estandar, que es:

     <protocolo>:<estacion><directorio><recurso>:<puerto>

   El <protocolo> puede ser 'http' (el protocolo del Web) si accedemos a una
hoja web, 'ftp' si es un fichero para bajarse, 'mailto' para enviar un e-mail,
'news' para acceder a un grupo de noticias, etc.

   La <estacion> es el nombre de la misma, o su numero IP. Las maquinas donde
esta el servidor web suelen llamarse tipicamente "www", de ahi las famosas tres
letras habituales (pero no tiene porque ser asi). Se utiliza en los protocolos
'ftp' y 'http', poniendo "//" por delante del nombre de la estacion.

   El <directorio> se utiliza en 'http' y 'ftp' para indicar donde esta el
fichero o la hoja web dentro de la maquina (a partir siempre de un
subdirectorio definido por el servidor para que no se entre a ficheros no
autorizados).

   El <recurso> es lo que se solicita: el fichero para 'ftp' o la hoja para
'http', la direccion de correo para 'mailto', el grupo para las 'news', etc.

   El <puerto> es opcional. Si el puerto del servidor no es el estandar para el
protocolo, se puede indicar un puerto alternativo para contactar con el
servidor.

   Un ejemplo, quiero acceder a la pagina inicial web de "eb2dsn.ampr.org". La
URL seria:

       http://eb2dsn.ampr.org/

El propio servidor suele tener definido cual es el fichero de la hoja web por
defecto del directorio principal (normalmente 'index.htm'). La '/' final no es
necesaria. Si no la pones, lo intenta sin '/'. Si no funciona, el cliente le
aade la '/' y lo intenta de nuevo.

Si el servidor esta en el puerto 8080:

       http://eb2dsn.ampr.org/:8080

Si la hoja web que quiero esta en el fichero 'noticias.htm':

       http://eb2dsn.ampr.org/noticias.htm

    Ahora quiero bajarme el fichero "hola.exe" en el directorio /public de
"ftp.eb2dsn.ampr.org".

       ftp://ftp.eb2dsn.ampr.org/public/hola.exe

   LAS PAGINAS WEB

   Para poner nuestra informacion no necesitamos mas que realizar nuestras
propias paginas web. Cada pagina web no es mas que un fichero de texto escrito
en un lenguaje especial, llamado HTML (HiperText Markup Languaje). No voy a
explicar nada de el, esta fuera del proposito de estos articulos, pero si voy
a poner un ejemplito basico para que os hagais una idea:

      <HTML>
      <HEAD>
      <TITLE> Una pagina web ejemplo </TITLE>
      </HEAD>
      <BODY>

      Esto es un ejemplo de texto.
      <BR>
      Hola mundo !
      <P>
      Esto es un ejemplo de un grafico.
      <BR>
      <IMG SRC="mi_cara.jpg" ALT="Tu navegador no soporta graficos?">
      <P>

      Esto es un ejemplo de enlace (en este caso a otra hoja de mi estacion)
      <BR>
      <A HREF="http://eb2dsn.ampr.org/noticias.htm"> Pulsa aqui para ver las
      noticias de mi servidor. </A>

      <P>
      Esto es un ejemplo para bajarse un fichero:
      <BR>
      <A HREF="ftp://ftp.ea2rcf.ampr.org/yapp/hola.zip"> Bajarse el fichero
      hola.zip de la BBS </A>

      <P>
      Esto es un ejemplo para enviarme sugerencias:
      <BR>
      <A HREF="mailto:eb2dsn@eb2dsn.ampr.org"> Enviame tu mensaje </A>

      </BODY>
      </HTML>

   Como ves, los "<A HREF=...> Objeto del enlace </A>" es un enlace (un
hiperenlace en la terminologia) donde pulsando sobre el objeto entre el <A > y
</A> se va a la URL que hay despues del "HREF=". Como es una URL, pulsar alli
puede significar cargar una nueva hoja Web, bajarse un fichero, o que te
aparezca una ventana donde teclear el titulo y texto del correo a enviar a esa
direccion. Cualquiera de ellos con una sola pulsacion.

   Puedes copiar el ejemplo en un fichero y ver el efecto en Netscape o
Internet Explorer, pero los enlaces no van a funcionar, y el fichero grafico
tampoco va a existir. Puedes cambiar el nombre por el directorio y nombre de
otro que tengas en tu disco duro si quieres ver como queda. Por supuesto esto
es un ejemplo muy sencillo: el HTML es muy extenso. Sin embargo hay programas
con los cuales no necesitas conocer nada para generar paginas Web (por ejemplo
con Word 97 salva tu documento en formato HTML en vez del tipico .doc).

   ========
     HTTP
   ========

   Aunque la forma de manejo sea tan diferente y espectacular, tecnicamente el
web no se diferencia mucho de otras aplicaciones de Internet. Para empezar,
tambien sigue el modelo cliente/servidor, lo cual significa que hay un cliente,
un servidor y un lenguaje especial que usan ambos para comunicarse: el
protocolo HTTP (HyperText Transfer Protocol = Protocolo de Transferencia de
Hipertexto).

   Al contrario de lo que pudieramos suponer, el HTTP es un protocolo bastante
sencillo. Por un lado el cliente hace peticiones de las paginas web que quiere
(dando el directorio y el nombre del fichero donde esta la hoja web) y por otro
lado el servidor web le pasa las paginas HTML y los ficheros graficos que el
cliente le ha pedido.

   El servidor esta a la escucha en el puerto 80 TCP, a la espera de peticiones
de paginas web que envia al cliente que lo solicita. Es lo unico que debe hacer
ademas de controlar que los ficheros solicitados existan y tengan permiso para
ser accedidos.

   El cliente sin embargo es mas complejo de lo habitual. De cara al protocolo,
solo solicita las hojas y graficos y las recibe, pero de cara al usuario debe
representar toda la informacion con el formato que los comandos HTML de la hoja
web indiquen. Por otro lado un cliente web debe ser capaz de llamar a otros
clientes, o ser el mismo cliente de otros protocolos debido a lo que ya hemos
comentado de las URL's.

   En definitiva, los clientes, llamados habitualmente 'navegadores', son
programas complejos. El usuario elige y ve las paginas web a traves de ellos,
indicando la URL bien directamente (en el lugar dedicado a ello) o bien
pulsando el raton sobre uno de los hiperenlaces de la pagina actual (de donde
se obtiene automaticamente la URL de la nueva pagina).

   Actualmente los 2 navegadores dominadores del mercado son el Netscape
Navigator y el Internet Explorer, pero no son los unicos. Los hay graficos y de
texto (sin graficos), comerciales, de shareware e incluso de libre
distribucion.

   INFORMACION ESTATICA

   El WWW forma parte de un conjunto de herramientas llamadas "servidores de
informacion". Estos han surgido a partir del problema de localizar el cada vez
mayor volumen de informacion en Internet. El WWW era una de las soluciones
planteadas, en cuanto a ofrecer informacion e integrar el resto de la existente
en una unica aplicacion.

   Hasta ahora las aplicaciones que hemos visto en Internet (mensajeria,
transferencia de ficheros, conversaciones en tiempo real) los podemos emular en
packet aunque sea de una forma limitada. Sin embargo, el concepto que yo
llamaria de "informacion estatica" que el web aporta a Internet no lo hay en
radiopaquete. Me explico.

   En unas paginas web el autor pone un tipo de informacion, generalmente texto
con graficos. Imaginemos por ejemplo que yo preparo unas paginas web con estos
mensajes que estoy enviando. A partir de ese momento cualquiera puede leerlos
con tal de saber su direccion (URL). Si dentro de un ao alguien pregunta sobre
TCP/IP, solo tengo que mandarle un mensaje con la direccion por si le interesa.
No tengo porque preocuparme de mandar los mensajes cada vez que alguien este
interesado en ello.

   Por otro lado no hace falta que yo envie la direccion para que los
interesados lean estas paginas. Por un lado, otras paginas de otros compaeros
pueden tener enlaces a mi pagina, y si se llega a ella, el interesado puede que
siga explorando y llegue a la mia. Asi los interesados pueden encontrar
informacion sobre su tema "navegando" a traves de los hiperenlaces.  Y ademas
hay sitios web especiales, llamados "buscadores", donde introduciendo un tema,
devuelve todas las direcciones web que el buscador tiene almacenado que tratan
de ese tema.

   Asi, el que ha conseguido configurar un programa o modificar un equipo,
escribe una o varias paginas en HTML sobre el tema. De esta forma:

   1) el mensaje puede ser consultado por los interesados (y solo por los
interesados) a lo largo del tiempo (y puede ser modificado y actualizado con el
tiempo) sin necesidad de tener que estar venga a enviar mensajes.

   2) el mensaje no se pierde para siempre, una vez los mensajes expiran. Y la
proxima vez que se pregunte, esta disponible y no hay que volverlo a escribir.
Teniendo en cuenta que mucha de la mensajeria actual son preguntas que se
repiten constantemente, es una forma de ahorrarselas y a la vez satisfacer a
los remitentes.

   Todo esto no tiene porque ser solo para informacion "fija". Pueden
mantenerse unas paginas por ejemplo con las noticias sobre DX, que se actualiza
cada semana. Asi, el interesado, que ya conoce la direccion, se conecta cuando
le interese para leer las novedades.

   En el proximo mensaje remataremos con un resumen final esta serie de
mensajes.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------

Ventajas del TCPIP en la red FIN

   Hola a todos:

   Durante 12 mensajes hemos navegado por las procelosas aguas del TCP/IP.
Ahora llega la hora de despedirse. Pero antes, me gustaria hacer un pequeo
resumen seguido de una serie de reflexiones sobre la direccion que debe
tomar el campo del TCP/IP en la radioaficion.

   En esta serie he tratado de, por un lado, que nos familiaricemos con el
funcionamiento, la terminologia y la forma de uso del TCP/IP y sus aplicaciones
mas tipicas. Por otro lado, he tratado de mostrar las ventajas de una red
TCP/IP sobre el estado tecnico actual de la red de packet, no con la intencion
de criticarla, sino de ensalzar a la de TCP/IP.

   Estas ventajas no son solo la transparencia y conectividad total de IP, ni
la fiabilidad de TCP, o rapidez de UDP. Las ventajas son tambien los protocolos
de aplicacion estandar: SMTP para el correo, FTP para la transferencia de
ficheros, TELNET para el acceso remoto, NNTP para el correo general y WWW para
"publicacion" de informacion, ademas de las de otros protocolos que ni siquiera
he mencionado.

   Pero una ventaja mas sutil e importante, que apenas he sealado a lo largo
de la serie es que la familia de protoclos TCP/IP no lo desarrollan
radioaficionados, sino expertos en informatica y telecomunicaciones de todo el
mundo, apoyados por las grandes empresas del sector. Esto por una parte nos
permite un desarrollo estandar con el resto del mundo, y unos protocolos "de
calidad" ya que han sido desarrollados por la vanguardia de este campo
tecnologico.

   Esto tambien nos evita de estar constantemente "reinventando la rueda".
Hasta ahora hemos empleado protocolos (como el AX.25, DAMA o el de correo de
FBB), sistemas como BBS's, etc. que muchos creen de nuestra invencion, pero que
no son mas que copias de otros sistemas anteriores, y muchas veces retrasados
respecto a los originales.

   Es necesario aprovechar la tecnologia, el software y las investigaciones y
todo el esfuerzo del resto del mundo: universidades, centros de investigacion,
empresas. En particular, podemos utilizar el software que las grandes empresas
venden o incluyen en sus productos. En otros casos, otras organizaciones no
lucrativas, o simplemente particulares ofrecen software de libre distribucion.
El adoptar estos estandares nos liberan de la tarea de hacer software de
nuestra invencion (normalmente como hemos dicho "reinventando la rueda") o en
todo caso que los estandares se adopten porque ese programa tan distribuido lo
hace asi, en vez de hacerse mediante reflexion, estudio y consenso.

   Ademas, eso significa por un lado que utilizamos sistemas que han sido
probados y se sabe que funcionan. Esta en los mas aventurados probar nuevos
protocolos experimentales, pero el usuario medio no desea esto. Lo que quiere
es el uso que la red le puede dar. Y en estos protocolos nos encontramos con
sistemas y programas ya probados y que funcionan, gente que conoce su uso y nos
puede echar una mano (aunque no sean radioaficionados), libros, tutoriales,
cursillos y ayudas disponibles para todo el publico. Ayudas que no serian
posibles/rentables si solo fueran para los "cuatros locos del radiopaquete",
pero que si lo son para la "gallina de los huevos de oro" que es ahora
Internet.

   CONCLUSIONES

   Muchos se diran a si mismos: "Es necesario todo este lio del TCP/IP? Al fin
y al cabo, mis mensajes llegan." "El que quiera cosas raras, que se vaya a
Internet."

   Esta gente no esta teniendo conciencia de lo que se nos avecina. Y lo que
se nos avecina, no es nada mas y nada menos que Internet, pero no la que ahora
conocemos.

   Hasta ahora Internet era el nido de universitarios que se divertian,
informaticos locos y cuatro sesudos que se dedicaban a cosas raras. Pero ahora
no es eso. Ahora es la mayor oportunidad de publicidad, de negocio y de reducir
costes para las empresas. Y eso significa que si antes era costosisimo acceder
a Internet (igual tenias que llamar fuera de Espaa con un modem de 2.400),
ahora la conexion es muchisimo mas barata y rapida, pero no es nada en
comparacion con lo barata y rapida que va a ser. Y todo es porque las empresas
no les interesan que la gente no quiera navegar por sus webs publicitarios
(donde intentan convencer al usuario de la bondad de sus productos) porque el
usuario este preocupado por la factura del telefono. O que no quiera utilizar
sus servicios, leer sus informaciones, jugar a sus juegos, etc.

   Asi que por un lado esta la competencia del sector, que no llegara hasta que
la prometida liberalizacion de las telecomunicaciones entre en vigor (alla por
el 2000 para Espaa aunque sea teoricamente en el 1998) y los segundos
operadores y empresas del cable entren en el mercado. Por otro lado, los
beneficios no se van a sacar de la transmision de los datos, sino de los
servicios que las empresas proporcionen (lo que ocurre con la TV de pago).
Esto va a significar una tarifa plana de acceso (por ejemplo unas 5.000 ptas
mensuales de la TV por cable incluyendo la conexion a Internet de 2 Megabits
por segundo).

   Con toda esta explicacion quiero decir que de pronto nos vamos a encontrar
con una Internet en casa, con todas las ventajas que ello conlleva y con una
capacidad de servicios que no conocemos. La red de packet, sino en ese mismo
momento, si a la larga desaparecera si permanece como esta ahora. Para que vas
a enviar un mensajito AX.25 que vete a saber si llega y cuando llega, cuando
vas a poder hablar por videoconferencia con el receptor, y ademas ya lo tienes
pagado? A quien se va a convencer de que se compre una TNC, de que es necesario
renovar el ordenador de FBB, o de que hay que pagar para mantener los nodos?
Como se va a captar nueva gente para el packet? Les parecera un sistema
primitivo y barbaro: solo texto!

   Con esta competencia que se nos avecina a pasos agigantados, hay que decir
que estas "locuras" del TCP/IP son necesarias, mas bien obligatorias. La red
necesita una profunda renovacion y la necesita ya, no se puede perder un
minuto mas, despues de estar 15 aos perdiendo el tiempo.

   Esta renovacion tecnologica necesaria se tiene que dar en dos frentes:

   - hardware: ahora mismo, cualquier persona con un modem telefonico alcanza
los 33.600 bits por segundo. Hay que tener en cuenta que un canal telefonico
tiene un ancho de banda de 3 KHz. Como es posible entonces que estemos en
VHF a 1200 o 2400 bits por segundo cuando un canal de la emisora tiene un
ancho de banda de unos 6 KHz (el doble!). Si utilizamos las tecnicas que ahora
se estan usando (QPSK), teniendo en cuenta que el enlace entre la BBS y el
usuario es bastante bueno, deberiamos aproximarnos a los 56000 bits por segundo
en VHF. Hay tecnicos cualificados entre nosotros capaz de investigar y trabajar
sobre ello? Hay electronicos competentes para disear y construir los nuevos
modems?

   - software: Hace falta montar la red en todos sus niveles. Para ello, "por
suerte", tenemos el TCP/IP y sus estandares. Por eso necesitamos gente que
aprenda como funciona todo esto. Necesitamos entusiastas que apoyen
experimentando, mostrandolo a los usuarios, e instalando y enseando el
funcionamiento de las nuevas aplicaciones. Otros, particulares y radioclubs.
deberian ofrecer sus maquinas para albergar los servidores y servicios. Tambien
es mas que probable que haya que sustituir el anacronico AX.25 por un protocolo
mas nuevo y adaptado a las nuevas necesidades.

   Y finalmente, nos queda el frente "legal", donde las asociaciones tienen que
jugar un papel decisivo. A todo esto hay que decir que si nuestra tarea es
dificil, con todo lo que se ha dicho, aumenta dicha dificultad con la nueva y
encorsetada legislacion digital. Es necesaria la desaparicion de todos los
impedimentos que dicha Orden Ministerial puedan producir en todo este
desarrollo de una forma prioritaria y rapida. No podemos estar enredados en
estas zarandajas legales, en vez de a lo que realmente debemos dedicarnos.

   Esta titanica tarea es, en resumen, obra de todos, y sin la colaboracion
de todos no se llevara a cabo. Esto sera por supuesto, para los que quieran
tener una red en bandas de aficionados. El resto no tiene que mover un solo
dedo: solo deben esperar y dar tiempo al tiempo a que todo se cumpla.

   CUESTIONES

   A lo largo de la serie he recibido algunas preguntas. Es hora de que las
conteste en la medida de mis posibilidades. Pero antes, dejare un tiempo para
que podais mandarme mas preguntas, o las mismas mas detalladas. Y luego las
contestare todas en un boletin. Tambien acepto criticas (ya que supongo que
lo que he dicho en este mensaje no gustara a muchos) y sugerencias.

   Ahora la pelota esta en vuestro tejado. Asi que espero vuestros mensajes.
En todo caso me despido de vosotros dando las gracias por vuestra paciencia
y tiempo que me habeis dedicado, y os envio mis mejores deseos hasta el
proximo cruce de antenas.

                       73's cordiales de Javier EB2DSN@EA2RCF.EAVI.ESP.EU

---------
