No me voy a introducir en la parte mas técnica del stack IRDA. Me decanto directamente por la parte mas practica.
Si que es verdad, sin embargo, que para una mejor comprensión es necesaria una breve introducción. Empecemos pues a medio traducir de varios documentos. En el año 93, 50 empresas se juntaron en lo que se llamó la Infrared Data Associaton (IRDA) para definir los estándares para la transmisión de datos usando infrarrojos de corto alcance. A partir de ahí, cientos de empresas se unieron a la susodicha asociación. Desde entonces una mejora tras otra, pasando de la versión 1.0 a la 1.1 etc etc.
Como todos los modelos, el del IRDA también se basa en capas. De esta
forma se reparte de la siguiente manera:
Tiny TP - IAS
IrLMP
Frame/Driver
Physical Layer
La Physical Layer o nivel físico aporta todas las características físicas. Las transmisiones se realizan en difusión con un cono de 30 grados desde el punto intermedio, eso es según las especificaciones, porque yo he probado desde unos 65 grados y sigue funcionando.
El tipo de conexión requiere un nivel intermedio en la transmisión de la luz. Es como todo, mucha luz cegaría el receptor, mientras que poca no es suficiente para consolidar la transmisión. Es curioso, porque aquí no hay un modelo concreto, o eso creo. Se pueden apreciar en el mercado dispositivos que alcanzan los 5 metros, mientras que otros no alcanzan ni uno, véase móviles y algunas pda's. Una buena manera de medir esto, si posees una palm, es con el IRMonitor ( http://www.palmgear.com). Es capaz de mostrar al instante en un S-Meter (signal meter, medidor de señal) la potencia de la señal IR recibida.
La conexión IR es semidúplex, mas que nada porque no tiene sentido recibir mientras se esta transmitiendo. La razón es sencilla, si sueltas el haz de luz el receptor queda cegado por este y no es capaz de ver el que le llega al mismo tiempo que tu transmites.
Encontramos además tres tipos, por decirlo así, de
transmisión:
Existe un cuarto tipo, el VFIR, que pretende alcanzar velocidades de
hasta 16Mbps. Ni idea de cómo andará este proyecto.
En principio tiene dos funciones, lo que ocurre es que tienen tantas cosas en común, o eso dicen XD, que se engloba en una sola. Así que en ocasiones solo se hace referencia a este nivel como Frame.
La parte Driver inicializa lo que es el hardware, las velocidades de transmisión, e intercambia datos desde el controlador hasta el transceptor.
La parte Frame digamos que convierte el formato de datos a un formato que el hardware entienda. Esto podría incluir la comprobación de CRC, bits de inicio/parada y de transparencia.
Hasta aquí todo trabaja a un nivel relativamente bajo. Empezamos pues a subir un nivel mas. El IrLAP se encarga de preservar la comunicación entre puertos IR. Así que es aquí donde se detectan los errores de transmisión y por tanto se encarga también de la retransmisión de los paquetes perdidos. Tiene algo de control de flujo, pero es demasiado poco evidente. Así que lo dejaremos para un nivel mas.
Está basado en HDLC, que en la familia OSI es un protocolo de enlace de datos
de alto nivel. Para mas info, buscarlo en algún buscador, que seguro que
aparece.
El caso es que nuestro IrLAP está basado en HDLC, pero se mejora el aspecto de
los reenlaces (reconexiones mas o menos), ya que en IR es muy fácil perder
conexión y volver a enlazar.
El IrLAP supone, por tanto, una buena base
para construir diferentes protocolos sobre él.
Nuestro querido linux ya nos avisa de su existencia:
irda0 Link encap:IrLAP HWaddr 21:18:d8:ab
UP RUNNING NOARP MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:8
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
El IrDA Link Management Protocol (IrLMP) nos permite tener uno o mas
servicios corriendo en una única conexión sobre IrLAP.
Con la ayuda de IAS las aplicaciones pueden acceder directamente a este nivel
para enviar sus datos.
Un ejemplo de cual dispositivo podría utilizar una conexión en este nivel es, por
ejemplo, una impresora conectada por puerto IR.
Justo he nombrado este nivel en el punto anterior. Y es porque el IAS requiere de IrLMP para todo. En este nivel es donde se buscan y encuentran los diferentes dispositivos IR. Por supuesto, me muestro escueto porque no creo que sirva de algo detenerme mas.
Aquí tenemos lo que seria el protocolillo a nivel de transporte y por lo tanto aquí tendríamos todo lo que englobaría el control de flujo. Es aquí pues, donde se segmentan ¿fragmentan? y reensamblan los paquetes.
Luego tenemos lo que en no se que texto de referencia llaman "Others Layers". Un punto interesante este. Es precisamente done vamos a centrar, como veréis después, todas nuestras prácticas.
Se trata de protocolos del nivel mas alto. En este punto encontramos:
Es un protocolo diseñado para que un objeto pueda ser movido de un dispositivo a otro como tal. Me explico, no se requiere un tipo de comunicación estable como podría ser, por ejemplo, la conexión de una Palm y un PC para sincronizarse. Esta mas en la linea de un "cut and paste". ¿Quien no ha visto nunca dos móviles pasándose vcards (tarjeta de visita, que es lo que pone en la pantallita) del uno al otro?
Nos detendremos mas adelante para algún caso practico con IrOBEX (Apéndice C).
IrCOMM fué diseñado para dar soporte a aquellas aplicaciones que ya funcionaban sobre el puerto COM. Por ejemplo, es posible emular la conexión con una Palm con el crandle como si este estuviera en el serie, cuando no lo está. IR rlz!. Lo bueno está en que no se requiere ninguna modificación del software para realizar esta operación.
Si, supongo que ya lo estáis oliendo. Efectivamente su uso está destinado a la conexión con dispositivos conectados al IR, como por ejemplo impresoras.