Visual Basic - Guía del Estudiante Cap.

20
APLICACIONES CLIENTE SERVIDOR
COMUNICACIÓ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)

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

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.

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

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.

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

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.

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

LSB Visual Basic Guía del Estudiante Cap. 20 Pág. 6
ANEXO 1
SERVIDOR 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:

Ordenes
Respuestas
Confirmaciones
Avisos

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%’>

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

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>

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

<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.

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

<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.

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

<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.

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

LSB Visual Basic Guía del Estudiante Cap. 20 Pág. 12
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 :

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

 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 IMPAR
E - 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ón
5 - 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 parada

2 - 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 Flujo

1 - Control de Flujo mediante XON - XOFF
2 - 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.

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

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).

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

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

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

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

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

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

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

 ‘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 solamente
nos 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 se

produce 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 Ring
pues 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 el

indicado en la Propiedad RThreshold

ComEvSend (1) Cuando quedan en el búfer de transmisión menos caracteres que los
indicados 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ínea

Detecció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 de
tiempo especificado en la Propiedad DSRTimeout mientras se
intentaba transmitir un carácter.

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

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 estaba

lleno cuando se ha intentado agregar un carácter a la cola de
transmisión. Este error es fácil de evitar, analizando el valor
de la propiedad OutBufferCount antes de enviar mas datos al buffer
de salida.

ComEventDCB 1011 Error inesperado al recuperar el Bloque de control de

dispositivos (DCB) para el puerto.

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

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

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 a
1 esta señal cuando quiere enviar datos.

CTS Clear To Send. Dispuesto para enviar. Es una entrada del ordenador. Si está a 1
significa 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. Le
indica que el módem está encendido y listo para funcionar.

DCD o CD Carrier Detect. Detección de portadora. Es una entrada del ordenador. Le

indica 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 que
está 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 2
2 RxD 3
7 RTS 4
8 CTS 5
6 DSR 6
5 GND 7
1 CD 8
4 DTR 20
RING 22
Tierra 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.

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