Download doc - Capitulo 20 Visual Basic

Visual Basic - Guía del Estudiante Cap. 20

APLICACIONES CLIENTE SERVIDORCOMUNICACIÓN PUERTO SERIE: EL CONTROL MSCOMM

(Capítulo inacabado. ¿Algún estudiante quiere colaborar a su terminación?)

Hasta ahora hemos visto aplicaciones que pueden utilizarse por sí solas. Pueden acceder a bases de datos que estén en el mismo ordenador que la aplicación o en otro, unido mediante una red de área local. La conexión a las bases de datos a las que accede se realiza, bien indicándole la dirección y carpeta (\\MiServidor\BasesdeDatos\MiBase.Mdb) o bien “mapeando” esa dirección (crear una unidad de disco que contienen esa dirección). De esta forma podemos acceder a una base de datos instalada en un equipo remoto y la aplicación debe funcionar perfectamente, aunque al abrir o leer la base de datos origine un tráfico elevado por la red de área local.

Con esta configuración podemos tener problemas de lentitud, sobre todo si la red es lenta y si hay muchos usuarios trabajando con esa aplicación en distintos ordenadores, accediendo todos ellos a través de la red a un servidor que contienen la base de datos. Esta lentitud se incrementaría en una gran escala si la red a utilizar fuese Internet mediante una conexión lenta.

Pero lo que más se notaría sería la ocupación de los recursos de la red durante las consultas a esa base de datos. Dependiendo de cómo se crease el recordset, podría darse el caso de transmitir por la red todos los datos de la base de datos para que nuestra aplicación utilice únicamente los datos correspondientes a un registro. Pensando en una aplicación bancaria, por ejemplo la petición de saldo de una cuenta desde un cajero automático, los únicos datos relevantes de esa operación serán el número de cuenta corriente, un código para indicar que lo que se desea es el saldo, y como datos de retorno, el número de esa cuenta, el saldo actual disponible y quizás un número de comprobación (Checksum) para comprobar que no ha existido error en la comunicación. De nada nos serviría en el cajero conocer el estado de cantidades retenidas, operaciones pendientes, etc.

Si en ese ejemplo del cajero creásemos un objeto Database, un recordset, leyésemos todos los datos del recordset y luego diésemos la orden de cerrarlo, estaríamos enviando información innecesaria a través de la red, con el coste de tiempo y ocupación que ello representa.

Casi llegamos a demostrar con esta introducción que sería más conveniente hacer una aplicación que tuviese dos partes: una, residente en el puesto de operación, (que llamaremos aplicación cliente) que fuese capaz de enviar datos solicitando información a otra aplicación, instalada en el servidor donde está la base de datos. Esta segunda aplicación, que llamaremos aplicación servidor, abrirá la base, creará los recordsets necesarios, filtrará la información, realizará con ella operaciones matemáticas, y una vez concluido todo el proceso, enviará a la aplicación cliente los datos estrictamente necesarios. Obviamente se necesita que ambas aplicaciones sean capaces de entenderse entre sí, es decir, que tengan un protocolo de comunicación entre ellas previamente definido. Esto es lo que se denomina una aplicación cliente – servidor.

La aplicación cliente – servidor más popular es el navegador de Internet. Esta aplicación está formada por una aplicación cliente (Navegador IEXplore, NetScape, etc) y una aplicación servidor (Internet Information Server IIS, Apache, etc). El protocolo para que se comuniquen entre ellas es el protocolo Http o el Ftp. Estos protocolos al ser públicos, permiten a cualquier empresa hacer su propia aplicación cliente o servidor.

No es nuestro deseo llegar a tanto. El navegador de Internet es una aplicación cliente–servidor que sobrepasa cualquier proyecto que podamos imaginar para realizarlo por medio de programación en VB. Cualquier navegador de Internet comercial lleva asociadas una serie de funciones, muchas de ellas transparentes para el usuario, que sería imposible crear una aplicación de este calibre, sobre todo como ejemplo de un curso de VB. Pensemos en una

LSB Visual Basic Guía del Estudiante Cap. 20 Pág. 1

aplicación más sencilla, que nos permita conocer como funcionan las aplicaciones cliente – servidor, y sirva además para algo útil.

Esa aplicación no puede ser otra que una guía telefónica, (versión novísima del Listatel) cuya base de datos está en un servidor conectado a Internet, al que se podrá acceder desde un número ilimitado de puestos cliente. En la base de datos del servidor, en un conjunto de tablas, figurarán los nombres, números de teléfono, despacho, etc. de una serie de personas, y el organigrama de esas personas dentro de la organización. Estas tablas serán estáticas, es decir, tendrán datos que solamente se actualizarán cuando exista un cambio en esas personas, pero no variarán durante la ejecución del programa. En otra tabla, esta dinámica, tendremos el registro de los usuarios que están conectados en ese momento al servicio. Así podremos saber si un usuario está presente y de esta forma conocer un dato importante para otro servicio que va a tener este programa: su dirección IP actual. Sabiendo que está conectado y con su dirección IP podremos enviarle mensajes directamente. Creo que ya vemos que se trata de una agenda telefónica que lleva incorporado un servicio de mensajería. El servicio de mensajería enviará mensajes con texto plano o RTF y puede llevar ficheros anexados. A esta agenda, y a su protocolo de comunicación le vamos a denominar SML. No se preocupe de no conocer las siglas. Al protocolo SMTP tampoco lo conocían en el momento de su creación.

Una aplicación cliente puede comportarse como aplicación servidor de otra aplicación, incluso de sí misma. Este es el caso de la aplicación cliente del SML. Cuando vamos a pedir la información de un abonado telefónico al servidor, el cliente se comporta como tal. Sin embargo cuando otro usuario de SML nos envía un mensaje, es nuestra aplicación la que realiza las funciones de servidor. Verá esto con mucha más claridad cuando comencemos el ejemplo.

Toda aplicación cliente - servidor debe tener un sistema de comunicación entre la aplicación cliente y la aplicación servidor. Parece que la comunicación que ha de tener es a través de una red IP (Red de Area Local, Red Privada Virtual, Internet) pero puede ser cualquier otro sistema de comunicación entre ordenadores. Sin ir más lejos, a través del puerto de comunicación serie COM-1 ó COM-2. A efectos de los programas de la aplicación cliente o servidor solamente variará en la forma en la que reciban y transmitan los datos. En nuestro ejemplo vamos a utilizar la comunicación a través de una red IP, usando el control Winsock ya estudiado. Tanto la aplicación cliente como la aplicación servidor deberán tener un Winsock. Como en nuestro caso, según explicamos más atrás, la aplicación cliente se convierte en aplicación servidor para recibir mensajes, ésta deberá tener dos Winsocks, uno para la función cliente, y otro para la función servidor.

Cuando se diseña una aplicación cliente – servidor hay que comenzar pensando en las funciones que va a realizar y sobre esas funciones comenzar a escribir el protocolo de comunicación. No es fácil tener terminado el protocolo de comunicación antes de escribir la primera línea de código del programa. Según se van concretando cada una de las acciones que debe realizar vemos que es necesario introducir nuevos códigos de operación en nuestro protocolo. No se preocupe que eso no es improvisar. Pero sí es muy importante tener las cosas claras desde el principio y saber que es lo que va a hacer nuestra aplicación para de esta forma poder saber dar respuesta correcta a cada uno de los dos programas. Y para tener las cosas claras, el autor recomienda que el protocolo de comunicación se establezca antes de comenzar a escribir el código en tanto se pueda. Y que se escriba en un documento en el propio ordenador o mejor aún, en una base de datos u hoja de cálculo, que nos permita ordenar las órdenes y avisos de nuestra aplicación para evitar de esta forma cualquier repetición involuntaria.

Es muy importante a la hora de pensar el protocolo de comunicación que este no pueda inducir a error al programa. Si el programa tiene como función la transmisión de mensajes (Tal como es nuestro caso) los mensajes no pueden estar limitados ni en su longitud ni en su contenido por el formato del protocolo de comunicaciones. Se entiende mejor esto analizando el protocolo del SML (fruto únicamente de la imaginación del autor y no sujeto a normas ni recomendaciones internacionales de ningún tipo)


Protocolo de comunicación de la aplicación SML.

(Vea el ANEXO 1 Protocolo de comunicación SML)

La comunicación entre ambas aplicaciones se establece mediante palabras en ASCI que indican una operación. A estas palabras las denominamos Acrónimos. Las operaciones pueden ser órdenes o avisos. Son órdenes aquellas comunicaciones del cliente que desencadenan una operación en el servidor. Son avisos aquellas respuestas del servidor para enviarle datos o comunicar algo al cliente. Cada orden o aviso, puede llevar uno o varios parámetros. Los parámetros contienen la información necesaria para que la operación que se va a realizar por esa orden o aviso pueda llevarse a cabo. En esta aplicación SML los acrónimos todos son de 3 caracteres, utilizando los signos < > como delimitadores del acrónimo. Si el acrónimo lleva parámetros, la separación entre los tres caracteres y el parámetro o parámetros es la barra /

Volvamos a lo comentado anteriormente respecto a la limitación del contenido de un mensaje. Si el mensaje contiene un carácter <, > ó / puede que el programa se confunda y piense que ese carácter forma parte de un acrónimo. Para evitar cualquier confusión, si uno de estos caracteres forma parte de un texto, se le antepondrá el signo &. De esta forma la recepción de la pareja de caracteres &<, &> ó &/ significa que no son parte de un acrónimo sino texto. Observe ahora que ese mismo problema lo vamos a tener con el carácter &. Si queremos enviar ese carácter, sin que haya posibilidad de error pensando que se trata del carácter & antepuesto a cualquiera de los signos anteriores, deberemos poner delante de él también el signo &. Así, && significa que se está transmitiendo el signo &.

Es obvio pensar que esas tres combinaciones no pueden formar parte de ningún acrónimo. Pero como los acrónimos los definimos nosotros, basta con hacer que ninguno contenga esas secuencias de caracteres.

Preocúpese de estos detalles que son los realmente importantes. Verá cuando se ponga a escribir código que siempre ha de faltar algo en el protocolo de comunicación. No se preocupe por tener que ir rectificándolo. Eso sí, mantenga siempre actualizado el documento o base de datos con el protocolo, explicando debidamente cada una de sus partes, los parámetros que lleva y la función que realiza. Es documento indispensable a la hora de distribuir la aplicación.

A modo de recordatorio, los protocolos de comunicación de las aplicaciones cliente – servidor para Internet se encuentran en las RFCs, (Request For Coments) son públicas, y han tardado en desarrollarse varios años a base de continuas aportaciones y correcciones por parte de sus creadores de todo el mundo mundial. Basta con que teclee RFC en un buen buscador y le llevará a muchas páginas donde puede ver todas las recomendaciones para todos los servicios de Internet.

El protocolo de comunicación debe hacerse preferentemente en ASCII puro y caracteres que tengan representación física. Esto nos permite depurar el programa analizando la comunicación mediante un programa externo y debidamente probado. Utilizar caracteres sin representación ASCII lo único que puede hacerle es complicarle la vida a Ud. y a quien analice su aplicación. Cuando se envíe una cifra, hágalo en decimal o en hexadecimal. Evite en lo posible enviar cifras sustituyendo su valor por su carácter equivalente. La mayoría de los caracteres no los va a poder representar y tendrá serios problemas para depurar su programa. Esto es especialmente importante con el cheksum de un mensaje, por ejemplo. Le recomiendo que use preferentemente numeración Hexadecimal.

Un buen programador nunca oculta el protocolo de comunicación. Esto permite que otros mejoren su aplicación. Sólo los programadores mediocres temen que se les plagie. Y por supuesto, nadie debería aceptar una aplicación cliente – servidor si el programador no suministra ese protocolo.


Aspectos que debe tener siempre en cuenta cuando diseñe una aplicación cliente – servidor.

Si como es normal, utiliza una red IP para la transmisión de información entre ambas aplicaciones, deberá poner un Winsock en la aplicación cliente, que deberá conocer la dirección IP o el DNS de la aplicación servidor, y el puerto en el que está escuchando. En el servidor deberá poner un Winsock que estará siempre a la escucha en el puerto determinado para la aplicación, y atenderá a todas las llamadas que reciba creando una instancia de ese Winsock. Creará una instancia para cada comunicación entrante desde los clientes. La comunicación en el servidor se mantendrá abierta hasta que el cliente la cierre. Solamente en circunstancias excepcionales, cerrará la comunicación el servidor. Por ejemplo, en aquellos casos en los que pase un tiempo predeterminado sin recibir ni enviar ningún dato al cliente. Para eso se utilizará una tecnología muy sencilla, denominada Watch Dog consistente en un contador que se pone a cero cada vez que se recibe o se envían datos al cliente. Ese contador incrementa su cuenta en una unidad cada cierto tiempo. Si llega a un número predeterminado, prueba evidente de que ha pasado un tiempo sin que reciba ni envíe información, cierra la conexión del Winsock asociado. De cualquier forma hay que tener cuidado y pensar muy bien lo que se hace antes de cerrar la comunicación desde el servidor.

El programa cliente debe conocer el número IP o dirección DNS del servidor. Pero el servidor no tiene porque conocer la dirección ni DNS del cliente, ya que debe ser el cliente el que inicie siempre la comunicación.

Al cliente nunca se le debe forzar el puerto en el que emite (Propiedad LocalPort del Winsock). El servidor contestará siempre al cliente usando la conexión abierta por éste, es decir, usando la instancia de su Winsock correspondiente a la conexión realizada para ese cliente)

Normalmente el servidor no podrá comunicar directamente con el cliente, ya que el cliente no está a la escucha. Solamente en algunas aplicaciones se le dota al cliente de otro Winsock para que sea este segundo Winsock quien esté a la escucha de una posible llamada del servidor. Esto se emplea para dar una batida por todos los clientes (Hacer Pooling) y ver los clientes que están conectados en este momento. Solamente lo he visto en algunas aplicaciones de seguridad. Generalmente este pooling se sustituye por llamadas periódicas desde cada cliente para indicarle al servidor que están activos.

La comunicación entre cliente y servidor debe ser siempre TCP. El uso de UDP simplifica mucho las comunicaciones, pero no sirve para salir a Internet, donde las tramas UDP son generalmente eliminadas por los servidores. Vale más trabajar un poco más el código y trabajar con comunicaciones seguras aunque sea en una red de área local que garantice la llegada de UDP.

Los paquetes broadcast deben evitarse también. Solamente deben usarse en configuraciones donde no se conocen las direcciones de los servidores. Esto ocurre cuando la red tiene asignación dinámica de direcciones. (Puede ocurrirle si usa una red VSAT) En cualquier caso, los paquetes broadcast deben evitarse en lo posible. Los servidores de Internet los eliminan automáticamente.

Posiblemente haya más recomendaciones relativas a la comunicación. Veamos ahora otras recomendaciones acerca del código y de la funcionalidad.

Dado que la aplicación cliente y la aplicación servidor son completamente independientes, es muy fácil realizar modificaciones en una de ellas, sobre todo en el servidor, sin que el cliente se entere. Basta para ello mantener invariable el protocolo de comunicación.

Pero puede llegar el caso en el que al servidor se le hayan introducido mejoras que puede aportar al cliente si este es capaz de reconocer un nuevo protocolo. Estamos en el caso de un servidor que debe atender a dos versiones distintas de cliente. Si el cliente tiene la versión mejorada, usará con él un protocolo de comunicación que permita las nuevas prestaciones. Si el cliente tiene la versión más antigua, deberá seguir usando con él el protocolo anterior.


Esto nos lleva a que el cliente siempre debe indicar al servidor su versión. Esto no ocupa unos recursos excesivos y puede ser muy útil cuando prevemos introducir una modificación. Esta práctica puede incluso servir para conocer aquellos clientes a los que hay que realizar el cambio de versión y enviarles una nueva. En el ejemplo de este curso, el cliente comunica al servidor su versión en el acto de conectarse mediante el acrónimo <VER>.

El servidor también debería enviar su versión al cliente. No está previsto en la aplicación SML pero confieso que no sobraría que al identificarse el cliente y devolverle el servidor la conformidad del registro, le devolviese también la versión del servidor. ¿Se da cuenta que según se avanza en la definición del protocolo aparecen nuevas necesidades?

La aplicación cliente debe mostrar de forma clara al usuario el estado de conexión o desconexión con el servidor. Y a ser posible, que indique la causa de la no conexión (Fallo en la RAL, fallo en el servidor) Esta información se obtienen de forma muy sencilla analizando los errores generados en el Winsock a la hora de realizar la conexión.

Cuando utilice el puerto COM para la comunicación, bien sea directamente o a través de módem, debe indicar claramente al usuario el estado de esa conexión, analizando la señal DSR (esta señal está activa cuando el módem está conectado, y en caso de comunicación directa, cuando se use, el Host debe poner a 1 esta señal para poder trabajar). Recuerde que la comunicación por el puerto COM es asíncrona respecto a la ejecución del programa.

En el ejemplo de aplicación cliente – servidor se han ensayado también los controles avanzados de Visual Basic (Capitulo 16). La aplicación tal como se dijo es una guía telefónica, que presenta en un TreeView el organigrama del Organismo o empresa a la que pertenece la guía. Esto facilita la búsqueda de una persona, haciéndolo por departamento. La guía permite también buscar por nombre, primer apellido, segundo apellido o combinación de ambos. Una vez encontrada la persona, se cubren todos los datos de la misma, para presentarlos en la solapa de la guía propiamente dicha, y el dato de su alias (dato que define de forma única a cada usuario) aparece en la dirección de correo para poder enviarle un mensaje. Para hacer una práctica con el puerto de comunicaciones COM-1 ó COM-2 utilizaremos un módem, conectado al PC a través de uno de estos puertos, para marcar el número telefónico.

Todas las operaciones de búsqueda de datos las haremos mediante consultas a la base de datos que está en el servidor. Las consultas se realizarán siguiendo el protocolo de comunicaciones. El organigrama se guardará en el cliente, en una base de datos, para evitar en lo posible el envío desde el servidor. La razón para esto es que el organigrama puede ser muy extenso, y no va a variar muy a menudo. Como esta información habría que enviarla nada más conectarse el cliente, y como puede ser bastante amplia, esto podría originar un tráfico intenso por la red, que es justamente lo que queríamos evitar. Solamente se va a enviar cuando haya cambiado. ¿Cómo sabe el cliente que ha cambiado?. ¿Cómo sabe el servidor que el cliente tiene ya la información actualizada? La idea más sencilla para conocerlo es que el cliente envíe cada vez que se registra (al comienzo de la conexión) el nombre de la revisión del organigrama que tienen. El nombre puede ser cualquiera. Lo que hace el servidor por defecto para poner el nombre a la revisión es combinar una cadena de texto con el nombre de la organización seguido de la fecha (día/mes/año) en la que se realiza la revisión. De esta forma es imposible que haya dos fichero con el mismo nombre. Al recibir ese nombre el servidor, si es igual al de la última revisión, le devuelve un OK. Si no es igual, le devuelve una instrucción para que el cliente solicite al servidor que le envíe la nueva revisión. El cliente la solicita y el servidor se la envía. Y al recibirla, el cliente reemplaza el contenido de la base de datos por los nuevos valores recibidos.

Y razonando los procedimientos de esta misma forma, vamos completando el mecanismo de comunicación entre cliente y servidor, y paralelamente creando el protocolo de comunicación. Por eso es muy probable que el protocolo de comunicación no esté acabado hasta que esté acabada la aplicación.

Al día de hoy (30 de Octubre de 2002) no está terminada la aplicación. Posiblemente no lo esté nunca porque sea una aplicación en continua ampliación. Esto es lo bonito de los programas ejemplo de los cursos de visual basic.



ANEXO 1SERVIDOR DE BASES DE DATOS Y MENSAJERIA LISTATEL (SML)

PROTOCOLO DE COMUNICACIÓN CLIENTE – SERVIDOR

La comunicación entre cliente y servidor se realizará mediante el protocolo descrito más adelante, a través de cualquier medio de comunicación. Generalmente será comunicación a través de red IP, pero esto no debe impedir que los clientes se puedan conectar al servidor a través de otros medios de comunicación, como puede ser un módem telefónico o un enlace vía satélite.

En cualquier caso, el contenido de las órdenes y comandos de este protocolo será siempre en ASCII, con caracteres alfanuméricos que permitan ver perfectamente el tráfico entre ambos interlocutores. El hecho de utilizar solamente caracteres legibles asegura igualmente la comunicación a través de cualquier medio de telecomunicación, incluyendo dispositivos de cifrado on-line colocados entre cliente y servidor.

La comunicación puede iniciarse tanto en el servidor como en cualquiera de los clientes. Una comunicación puede estar compuesta de:

OrdenesRespuestasConfirmacionesAvisos

Ordenes: Son aquellas partes de la comunicación que inician una operación en el equipo colateral.

Respuestas. Son siempre respuesta a una orden, y contendrán el resultado de la operación generada por la orden, o en su defecto, la notificación de que esa orden no ha sido ejecutada o que dio resultado nulo.

Confirmaciones: Son el reconocimiento de recepción de una comunicación. Pueden emplearse tanto para responder a un aviso como para confirmar que una orden se ha recibido, y que está siendo tratada. También pueden existir confirmaciones para avisar que una orden o una respuesta no ha llegado en un tiempo determinado.

Avisos: Son aquellas comunicaciones que no ejecutan ninguna acción en el colateral, pero informan de algo. Por ejemplo, servidor fuera de servicio temporalmente, servidor restablecido. Pueden ser individuales, en cuyo caso generarán normalmente una confirmación, o broadcast, en cuyo caso no generarán confirmación.

Formato de las tramas de comunicaciones.

La trama de una comunicación estará compuesta de unos acrónimos que indicarán la orden, respuesta, confirmación o aviso que envían, dirección IP, nombre de la máquina o nombre del servidor que envía, dirección IP, nombre de la máquina o nombre del servidor destino, datos, cheksum de la trama y acrónimo de fin de trama. Cada uno de estos componentes irá metido entra los símbolos < > y su longitud puede ser variable. Cuando se envíe información, esta se colocará detrás del acrónimo que la define, separada por la barra /.

Ejemplos:

<SAT> Servidor Atención. Inicia una sesión de un cliente con el servidor.<IPO/10.3.22.119> Dirección IP del equipo origen<IPD/217.126.179.96> Dirección IP del equipo destino<QRY/Select * From Agenda_Personal Where Apellido1 Like ‘FERN%’>


Si hubiese que emplear los símbolos /, &, < o > como símbolos de la información, deberá anteponerse a cada uno de ellos el símbolo &. Por ejemplo:

<QRY/Select * From Agenda_Personal Where Edad &> 25>

El cheksum será el resultado de realizar la función XOR sobre todos los caracteres de los componentes de la trama, exceptuando los correspondientes precisamente a este cheksum y al fin de trama. El cheksum se indicará en decimal, con el acrónimo CHK. Por ejemplo, <CHK/235>

El acrónimo de fin de trama será <EOT>

El orden de los componentes de una trama no debe ser estricto, si bien debe ir en primer lugar el acrónimo que inicie la sesión de comunicaciones, en penúltimo lugar el cheksum, y en último lugar el <EOT>

Una trama puede contener varias ordenes siempre y cuando estas sean congruentes.

Cuadro con los acrónimos usados en las tramas de comunicación.

<RHC> Remote Host Conectado. Lo devuelve el servidor o un cliente cuando otro equipo se conecta a él.

<SAT> Servidor ATención. Inicia una sesión de comunicación desde el cliente al servidor.

<CAT> Cliente Atención. Inicia una sesión de comunicación desde una máquina (Servidor o cliente) a una máquina cliente.

<LIC> Login Cliente. Indica que el cliente desea hacer Login en ese servidor. Pasa como parámetros el alias y el password (en claro o cifrado) del cliente.

<LOC> LogOut de cliente. Ese cliente quiere hacer LogOut de ese servidor. Pasa como parámetros el alias y el password (en claro o cifrado) del cliente.

<ALC> Alias de cliente. Llevará como dato el alias de ese cliente.<ALS> Alias de servidor. Llevará como dato el alias de ese servidor.<PWC> Password del cliente. Lleva como parámetro el password (en claro o

encriptado) del cliente<IPO> IP de la máquina origen. Llevará como dato el número IP de la máquina origen

de la trama.<IPD> IP de la máquina destino. Llevará como dato el número IP de la máquina

destino.<NMO> Nombre máquina origen. Llevará como dato el nombre de la máquina dentro de

la red. <NMD> Nombre máquina destino. Llevará como dato el nombre de la máquina dentro

de la red.<NSO> Nombre Servidor origen. Llevará como dato el nombre del servidor origen. Este

nombre de servidor será el nombre de un programa servidor, no el nombre de la máquina donde se alberga el programa servidor.

<NSD> Nombre servidor destino. Igual que el anterior.<QRY> Consulta a una base de datos. Llevará como datos la consulta completa en

SQL<QPR> Consulta ya preprogramada en el servidor. Lleva como parámetro el nombre de

esa consulta, y los datos que necesite esa consulta para su ejecución.<RQY> Resultado de la consulta a la base de datos. Llevará como datos el resultado

de esa consulta. Si el resultado genera varios registros, cada uno de ellos irá entre brackets ( [ ] )

<QIP> Consulta de los datos del correo de un usuario. Envía como parámetro el Alias del usuario del que se quieren conocer los datos. Devuelve los datos con el acrónimo <QIP>


<QIR> Consulta los datos del correo de un usuario pasándole en este caso como parámetro la dirección de correo SML. Devuelve los datos con el acrónimo <QIP>

<QIS> Consulta los datos del correo de un usuario pasándole la dirección de correo SMTP. Devuelve los datos con el acrónimo <QIP>

<ECO> Orden de envío del mismo dato en la respuesta a esa orden. Se envía, por ejemplo, en una consulta a la base de datos, para que el cliente ubique la respuesta a esa consulta en un sitio determinado.

<OCE> Se emplea para devolver el mismo dato recibido con <ECO><CRY> Inicia o finaliza una operación de cifrado de datos. Lleva como parámetro INI

para iniciar y FIN para terminar. En el caso de iniciar, lleva uno o dos parámetros más, el número de clave o el nombre de un usuario con clave asociada. Puede llevar dos nombres de usuario en caso que se cifre doblemente con la clave privada del remitente y la clave publica del destino, en cuyo caso se envían como dos parámetros<CRY/INI/PUB_LUIS.RODRIGUEZ/PRI_JOSE.LOPEZ>Si el inicio no llevase parámetros de clave, el servidor entenderá que se cifra con la clave asignada en el servidor al usuario que envía<CRY/FIN>

<DI0> Datos iniciales. Son datos que se envían entre aplicaciones <DI1> para su inicialización. Van del 0 al 9 . Pueden usarse en ambos . . . sentidos. Preferentemente, DI5 como contestación a DI0,<DI9> DI6 como contestación a DI1, etc.

<BRC> Mensaje dirigido a todos los clientes<BRS> Mensaje dirigido a todos los servidores<BRA> Mensaje dirigido a todos los equipos (Clientes y servidores)<VER> Versión del programa cliente. Se envía al registrarse.<VES> Solicita la versión de software del servidor. Devuelve la versión del software del

servidor.<BIP> Busca IP. Se usa para comprobar que un cliente está disponible actualmente

en la red. No lleva parámetros.<DIP> Es la respuesta del cliente a la llamada <BIP> Lleva como parámetro la

dirección SML o el nombre del usuario de ese cliente.<UCC> Usuario Cliente Conectado. Se devuelve cuando un cliente recibe una solicitud

de conexión. Es equivalente al RHC del servidor.<MN_> Información del mensaje. Número de mensaje. Es una cadena de caracteres

generada por el origen, para definir el mensaje enviado. Consiste en una cadena de 4 caracteres programable por el usuario, seguida de un número que indica el año, mes, día, hora, minuto y segundo del envío, todos ellos de dos dígitos. (abcdyymmddhhnnss)

<FR_> Origen del mensaje (From) Lleva como parámetro la dirección SML del origen.<IP_> Dirección IP desde la que se envía el mensaje. Es similar a <IPO> pero

solamente se utiliza al enviar un correo.<TO_> Información del mensaje. Indica dirección de correo a la que se está enviando

el mensaje. Lleva como parámetro la dirección SML o SMTP del destino.<SJ_> Información del mensaje. Indica el Asunto (Subjet) del mensaje. Lleva como

parámetro el contenido del asunto.<NX_> Información del mensaje. Indica el nombre del fichero Anexado enviado en el

mensaje. Puede haber varios anexos dentro de un mismo mensaje, en este caso se enviarán varios grupos <NX_>. Lleva como parámetro el nombre del fichero en el origen y el tamaño (en bytes) del fichero.

<CX_> Cheksum del fichero anexado. Lleva como parámetro 8 bytes con el cheksum en Hexadecimal. (El cheksum son 32 bits –4 bytes- expresados en hexadecimal. Si no envía cheksum, estos 8 bytes se sustituyen por la cadena YYYYZZZZ.

<BX_> Comienza la transmisión del anexo. No lleva parámetros. El primer carácter del anexo debe transmitirse inmediatamente después de este acrónimo.


<EX_> Termina la transmisión del anexo. Este acrónimo debe enviarse inmediatamente después del ultimo carácter del anexo.

<MSG> Cuerpo del mensaje enviado como texto. Lleva como parámetro el texto del mensaje.

<CHM> cheksum del mensaje. Se envía cuando se solicita acuse de recepción o de lectura, para comprobar la exactitud de la transmisión. Se usa también para devolver el cheksum del mensaje al origen en la confirmación de recibo o lectura. Lleva como parámetro los dos bytes del checsum codificados en hexadecimal (4 caracteres).

<RTF> Información del mensaje. Indica que el contenido del mensaje está en formato RTF. Puede no llevar ningún parámetro, en cuyo caso indica que todo el cuerpo del mensaje está en formato RTF, o llevar le parámetro INI para indicar que comienza el formato RTF y FIN para indicar que termina. Afecta solamente al cuerpo del mensaje enviado con <MSG>

<SAR> Solicitado acuse de recibo. Puede llevar como parámetro una dirección de correo SML o SMTP que será en este caso a quien enviará acuse de recibo del mensaje. Si no lleva ningún parámetro enviará el acuse de recibo al origen del mensaje. El acuse de recibo implica solamente que se ha recibido el mensaje correctamente en el destino, pero no indica que se haya leído.

<SAL> Solicitado Aviso de Lectura. Puede llevar como parámetro una dirección SML o SMTP que será en este caso a quien se envíe el aviso de lectura del mensaje. Si no lleva parámetro se le enviará al origen del mensaje. Este aviso de lectura indica solamente que se ha abierto el mensaje, pero no puede asegurar que el usuario destino lo haya leído.

<FM_> Fin del mensaje. Indica que se ha transmitido todo el mensaje con todos los anexos. En caso de una transmisión de mensajes múltiples, lleva como parámetro el número del mensaje que termina. En caso de mensaje único no lleva ningún parámetro o puede llevar el número del mensaje.

Una máquina puede identificarse bien por su dirección IP o por su nombre dentro de una red. Puede también identificarse por ambos, en aquellas situaciones en las que la máquina receptora del mensaje deba retransmitirlo a otra máquina. Este es el caso, por ejemplo, de una red conectada a través de una conexión ADSL. El módem ADSL tiene asignado un número IP verdadero, y en esa red existen varias máquinas que cada una de ellas tendrá un nombre distinto, y un número IP distinto, (número IP que para estas máquinas será ya de la numeración interna) Al poder identificar una máquina por su IP y nombre, basta con poner como IP de destino el numero IP real del módem ADSL, y como nombre, el nombre de la máquina dentro de la red privada.

Por ejemplo:

<CAT> <IPO/100.100.100.100><IPD/217.126.179.96><NMD/Administracion_1><OCE/123><RQY/[Antonio Fernandez_91 1234567][Antonio Fernangomez_91 7654321]>

Este mensaje devuelve el resultado de una consulta a la máquina Administracion_1 que está en la red de área local cuyo acceso desde Internet se realiza por un módem ADSL cuyo número IP es el 217.126.179.96. Lógicamente, la máquina real que recibe esta comunicación no es la máquina Administracion_1, sino otra máquina colocada en la misma red de área local, sobre la cual se ha hecho NAT desde Internet para el puerto que use este sistema, y esta máquina, una vez recibido el mensaje, lo reenvía a la máquina Administracion_1 que será quien lo trate. Si la comunicación no llevase más que el número IP, se entiende que el destino es la máquina que tiene ese número IP.

ORDENES PREPROGRAMADAS

Las órdenes preprogramadas son aquellas que el servidor ya tienen programadas en su código. Deben ir necesariamente tras el acrónimo <QPR> ya que en caso contrario no serán tratadas.


<ORG> Pide / devuelve el organigrama. No lleva más parámetros<ABN> Pide devuelve el nombre t Teléfono 1 de los abonados de un departamento. Se

le pasa como parámetro el ID de ese departamento (Campo Ag_Departamento_ID)

<ABD> Pide / devuelve todos los datos de un abonado. Lleva como parámetro el ID de ese abonado.

<ABL> Pide / devuelve todos los datos de los abonados de un departamento. Se le pasa como parámetro el ID del departamento.

<ABC> Pide todos los datos de los abonados de un despacho. Se le pasa como parámetro el número de despacho. Los datos se devuelven con el acrónimo <ABL>

<ABB> Pide todos los datos de los abonados que tienen un determinado nombre (Búsqueda aproximada por ambos lados) Se pasa como parámetro el nombre por el que se quiere buscar, o las letras del nombre por el que se va a realizar búsqueda aproximada. Devuelve los datos con el acrónimo <ABL>

<ABA> Pide todos datos de los abonados con un determinado primer apellido (Búsqueda aproximada por la derecha) Se pasa como parámetro el apellido a buscar, o la cadena de caracteres por la que hará la búsqueda. Devuelve los datos con el acrónimo <ABL>

<ABE> Pide todos los datos de los abonados con un determinado segundo apellido. (Búsqueda aproximada por la derecha) Se pasa como parámetro el apellido a buscar, o la cadena de caracteres por la que hará la búsqueda. Devuelve los datos con el acrónimo <ABL>

<ABF> Pide todos los datos de los abonados con el mismo primer apellido (Búsqueda aproximada por la derecha) y segundo apellido (Búsqueda aproximada por la derecha). Se pasan como parámetros los apellidos a buscar, o las cadenas de caracteres por las que hará la búsqueda. Devuelve los datos con el acrónimo <ABL>

<ABG> Pide todos los datos de los abonados con el mismo nombre (Búsqueda aproximada por los dos lados) y el mismo primer apellido (Búsqueda aproximada por la derecha) Se pasa como parámetro el nombre y apellido a buscar, o las cadenas de caracteres por la que hará la búsqueda. Devuelve los datos con el acrónimo <ABL>

<ABH> Igual que el anterior, con nombre y segundo apellido.



EL CONTROL PERSONALIZADO MICROSOFT COMM

Este control permite la comunicación de una aplicación VB con el puerto serie. Parece en principio que los puertos serie del PC se usan para muy pocas cosas. Prácticamente para conectarnos a Internet a través de un módem telefónico. Existen muchísimas aplicaciones industriales para las cuales son fundamentales los puertos COM. Las redes de área local parece que han dejado obsoletos a los puertos COM1 y COM2. No es así. Deje volar su imaginación. Vuelva a la página 4 del capítulo 2, y observe el panel de control de una radio realizado en Visual Basic. La unión entre el PC y la radio, separados muchos kilómetros, se realizó mediante el puerto COM, conectado a una línea telefónica mediante un módem. El puerto COM es el gran olvido de los informáticos…

El control MSComm no está normalmente en la caja de herramientas, por lo que será necesario introducirlo mediante Proyecto | Componentes.

En el formulario solamente se le ve en tiempo de diseño. El icono que lo representa en la caja de herramientas coincide con el que presenta en el formulario:

Al tratarse de un control personalizado, presenta dos formas de ver las propiedades. Si hacemos click con el botón derecho del ratón sobre el control y vamos a propiedades, nos presenta tres cuadros de configuración de los típicos de los controles personalizados. Si seleccionamos el control MSComm y pulsamos F4 , aparecerá la caja de propiedades típica de los controles VB.

PRPIEDADES

Existen propiedades que pueden establecerse en tiempo de diseño o en tiempo de ejecución, y otras que solamente se pueden ejecutar o consultar en solamente en tiempo de ejecución. Se detallan a continuación las primeras. Las segundas se enumerarán tras estas, aunque se nombran algunas de estas últimas al explicar cada una de las propiedades del primer tipo.

CommPort Indica el número del puerto serie usado. Admite los valores de 1 a 255. Cambiando esa propiedad podemos cambiar el puerto de comunicación que vamos a usar (Un PC tiene normalmente 2 puertos serie : El Com1 y el Com2. Puede tener sin grandes problemas Hardware hasta 4 (Com3 y Com4) Si le damos a ese valor un número de puerto inexistente, dará error.

Settings

Sintaxis Velocidad, Paridad, Bits de información, Bits parada

Indica la velocidad, paridad, número de bits y bits de stop (parada) que se van a usar en la comunicación.

Los valores posibles para velocidad son : Indica la velocidad en baudios.

50 100 110 300 600 1200 2400 4800 9600 14400 19200 y 28800

Los valores posibles para paridad son :


N - No envía bit de paridad ni hace comprobación de paridad en la recepción.O - Envía y comprueba paridad, con el criterio de paridad IMPARE - Envía y comprueba paridad, con criterio de paridad PAR

Los valores para el parámetro Bits de Información pueden ser :

7 - Se envían / reciben 7 bits por trama de información.8 - Se envían / reciben 8 bits por trama de información5 - Se envían / reciben 5 bits por trama de información. Este valor de 5 bits es el típico

del sistema Baudot para transmisión telegráfica (Teletipos) que se ha conservado en las comunicaciones informáticas por pura tradición. Si se eligen 5 bits, los bits de parada se ponen automáticamente a 1,5 (Típico también del sistema Baudot.)

Los valores para el parámetro Bits de parada pueden ser :

1 - Se envía un bit de parada2 - Se envían 2 bits de parada

(No es posible programar 1,5 bits de parada. Sólo lo hace cuando se programan 5 bits de información y lo hace automáticamente).

Handshaking

Especifica el método de control sobre el flujo de información. En una comunicación serie se necesita conocer si el puerto puede enviar información (necesita saber si el módem está preparado para recibirla) y necesita indicarle al módem que él está preparado para recibir información. A este proceso se le denomina Handshaking. (Handshaking = Control de Flujo)(Como sabrá por sus conocimientos de inglés, Handshaking significa apretón de manos, ponerse de acuerdo. Y ponerse de acuerdo entre dos terminales que van a comunicarse es establecer las condiciones de control que uno va a tener sobre otro.)

El Control de Flujo puede hacerse de dos formas : Una mediante las señales auxiliares del puerto (RTS, CTS, DSR, DTR), que son cables adicionales que tendrán una tensión positiva respecto a los 0V del equipo si esa señal está activada, o una tensión negativa si no lo está. Este tipo de control del flujo de información es el típico para comunicarse el ordenador con un módem.

Existe otra forma de controlar el flujo de información : mediante señales especiales que se envían por los dos cables que transportan la información. Mediante estas dos señales podemos controlar que el ordenador envíe información o deje de enviarla. De igual forma, podemos indicarle al módem que envíe o no envíe. Estas señales especiales se denominan X-ON y X-OFF.

La propiedad Handshaking controla la forma de realizar este proceso. Puede tomar los siguientes valores :

0 - No existe Control de Flujo1 - Control de Flujo mediante XON - XOFF2 - Control de Flujo mediante Request To Send (RTS) y Clear To Send (CTS)3 - Control de Flujo mediante XON - XOFF y RTS - CTS

Los tres tipos de Control de Flujo tiene cada uno su aplicación.

InBufferSize

Mediante esta propiedad establecemos el tamaño del Buffer (almacén de datos) de entrada. Este Buffer sirve para poder recibir datos sin que tenga que intervenir la aplicación continuamente para controlar el puerto de entrada.


Puede conocerse el número de caracteres presentes en el Buffer de entrada consultando el valor de la propiedad InBufferCount.

OutBufferSize

Mediante esta propiedad controlamos el tamaño del Buffer de salida.

El tamaño de los Buffers dependerá de la aplicación y de la velocidad de comunicación. Si la aplicación tiene muchas cosas que hacer, aparte de controlar el puerto de comunicaciones, se deberá poner un Buffer grande. Tanto mas grande cuanta mayor sea la velocidad de transferencia de datos.

Puede conocerse el número de caracteres presentes en el Buffer de salida (los que aún están por transmitir), consultando el valor de la propiedad OutBufferCount.

RThreshold, SThreshold

Estas dos propiedades especifican el número de caracteres que deben estar presentes en los Buffers de Recepción y Transmisión respectivamente, para que se produzca el evento OnComm relativo a recepción y transmisión de caracteres. (Eventos EvReceive y EvSend) Si el valor de una de estas propiedades está a 0, no se produce el evento OnComm correspondiente.

El valor que se debe dar a estas dos propiedades depende de la aplicación y del tiempo que queramos que la aplicación está atendiendo al puerto de comunicaciones. Concretamente para la propiedad RThreshold debemos pensar muy bien el valor que se le pone. Si ponemos un valor corto (1 es el mínimo), cada vez que reciba un carácter se producirá el evento OnComm. (Vea la descripción de eventos mas adelante). Al producirse este evento, ejecutará el procedimiento asociado a él, lo que hará perder tiempo a la aplicación, impidiéndole realizar otras funciones. Si se pone un valor muy alto, el puerto no avisará que tiene caracteres recibidos hasta que reciba un número igual al programado en esta propiedad, por lo que no podremos procesar los datos recibidos hasta que el buffer tenga ese número de caracteres en su interior. En número adecuado dependerá del tipo de aplicación que vayamos a realizar. En cualquier caso, este número será inferior al número programado para la longitud del buffer, (InBufferSize)

InputLen

Por defecto, cuando se lee el Buffer de recepción, se leen todos los caracteres, quedando el Buffer vacío. Si se le asigna a esta propiedad un valor distinto de 0, cada vez que leamos el Buffer de recepción leerá un número de caracteres igual a esa cantidad, permaneciendo los caracteres restantes en el Buffer a la espera de una nueva lectura. Asignándole el valor 0 (Valor por defecto), el buffer se lee completo.

ParityReplace

Si la comunicación se realiza con bit de paridad (Par o Impar), en recepción se comprueba byte a byte la recepción de la paridad correcta. Si se recibe un Byte que no tiene paridad correcta, lo mas probable es que ese Byte (carácter) se haya recibido defectuoso. Esta propiedad nos permite sustituir un carácter que ha llegado con bit de paridad incorrecto por otro carácter. ( ? predeterminado). Se puede sustituir por una cadena de caracteres (Error, por ejemplo).


NullDiscard

Cuando se recibe el carácter nulo (00000000) puede ser que no sirva para nada a efectos de nuestra aplicación, o que este carácter sea un dato mas. Esta propiedad acepta los valores True / False. Si es True se desprecia el carácter Nulo. Si es False, se toma como un carácter mas.

CTSTimeout

Es el tiempo (en milisegundos) que permanece esperando la señal CTS (Señal CTS - Dispuesto para enviar), señal de entrada al ordenador que debe estar presente antes de que el puerto comience a enviar información. El tiempo se mide desde que se pone activa la señal de salida RTS (Petición de envío). Si se supera este tiempo entre el instante de activación de la señal RTS y la recepción de la señal CTS, se produce el evento CTSTO. Poniendo 0 en esta propiedad, se deshabilita, y en estas condiciones no se producirá nunca el evento CTSTO.

CDTimeout

Es el tiempo máximo de espera (en milisegundos) desde que se activa la señal DTR hasta que se recibe la señal CD (Carrier Detect - Detección de portadora). Este tiempo solamente tendrá importancia en ciertas aplicaciones donde se espere recibir CD continuamente. No tendrá sentido cuando la aplicación se queda en espera a recibir una comunicación, pero sin saber cuando la tiene que recibir. Si transcurre el tiempo programado en esta propiedad, ocurrirá el evento CDTO. Poniendo el valor 0 se deshabilita esta propiedad y no se producirá nunca el evento CDTO.

DSRTimeout

Similar a la anterior, pero en vez de esperar la señal CD se espera la señal DSR. Esta propiedad sí tiene sentido, ya que si, por ejemplo, estamos conectados con un módem, y nuestra aplicación se pone a la espera de recibir alguna llamada, activa la salida DTR, y espera recibir inmediatamente la respuesta de que el módem está dispuesto, mediante la línea DSR. Si transcurre el tiempo programado sin recibir la señal DSR se producirá el evento DSRTO . Poniéndola a 0, se deshabilita esta propiedad y nunca ocurrirá el evento DSRTO.

RTSEnable

Activa (Pone a 1) la señal RTS (Request To Send - Petición de envío) Esta señal debe ponerse a 1 para indicar al módem (o al equipo que va a recibir nuestra comunicación) que deseamos enviar datos. Debe estar activada durante toda la transmisión de datos.

Cuando se pone la propiedad Handshaking a 2 (control con RTS / CTS) ó 3 (Control con RTS / CTS y con X-ON / X-OFF) no debemos preocuparnos de poner a 1 la señal RTS, pues lo hace automáticamente el puerto de comunicaciones. Esta propiedad está ahí para aplicaciones donde no se emplee ese tipo de Handshaking y necesitemos activar algo antes de transmitir. (Caso por ejemplo de transmisión de datos por radio, donde podemos usar esta señal de salida para activar el PTT (Push To Talk - Pulse para hablar) y poner el transmisor en marcha)

DTREnable

Activa (Pone a 1) la salida DTR (Data Terminal Ready - Terminal de Datos Listo). Esta señal se emplea para decirle al módem que el terminal (Ordenador) está preparado para recibir datos.

Se hace la misma observación que para la propiedad anterior respecto a los valores de la propiedad Handshaking


Interval

Indica el tiempo (en milisegundos) del intervalo entre una y otra comprobación del estado de recepción del puerto. El valor mínimo es de 55 ms.

El análisis del puerto de comunicación no tiene nada que ver con la generación del evento OnComm. Este evento se producirá cuando se cumplan las condiciones para ello, independientemente del tiempo programado en esta propiedad. La comprobación del puerto cada intervalo de tiempo marcado por esta propiedad solamente afecta a averiguar el estado de las líneas auxiliares CD, DSR y CTS, y para saber el número de caracteres existentes en los Buffers de transmisión y recepción.

Las siguientes propiedades no difieren en nada respecto a otros controles :

Left, Name, Index, Top, Tag

Propiedades propias del tiempo de ejecución

PortOpen

Abre el puerto de comunicación. Puede tener los valores True (Para abrirlo) y False (Para cerrarlo) Si tenemos un MSComm con Nombre (Name) MSComm1, para abrirlo ejecutaremos la siguiente sentencia :

MSComm1.PortOpen = True

Para cerrarlo, ejecutaremos :

MSComm1.PortOpen = False

InBufferCount.

Nos permite averiguar cuantos caracteres tenemos en el Buffer de entrada. Con el mismo MSComm anterior, comprobaremos el número de caracteres sin leer con la sentencia :

caracteressinleer = MSComm1.InBufferCount

OutBufferCount

Nos permite conocer cuantos caracteres quedan por transmitir en el Buffer de salida. Emplearemos la sentencia :

caracteressinenviar = MSComm1.OutBufferCount

Output

Envía caracteres al Buffer de salida. Debe existir un signo igual ( = ) entre Output y lo que se envía al Buffer. Para enviar la frase Curso de Visual Basic ejecutaremos la sentencia :

MSComm1.Output = “Curso de Visual Basic”

Si deseamos enviar el contenido de una variable

MSComm1.Output = variable


Input

Lee el Buffer de recepción. El número de caracteres leídos dependerá del valor de la propiedad InputLen. Cuando la propiedad InputLen tiene el valor 0, el Buffer se lee completo. Si InputLen tiene un valor distinto de 0, se leerá un número de caracteres igual al valor de esta propiedad. CommEvent Devuelve el evento mas reciente que ha ocurrido para generar el evento general OnComm (Vea mas adelante). Esta propiedad no está disponible en tiempo de diseño y es de sólo lectura en tiempo de ejecución.

Sintaxis NombredelMSComm.CommEvent

Break

Devuelve un valor (True / False) que indica que se ha recibido la señal Break.

variable = MSComm1.Break

CDHolding

Devuelve el estado de la línea de control CD (Detección de Portadora) Si es True, esa entrada está activada, si es False, la entrada está desactivada.

variable = MSComm1.CDHolding

CTSHolding

Devuelve el estado de la línea de control CTS (Dispuesto para enviar) Si es True, esa entrada está activada, si es False, la entrada está desactivada.

variable = MSComm1.CTSHolding

DSRHolding

Devuelve el estado de la línea de control DSR (Data Set Ready ) Si es True, esa entrada está activada, si es False, la entrada está desactivada.

variable = MSComm1.DSRHolding

EVENTOS DEL MSComm

El MSComm tiene varios eventos, pero un solo Procedimiento : el Procedimiento OnComm. Este procedimiento se ejecuta cada vez que se produce alguno de los eventos del MSComm.Esto quiere decir que para escribir el código apropiado en el procedimiento del MSComm será necesario analizar qué evento se ha producido y colocar, mediante una sentencia If .. Then el código apropiado para cada uno de los eventos que se produzcan.

Para averiguar qué evento se ha producido puede hacerse consultando el valor de la propiedad CommEvent. (Se toma como nombre del MsComm el de MsComm1)

If MsComm1.CommEvent = ComEvRing Then

'Se ha consultado si el evento particular que ha producido el evento general OnComm'ha sido el ComEvRing (Se está recibiendo la llamada del teléfono). En esta sentencia


‘If Then deberemos colocar el código necesario para que la aplicación se prepare para‘recibir una comunicación a través del módem.

End If

Los eventos del Comm pueden identificarse por una constante o un número. La constante, como todas las de Visual Basic, tiene una expresión bastante difícil. Se pone entre paréntesis el número que identifica a ese evento. Este número debe declararse como Integer.

Se ejecutará el Procedimiento OnComm cuando ocurra alguno de los siguientes eventos :

ComEvCD ( 5 ) Cambio en la línea CD. Para conocer el estado actual de esa línea(Activado/Desactivado) deberemos invocar la propiedad CDHolding

ComEvCTS ( 3 ) Cambio en la línea CTS. Igual que la anterior, este evento solamentenos indica que ha existido un cambio. Para averiguar el estado en que se encuentra esta línea, debemos invocar la propiedad CTSHolding

ComEvDSR ( 4 ) Cambio en la línea DSR. Igual que las anteriores. Debemos invocar la

propiedad DSRHolding para averiguar su estado actual.

ComEvRing ( 6 ) Cambio en la línea de detección de llamada (Ring). Este evento seproduce cuando hay un cambio en la línea Ring (Detección de llamada en el módem)No existe una propiedad para averiguar el estado de la línea Ringpues no es necesario. Lo importante de esta línea es que está cambiando, es decir, el teléfono está sonando y poco importa que analicemos si la línea Ring está a 1 o a 0, pues toda llamada telefónica es intermitente. Dependiendo de la UART de su PC, puede que este evento no lo soporte.

ComEvReceive( 2 ) Cuando se recibe un número igual o mayor de caracteres que elindicado en la Propiedad RThreshold

ComEvSend ( 1 ) Cuando quedan en el búfer de transmisión menos caracteres que losindicados en la Propiedad SThreshold

ComEvEOF ( 7 ) Recibido un carácter de fin de archivo (carácter ASCII 26) .

comEventBreak (1001) Se ha recibido una señal de interrupción. (Break)

ComEventCDTO (1007) Tiempo de espera de Detección de portadora. La líneaDetección de portadora (CD) estuvo baja durante el periodo de tiempo especificado en la Propiedad CDTimeout, mientras se intentaba transmitir un carácter.

ComEventCTSTO 1002 Tiempo de espera de Preparado para enviar. La línea Preparado para enviar (CTS) estuvo baja durante el periodo de tiempo especificado en la propiedad CTSTimeout mientras se intentaba transmitir un carácter.

ComEventDSRTO 1003 Tiempo de espera de Equipo de datos preparado. La línea Equipo de datos preparado (DSR) estuvo baja durante el periodo detiempo especificado en la Propiedad DSRTimeout mientras se intentaba transmitir un carácter.


ComEventOverrun 1006 Se sobrepasó la capacidad del Buffer de entrada sin haber leído todos los caracteres. Los caracteres no leídos se han perdido. Debemos aprovechar este evento para solicitar al colateral una repetición de los datos perdidos.

ComEventRxOver 1008 Desbordamiento del búfer de recepción. No hay espacio para más datos en el búfer de recepción.

ComEventRxParity 1009 Error de paridad. El hardware ha detectado un error de paridad.

ComEventTxFull 1010 Búfer de transmisión lleno. El búfer de transmisión estaballeno cuando se ha intentado agregar un carácter a la cola de transmisión. Este error es fácil de evitar, analizando el valorde la propiedad OutBufferCount antes de enviar mas datos al buffer de salida.

ComEventDCB 1011 Error inesperado al recuperar el Bloque de control dedispositivos (DCB) para el puerto.

ComEventFrame 1004 Error de trama. El hardware ha detectado un error de trama.


NOTA ADICIONAL El puerto de comunicaciones.

El puerto de comunicaciones de un PC está formado por varias entradas / salidas. El soporte físico es un conector tipo Sub-D de 9 ó 25 contactos, macho en ambas versiones. Se necesita por tanto un cable con conector Sub-D hembra de 9 o 25 pines para acceder a él.

La distribución de las señales en cada uno de sus pines es la siguiente :

GND (Potencial de 0 V.).

TxD Transmisión de datos. Es una salida del ordenador. Por ella salen los datos en serie.

RxD Recepción de datos. Es una entrada del ordenador. Por ella entran los datos en serie.

RTS Request To Send. Petición de envío. Es una salida del ordenador. El ordenador pone a1 esta señal cuando quiere enviar datos.

CTS Clear To Send. Dispuesto para enviar. Es una entrada del ordenador. Si está a 1significa que el ordenador puede enviar datos pues el módem (o el dispositivo que vaya a recibirlos) está preparado para hacerlo.

DSR Data Set Ready. Dispositivo de datos preparado. Es una entrada del ordenador. Leindica que el módem está encendido y listo para funcionar.

DCD o CD Carrier Detect. Detección de portadora. Es una entrada del ordenador. Leindica al ordenador que el módem está detectado señal de audio (tonos) válida.

DTR Data Terminal Ready. Terminal de datos listo. Es una salida del ordenador. Indica queestá listo para trabajar. Suele emplearse para indicar al módem que el ordenador estádispuesto para recibir información.

Otra señal (disponible sólo en los ordenadores que tengan conector de 25 pines, y no en todos) es la señal RING (timbre del teléfono) Es una entrada del ordenador. Le indica que está sonando el timbre de la línea telefónica del módem.

Disposición de los pines en el ordenador

Dependiendo de si tiene conector de 9 pines o de 25, la distribución de estas señales físicamente en el conector es :

Conector de 9 pines Conector de 25 pines

Pin Señal Pin

3 TxD 22 RxD 37 RTS 48 CTS 56 DSR 65 GND 71 CD 84 DTR 20

RING 22Tierra de protección 1

(La señal RING no está disponible en el conector de 9 pines. La detección del Ring del teléfono se realiza directamente por la línea RxD. El módem envía la palabra RING cuando suena el timbre del teléfono. La tierra de protección tampoco se usa en este conector.
