Visual Basic - Gua del Estudiante Cap.

20
APLICACIONES CLIENTE SERVIDOR
COMUNICACIN PUERTO SERIE: EL CONTROL MSCOMM
(Captulo inacabado. Algn estudiante quiere colaborar a su terminacin?)
Hasta ahora hemos visto aplicaciones que pueden utilizarse por s solas. Pueden acceder a
bases de datos que estn en el mismo ordenador que la aplicacin o en otro, unido mediante
una red de rea local. La conexin a las bases de datos a las que accede se realiza, bien
indicndole la direccin y carpeta (\\MiServidor\BasesdeDatos\MiBase.Mdb) o bien mapeando
esa direccin (crear una unidad de disco que contienen esa direccin). De esta forma
podemos acceder a una base de datos instalada en un equipo remoto y la aplicacin debe
funcionar perfectamente, aunque al abrir o leer la base de datos origine un trfico elevado por
la red de rea local.
Con esta configuracin podemos tener problemas de lentitud, sobre todo si la red es lenta y si
hay muchos usuarios trabajando con esa aplicacin en distintos ordenadores, accediendo
todos ellos a travs de la red a un servidor que contienen la base de datos. Esta lentitud se
incrementara en una gran escala si la red a utilizar fuese Internet mediante una conexin lenta.
Pero lo que ms se notara sera la ocupacin de los recursos de la red durante las consultas a
esa base de datos. Dependiendo de cmo se crease el recordset, podra darse el caso de
transmitir por la red todos los datos de la base de datos para que nuestra aplicacin utilice
nicamente los datos correspondientes a un registro. Pensando en una aplicacin bancaria,
por ejemplo la peticin de saldo de una cuenta desde un cajero automtico, los nicos datos
relevantes de esa operacin sern el nmero de cuenta corriente, un cdigo para indicar que lo
que se desea es el saldo, y como datos de retorno, el nmero de esa cuenta, el saldo actual
disponible y quizs un nmero de comprobacin (Checksum) para comprobar que no ha
existido error en la comunicacin. De nada nos servira en el cajero conocer el estado de
cantidades retenidas, operaciones pendientes, etc.
Si en ese ejemplo del cajero cresemos un objeto Database, un recordset, leysemos todos los
datos del recordset y luego disemos la orden de cerrarlo, estaramos enviando informacin
innecesaria a travs de la red, con el coste de tiempo y ocupacin que ello representa.
Casi llegamos a demostrar con esta introduccin que sera ms conveniente hacer una
aplicacin que tuviese dos partes: una, residente en el puesto de operacin, (que llamaremos
aplicacin cliente) que fuese capaz de enviar datos solicitando informacin a otra aplicacin,
instalada en el servidor donde est la base de datos. Esta segunda aplicacin, que llamaremos
aplicacin servidor, abrir la base, crear los recordsets necesarios, filtrar la informacin,
realizar con ella operaciones matemticas, y una vez concluido todo el proceso, enviar a la
aplicacin cliente los datos estrictamente necesarios. Obviamente se necesita que ambas
aplicaciones sean capaces de entenderse entre s, es decir, que tengan un protocolo de
comunicacin entre ellas previamente definido. Esto es lo que se denomina una aplicacin
cliente servidor.
La aplicacin cliente servidor ms popular es el navegador de Internet. Esta aplicacin est
formada por una aplicacin cliente (Navegador IEXplore, NetScape, etc) y una aplicacin
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 pblicos, permiten a cualquier
empresa hacer su propia aplicacin cliente o servidor.
No es nuestro deseo llegar a tanto. El navegador de Internet es una aplicacin clienteservidor
que sobrepasa cualquier proyecto que podamos imaginar para realizarlo por medio de
programacin en VB. Cualquier navegador de Internet comercial lleva asociadas una serie de
funciones, muchas de ellas transparentes para el usuario, que sera imposible crear una
aplicacin de este calibre, sobre todo como ejemplo de un curso de VB. Pensemos en una

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 1

aplicacin ms sencilla, que nos permita conocer como funcionan las aplicaciones cliente
servidor, y sirva adems para algo til.
Esa aplicacin no puede ser otra que una gua telefnica, (versin novsima del Listatel) cuya
base de datos est en un servidor conectado a Internet, al que se podr acceder desde un
nmero ilimitado de puestos cliente. En la base de datos del servidor, en un conjunto de tablas,
figurarn los nombres, nmeros de telfono, despacho, etc. de una serie de personas, y el
organigrama de esas personas dentro de la organizacin. Estas tablas sern estticas, es
decir, tendrn datos que solamente se actualizarn cuando exista un cambio en esas personas,
pero no variarn durante la ejecucin del programa. En otra tabla, esta dinmica, tendremos el
registro de los usuarios que estn 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 direccin IP actual. Sabiendo que est conectado y con su
direccin IP podremos enviarle mensajes directamente. Creo que ya vemos que se trata de una
agenda telefnica que lleva incorporado un servicio de mensajera. El servicio de mensajera
enviar mensajes con texto plano o RTF y puede llevar ficheros anexados. A esta agenda, y a
su protocolo de comunicacin le vamos a denominar SML. No se preocupe de no conocer las
siglas. Al protocolo SMTP tampoco lo conocan en el momento de su creacin.
Una aplicacin cliente puede comportarse como aplicacin servidor de otra aplicacin, incluso
de s misma. Este es el caso de la aplicacin cliente del SML. Cuando vamos a pedir la
informacin de un abonado telefnico al servidor, el cliente se comporta como tal. Sin embargo
cuando otro usuario de SML nos enva un mensaje, es nuestra aplicacin la que realiza las
funciones de servidor. Ver esto con mucha ms claridad cuando comencemos el ejemplo.
Toda aplicacin cliente - servidor debe tener un sistema de comunicacin entre la aplicacin
cliente y la aplicacin servidor. Parece que la comunicacin que ha de tener es a travs de una
red IP (Red de Area Local, Red Privada Virtual, Internet) pero puede ser cualquier otro sistema
de comunicacin entre ordenadores. Sin ir ms lejos, a travs del puerto de comunicacin serie
COM-1 COM-2. A efectos de los programas de la aplicacin cliente o servidor solamente
variar en la forma en la que reciban y transmitan los datos. En nuestro ejemplo vamos a
utilizar la comunicacin a travs de una red IP, usando el control Winsock ya estudiado. Tanto
la aplicacin cliente como la aplicacin servidor debern tener un Winsock. Como en nuestro
caso, segn explicamos ms atrs, la aplicacin cliente se convierte en aplicacin servidor para
recibir mensajes, sta deber tener dos Winsocks, uno para la funcin cliente, y otro para la
funcin servidor.
Cuando se disea una aplicacin cliente servidor hay que comenzar pensando en las
funciones que va a realizar y sobre esas funciones comenzar a escribir el protocolo de
comunicacin. No es fcil tener terminado el protocolo de comunicacin antes de escribir la
primera lnea de cdigo del programa. Segn se van concretando cada una de las acciones
que debe realizar vemos que es necesario introducir nuevos cdigos de operacin 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 aplicacin 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 comunicacin se establezca antes de
comenzar a escribir el cdigo en tanto se pueda. Y que se escriba en un documento en el
propio ordenador o mejor an, en una base de datos u hoja de clculo, que nos permita
ordenar las rdenes y avisos de nuestra aplicacin para evitar de esta forma cualquier
repeticin involuntaria.
Es muy importante a la hora de pensar el protocolo de comunicacin que este no pueda inducir
a error al programa. Si el programa tiene como funcin la transmisin 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 imaginacin del autor y no sujeto a normas ni
recomendaciones internacionales de ningn tipo)

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 2

Protocolo de comunicacin de la aplicacin SML.

(Vea el ANEXO 1 Protocolo de comunicacin SML)
La comunicacin entre ambas aplicaciones se establece mediante palabras en ASCI que
indican una operacin. A estas palabras las denominamos Acrnimos. Las operaciones
pueden ser rdenes o avisos. Son rdenes aquellas comunicaciones del cliente que
desencadenan una operacin 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
parmetros. Los parmetros contienen la informacin necesaria para que la operacin que se
va a realizar por esa orden o aviso pueda llevarse a cabo. En esta aplicacin SML los
acrnimos todos son de 3 caracteres, utilizando los signos < > como delimitadores del
acrnimo. Si el acrnimo lleva parmetros, la separacin entre los tres caracteres y el
parmetro o parmetros es la barra /
Volvamos a lo comentado anteriormente respecto a la limitacin del contenido de un mensaje.
Si el mensaje contiene un carcter <, > / puede que el programa se confunda y piense que
ese carcter forma parte de un acrnimo. Para evitar cualquier confusin, si uno de estos
caracteres forma parte de un texto, se le antepondr el signo &. De esta forma la recepcin de
la pareja de caracteres &<, &> &/ significa que no son parte de un acrnimo sino texto.
Observe ahora que ese mismo problema lo vamos a tener con el carcter &. Si queremos
enviar ese carcter, sin que haya posibilidad de error pensando que se trata del carcter &
antepuesto a cualquiera de los signos anteriores, deberemos poner delante de l tambin el
signo &. As, && significa que se est transmitiendo el signo &.
Es obvio pensar que esas tres combinaciones no pueden formar parte de ningn acrnimo.
Pero como los acrnimos los definimos nosotros, basta con hacer que ninguno contenga esas
secuencias de caracteres.
Preocpese de estos detalles que son los realmente importantes. Ver cuando se ponga a
escribir cdigo que siempre ha de faltar algo en el protocolo de comunicacin. No se preocupe
por tener que ir rectificndolo. Eso s, mantenga siempre actualizado el documento o base de
datos con el protocolo, explicando debidamente cada una de sus partes, los parmetros que
lleva y la funcin que realiza. Es documento indispensable a la hora de distribuir la aplicacin.
A modo de recordatorio, los protocolos de comunicacin de las aplicaciones cliente servidor
para Internet se encuentran en las RFCs, (Request For Coments) son pblicas, y han tardado
en desarrollarse varios aos 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 pginas donde puede ver todas las recomendaciones para todos los servicios
de Internet.
El protocolo de comunicacin debe hacerse preferentemente en ASCII puro y caracteres que
tengan representacin fsica. Esto nos permite depurar el programa analizando la comunicacin
mediante un programa externo y debidamente probado. Utilizar caracteres sin representacin
ASCII lo nico que puede hacerle es complicarle la vida a Ud. y a quien analice su aplicacin.
Cuando se enve una cifra, hgalo en decimal o en hexadecimal. Evite en lo posible enviar
cifras sustituyendo su valor por su carcter equivalente. La mayora 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 numeracin Hexadecimal.
Un buen programador nunca oculta el protocolo de comunicacin. Esto permite que otros
mejoren su aplicacin. Slo los programadores mediocres temen que se les plagie. Y por
supuesto, nadie debera aceptar una aplicacin cliente servidor si el programador no
suministra ese protocolo.

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 3

Aspectos que debe tener siempre en cuenta cuando disee una

aplicacin cliente servidor.
Si como es normal, utiliza una red IP para la transmisin de informacin entre ambas
aplicaciones, deber poner un Winsock en la aplicacin cliente, que deber conocer la
direccin IP o el DNS de la aplicacin 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 aplicacin, y atender a todas las llamadas que reciba creando una instancia de ese
Winsock. Crear una instancia para cada comunicacin entrante desde los clientes. La
comunicacin en el servidor se mantendr abierta hasta que el cliente la cierre. Solamente en
circunstancias excepcionales, cerrar la comunicacin el servidor. Por ejemplo, en aquellos
casos en los que pase un tiempo predeterminado sin recibir ni enviar ningn dato al cliente.
Para eso se utilizar una tecnologa muy sencilla, denominada Watch Dog consistente en un
contador que se pone a cero cada vez que se recibe o se envan datos al cliente. Ese contador
incrementa su cuenta en una unidad cada cierto tiempo. Si llega a un nmero predeterminado,
prueba evidente de que ha pasado un tiempo sin que reciba ni enve informacin, cierra la
conexin del Winsock asociado. De cualquier forma hay que tener cuidado y pensar muy bien
lo que se hace antes de cerrar la comunicacin desde el servidor.
El programa cliente debe conocer el nmero IP o direccin DNS del servidor. Pero el servidor
no tiene porque conocer la direccin ni DNS del cliente, ya que debe ser el cliente el que inicie
siempre la comunicacin.
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 conexin abierta por ste, es decir, usando
la instancia de su Winsock correspondiente a la conexin 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 estn conectados en este momento. Solamente lo he visto en algunas aplicaciones
de seguridad. Generalmente este pooling se sustituye por llamadas peridicas desde cada
cliente para indicarle al servidor que estn activos.
La comunicacin 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 ms trabajar un poco ms el cdigo y trabajar
con comunicaciones seguras aunque sea en una red de rea local que garantice la llegada de
UDP.
Los paquetes broadcast deben evitarse tambin. Solamente deben usarse en configuraciones
donde no se conocen las direcciones de los servidores. Esto ocurre cuando la red tiene
asignacin dinmica 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
automticamente.
Posiblemente haya ms recomendaciones relativas a la comunicacin. Veamos ahora otras
recomendaciones acerca del cdigo y de la funcionalidad.
Dado que la aplicacin cliente y la aplicacin servidor son completamente independientes, es
muy fcil 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 comunicacin.
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 versin
mejorada, usar con l un protocolo de comunicacin que permita las nuevas prestaciones. Si
el cliente tiene la versin ms antigua, deber seguir usando con l el protocolo anterior.

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 4

Esto nos lleva a que el cliente siempre debe indicar al servidor su versin. Esto no ocupa unos
recursos excesivos y puede ser muy til cuando prevemos introducir una modificacin. Esta
prctica puede incluso servir para conocer aquellos clientes a los que hay que realizar el
cambio de versin y enviarles una nueva. En el ejemplo de este curso, el cliente comunica al
servidor su versin en el acto de conectarse mediante el acrnimo <VER>.
El servidor tambin debera enviar su versin al cliente. No est previsto en la aplicacin SML
pero confieso que no sobrara que al identificarse el cliente y devolverle el servidor la
conformidad del registro, le devolviese tambin la versin del servidor. Se da cuenta que
segn se avanza en la definicin del protocolo aparecen nuevas necesidades?
La aplicacin cliente debe mostrar de forma clara al usuario el estado de conexin o
desconexin con el servidor. Y a ser posible, que indique la causa de la no conexin (Fallo en
la RAL, fallo en el servidor) Esta informacin se obtienen de forma muy sencilla analizando los
errores generados en el Winsock a la hora de realizar la conexin.
Cuando utilice el puerto COM para la comunicacin, bien sea directamente o a travs de
mdem, debe indicar claramente al usuario el estado de esa conexin, analizando la seal
DSR (esta seal est activa cuando el mdem est conectado, y en caso de comunicacin
directa, cuando se use, el Host debe poner a 1 esta seal para poder trabajar). Recuerde que
la comunicacin por el puerto COM es asncrona respecto a la ejecucin del programa.
En el ejemplo de aplicacin cliente servidor se han ensayado tambin los controles
avanzados de Visual Basic (Capitulo 16). La aplicacin tal como se dijo es una gua telefnica,
que presenta en un TreeView el organigrama del Organismo o empresa a la que pertenece la
gua. Esto facilita la bsqueda de una persona, hacindolo por departamento. La gua permite
tambin buscar por nombre, primer apellido, segundo apellido o combinacin de ambos. Una
vez encontrada la persona, se cubren todos los datos de la misma, para presentarlos en la
solapa de la gua propiamente dicha, y el dato de su alias (dato que define de forma nica a
cada usuario) aparece en la direccin de correo para poder enviarle un mensaje. Para hacer
una prctica con el puerto de comunicaciones COM-1 COM-2 utilizaremos un mdem,
conectado al PC a travs de uno de estos puertos, para marcar el nmero telefnico.
Todas las operaciones de bsqueda de datos las haremos mediante consultas a la base de
datos que est en el servidor. Las consultas se realizarn siguiendo el protocolo de
comunicaciones. El organigrama se guardar en el cliente, en una base de datos, para evitar
en lo posible el envo desde el servidor. La razn para esto es que el organigrama puede ser
muy extenso, y no va a variar muy a menudo. Como esta informacin habra que enviarla nada
ms conectarse el cliente, y como puede ser bastante amplia, esto podra originar un trfico
intenso por la red, que es justamente lo que queramos evitar. Solamente se va a enviar cuando
haya cambiado. Cmo sabe el cliente que ha cambiado?. Cmo sabe el servidor que el
cliente tiene ya la informacin actualizada? La idea ms sencilla para conocerlo es que el
cliente enve cada vez que se registra (al comienzo de la conexin) el nombre de la revisin del
organigrama que tienen. El nombre puede ser cualquiera. Lo que hace el servidor por defecto
para poner el nombre a la revisin es combinar una cadena de texto con el nombre de la
organizacin seguido de la fecha (da/mes/ao) en la que se realiza la revisin. 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 revisin, le devuelve un OK. Si no es igual, le devuelve una instruccin
para que el cliente solicite al servidor que le enve la nueva revisin. El cliente la solicita y el
servidor se la enva. 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
comunicacin entre cliente y servidor, y paralelamente creando el protocolo de comunicacin.
Por eso es muy probable que el protocolo de comunicacin no est acabado hasta que est
acabada la aplicacin.
Al da de hoy (30 de Octubre de 2002) no est terminada la aplicacin. Posiblemente no lo est
nunca porque sea una aplicacin en continua ampliacin. Esto es lo bonito de los programas
ejemplo de los cursos de visual basic.

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 5

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 6

ANEXO 1
SERVIDOR DE BASES DE DATOS Y MENSAJERIA LISTATEL (SML)
PROTOCOLO DE COMUNICACIN CLIENTE SERVIDOR
La comunicacin entre cliente y servidor se realizar mediante el protocolo descrito ms
adelante, a travs de cualquier medio de comunicacin. Generalmente ser comunicacin a
travs de red IP, pero esto no debe impedir que los clientes se puedan conectar al servidor a
travs de otros medios de comunicacin, como puede ser un mdem telefnico o un enlace va
satlite.
En cualquier caso, el contenido de las rdenes y comandos de este protocolo ser siempre en
ASCII, con caracteres alfanumricos que permitan ver perfectamente el trfico entre ambos
interlocutores. El hecho de utilizar solamente caracteres legibles asegura igualmente la
comunicacin a travs de cualquier medio de telecomunicacin, incluyendo dispositivos de
cifrado on-line colocados entre cliente y servidor.
La comunicacin puede iniciarse tanto en el servidor como en cualquiera de los clientes. Una
comunicacin puede estar compuesta de:
Ordenes
Respuestas
Confirmaciones
Avisos
Ordenes: Son aquellas partes de la comunicacin que inician una operacin en el equipo
colateral.
Respuestas. Son siempre respuesta a una orden, y contendrn el resultado de la operacin
generada por la orden, o en su defecto, la notificacin de que esa orden no ha sido ejecutada o
que dio resultado nulo.
Confirmaciones: Son el reconocimiento de recepcin de una comunicacin. Pueden
emplearse tanto para responder a un aviso como para confirmar que una orden se ha recibido,
y que est siendo tratada. Tambin 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 accin en el colateral, pero
informan de algo. Por ejemplo, servidor fuera de servicio temporalmente, servidor restablecido.
Pueden ser individuales, en cuyo caso generarn normalmente una confirmacin, o broadcast,
en cuyo caso no generarn confirmacin.
Formato de las tramas de comunicaciones.
La trama de una comunicacin estar compuesta de unos acrnimos que indicarn la orden,
respuesta, confirmacin o aviso que envan, direccin IP, nombre de la mquina o nombre del
servidor que enva, direccin IP, nombre de la mquina o nombre del servidor destino, datos,
cheksum de la trama y acrnimo de fin de trama. Cada uno de estos componentes ir metido
entra los smbolos < > y su longitud puede ser variable. Cuando se enve informacin, esta se
colocar detrs del acrnimo que la define, separada por la barra /.
Ejemplos:
<SAT> Servidor Atencin. Inicia una sesin de un cliente con el servidor.
<IPO/10.3.22.119>
Direccin IP del equipo origen
<IPD/217.126.179.96> Direccin IP del equipo destino
<QRY/Select * From Agenda_Personal Where Apellido1 Like FERN%>

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 7

Si hubiese que emplear los smbolos /, &, < o > como smbolos de la informacin, deber
anteponerse a cada uno de ellos el smbolo &.
Por ejemplo:
<QRY/Select * From Agenda_Personal Where Edad &> 25>
El cheksum ser el resultado de realizar la funcin 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 acrnimo CHK. Por ejemplo,
<CHK/235>
El acrnimo 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 acrnimo que inicie la sesin de comunicaciones, en penltimo lugar el cheksum, y en ltimo
lugar el <EOT>
Una trama puede contener varias ordenes siempre y cuando estas sean congruentes.

Cuadro con los acrnimos usados en las tramas de comunicacin.

<RHC>
<SAT>
<CAT>
<LIC>
<LOC>
<ALC>
<ALS>
<PWC>
<IPO>
<IPD>
<NMO>
<NMD>
<NSO>
<NSD>
<QRY>
<QPR>
<RQY>
<QIP>

LSB

Remote Host Conectado. Lo devuelve el servidor o un cliente cuando otro

equipo se conecta a l.
Servidor ATencin. Inicia una sesin de comunicacin desde el cliente al
servidor.
Cliente Atencin. Inicia una sesin de comunicacin desde una mquina
(Servidor o cliente) a una mquina cliente.
Login Cliente. Indica que el cliente desea hacer Login en ese servidor. Pasa
como parmetros el alias y el password (en claro o cifrado) del cliente.
LogOut de cliente. Ese cliente quiere hacer LogOut de ese servidor. Pasa como
parmetros el alias y el password (en claro o cifrado) del cliente.
Alias de cliente. Llevar como dato el alias de ese cliente.
Alias de servidor. Llevar como dato el alias de ese servidor.
Password del cliente. Lleva como parmetro el password (en claro o
encriptado) del cliente
IP de la mquina origen. Llevar como dato el nmero IP de la mquina origen
de la trama.
IP de la mquina destino. Llevar como dato el nmero IP de la mquina
destino.
Nombre mquina origen. Llevar como dato el nombre de la mquina dentro de
la red.
Nombre mquina destino. Llevar como dato el nombre de la mquina dentro
de la red.
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 mquina donde se alberga el programa servidor.
Nombre servidor destino. Igual que el anterior.
Consulta a una base de datos. Llevar como datos la consulta completa en
SQL
Consulta ya preprogramada en el servidor. Lleva como parmetro el nombre de
esa consulta, y los datos que necesite esa consulta para su ejecucin.
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 ( [ ] )
Consulta de los datos del correo de un usuario. Enva como parmetro el Alias
del usuario del que se quieren conocer los datos. Devuelve los datos con el
acrnimo <QIP>

Visual Basic Gua del Estudiante

Cap. 20

Pg. 8

<QIR>
<QIS>
<ECO>
<OCE>
<CRY>

Consulta los datos del correo de un usuario pasndole en este caso como
parmetro la direccin de correo SML. Devuelve los datos con el acrnimo
<QIP>
Consulta los datos del correo de un usuario pasndole la direccin de correo
SMTP. Devuelve los datos con el acrnimo <QIP>
Orden de envo del mismo dato en la respuesta a esa orden. Se enva, por
ejemplo, en una consulta a la base de datos, para que el cliente ubique la
respuesta a esa consulta en un sitio determinado.
Se emplea para devolver el mismo dato recibido con <ECO>
Inicia o finaliza una operacin de cifrado de datos. Lleva como parmetro INI
para iniciar y FIN para terminar. En el caso de iniciar, lleva uno o dos
parmetros ms, el nmero 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 envan como dos parmetros
<CRY/INI/PUB_LUIS.RODRIGUEZ/PRI_JOSE.LOPEZ>
Si el inicio no llevase parmetros de clave, el servidor entender que se cifra
con la clave asignada en el servidor al usuario que enva
<CRY/FIN>

<DI0>
<DI1>
...
<DI9>

Datos iniciales. Son datos que se envan entre aplicaciones

para su inicializacin. Van del 0 al 9 . Pueden usarse en ambos
sentidos. Preferentemente, DI5 como contestacin a DI0,
DI6 como contestacin a DI1, etc.

<BRC>
<BRS>
<BRA>
<VER>
<VES>

Mensaje dirigido a todos los clientes

Mensaje dirigido a todos los servidores
Mensaje dirigido a todos los equipos (Clientes y servidores)
Versin del programa cliente. Se enva al registrarse.
Solicita la versin de software del servidor. Devuelve la versin del software del
servidor.
Busca IP. Se usa para comprobar que un cliente est disponible actualmente en
la red. No lleva parmetros.
Es la respuesta del cliente a la llamada <BIP> Lleva como parmetro la
direccin SML o el nombre del usuario de ese cliente.
Usuario Cliente Conectado. Se devuelve cuando un cliente recibe una solicitud
de conexin. Es equivalente al RHC del servidor.
Informacin del mensaje. Nmero 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 nmero que
indica el ao, mes, da, hora, minuto y segundo del envo, todos ellos de dos
dgitos. (abcdyymmddhhnnss)
Origen del mensaje (From) Lleva como parmetro la direccin SML del origen.
Direccin IP desde la que se enva el mensaje. Es similar a <IPO> pero
solamente se utiliza al enviar un correo.
Informacin del mensaje. Indica direccin de correo a la que se est enviando
el mensaje. Lleva como parmetro la direccin SML o SMTP del destino.
Informacin del mensaje. Indica el Asunto (Subjet) del mensaje. Lleva como
parmetro el contenido del asunto.
Informacin 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 enviarn varios grupos <NX_>. Lleva como parmetro el nombre del
fichero en el origen y el tamao (en bytes) del fichero.
Cheksum del fichero anexado. Lleva como parmetro 8 bytes con el cheksum
en Hexadecimal. (El cheksum son 32 bits 4 bytes- expresados en
hexadecimal. Si no enva cheksum, estos 8 bytes se sustituyen por la cadena
YYYYZZZZ.
Comienza la transmisin del anexo. No lleva parmetros. El primer carcter del
anexo debe transmitirse inmediatamente despus de este acrnimo.

<BIP>
<DIP>
<UCC>
<MN_>

<FR_>
<IP_>
<TO_>
<SJ_>
<NX_>

<CX_>

<BX_>

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 9

<EX_>
<MSG>
<CHM>

<RTF>

<SAR>

<SAL>

<FM_>

Termina la transmisin del anexo. Este acrnimo debe enviarse

inmediatamente despus del ultimo carcter del anexo.
Cuerpo del mensaje enviado como texto. Lleva como parmetro el texto del
mensaje.
cheksum del mensaje. Se enva cuando se solicita acuse de recepcin o de
lectura, para comprobar la exactitud de la transmisin. Se usa tambin para
devolver el cheksum del mensaje al origen en la confirmacin de recibo o
lectura. Lleva como parmetro los dos bytes del checsum codificados en
hexadecimal (4 caracteres).
Informacin del mensaje. Indica que el contenido del mensaje est en formato
RTF. Puede no llevar ningn parmetro, en cuyo caso indica que todo el
cuerpo del mensaje est en formato RTF, o llevar le parmetro INI para indicar
que comienza el formato RTF y FIN para indicar que termina. Afecta solamente
al cuerpo del mensaje enviado con <MSG>
Solicitado acuse de recibo. Puede llevar como parmetro una direccin de
correo SML o SMTP que ser en este caso a quien enviar acuse de recibo del
mensaje. Si no lleva ningn parmetro 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 ledo.
Solicitado Aviso de Lectura. Puede llevar como parmetro una direccin SML o
SMTP que ser en este caso a quien se enve el aviso de lectura del mensaje.
Si no lleva parmetro 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 ledo.
Fin del mensaje. Indica que se ha transmitido todo el mensaje con todos los
anexos. En caso de una transmisin de mensajes mltiples, lleva como
parmetro el nmero del mensaje que termina. En caso de mensaje nico no
lleva ningn parmetro o puede llevar el nmero del mensaje.

Una mquina puede identificarse bien por su direccin IP o por su nombre dentro de una red.
Puede tambin identificarse por ambos, en aquellas situaciones en las que la mquina
receptora del mensaje deba retransmitirlo a otra mquina. Este es el caso, por ejemplo, de una
red conectada a travs de una conexin ADSL. El mdem ADSL tiene asignado un nmero IP
verdadero, y en esa red existen varias mquinas que cada una de ellas tendr un nombre
distinto, y un nmero IP distinto, (nmero IP que para estas mquinas ser ya de la numeracin
interna) Al poder identificar una mquina por su IP y nombre, basta con poner como IP de
destino el numero IP real del mdem ADSL, y como nombre, el nombre de la mquina 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 mquina Administracion_1 que est en
la red de rea local cuyo acceso desde Internet se realiza por un mdem ADSL cuyo nmero IP
es el 217.126.179.96. Lgicamente, la mquina real que recibe esta comunicacin no es la
mquina Administracion_1, sino otra mquina 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 mquina, una
vez recibido el mensaje, lo reenva a la mquina Administracion_1 que ser quien lo trate. Si la
comunicacin no llevase ms que el nmero IP, se entiende que el destino es la mquina que
tiene ese nmero IP.
ORDENES PREPROGRAMADAS
Las rdenes preprogramadas son aquellas que el servidor ya tienen programadas en su
cdigo. Deben ir necesariamente tras el acrnimo <QPR> ya que en caso contrario no sern
tratadas.

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 10

<ORG>
<ABN>
<ABD>
<ABL>
<ABC>
<ABB>

<ABA>

<ABE>

<ABF>

<ABG>

<ABH>

LSB

Pide / devuelve el organigrama. No lleva ms parmetros

Pide devuelve el nombre t Telfono 1 de los abonados de un departamento. Se
le pasa como parmetro el ID de ese departamento (Campo
Ag_Departamento_ID)
Pide / devuelve todos los datos de un abonado. Lleva como parmetro el ID de
ese abonado.
Pide / devuelve todos los datos de los abonados de un departamento. Se le
pasa como parmetro el ID del departamento.
Pide todos los datos de los abonados de un despacho. Se le pasa como
parmetro el nmero de despacho. Los datos se devuelven con el acrnimo
<ABL>
Pide todos los datos de los abonados que tienen un determinado nombre
(Bsqueda aproximada por ambos lados) Se pasa como parmetro el nombre
por el que se quiere buscar, o las letras del nombre por el que se va a realizar
bsqueda aproximada. Devuelve los datos con el acrnimo <ABL>
Pide todos datos de los abonados con un determinado primer apellido
(Bsqueda aproximada por la derecha) Se pasa como parmetro el apellido a
buscar, o la cadena de caracteres por la que har la bsqueda. Devuelve los
datos con el acrnimo <ABL>
Pide todos los datos de los abonados con un determinado segundo apellido.
(Bsqueda aproximada por la derecha) Se pasa como parmetro el apellido a
buscar, o la cadena de caracteres por la que har la bsqueda. Devuelve los
datos con el acrnimo <ABL>
Pide todos los datos de los abonados con el mismo primer apellido (Bsqueda
aproximada por la derecha) y segundo apellido (Bsqueda aproximada por la
derecha). Se pasan como parmetros los apellidos a buscar, o las cadenas de
caracteres por las que har la bsqueda. Devuelve los datos con el acrnimo
<ABL>
Pide todos los datos de los abonados con el mismo nombre (Bsqueda
aproximada por los dos lados) y el mismo primer apellido (Bsqueda
aproximada por la derecha) Se pasa como parmetro el nombre y apellido a
buscar, o las cadenas de caracteres por la que har la bsqueda. Devuelve los
datos con el acrnimo <ABL>
Igual que el anterior, con nombre y segundo apellido.

Visual Basic Gua del Estudiante

Cap. 20

Pg. 11

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 12

EL CONTROL PERSONALIZADO MICROSOFT COMM

Este control permite la comunicacin de una aplicacin VB con el puerto serie. Parece en
principio que los puertos serie del PC se usan para muy pocas cosas. Prcticamente para
conectarnos a Internet a travs de un mdem telefnico. Existen muchsimas 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
imaginacin. Vuelva a la pgina 4 del captulo 2, y observe el panel de control de una radio
realizado en Visual Basic. La unin entre el PC y la radio, separados muchos kilmetros, se
realiz mediante el puerto COM, conectado a una lnea telefnica mediante un mdem. El
puerto COM es el gran olvido de los informticos
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 diseo. 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 botn derecho del ratn sobre el control y vamos a propiedades, nos
presenta tres cuadros de configuracin de los tpicos de los controles personalizados. Si
seleccionamos el control MSComm y pulsamos F4 , aparecer la caja de propiedades tpica de
los controles VB.

PRPIEDADES
Existen propiedades que pueden establecerse en tiempo de diseo o en tiempo de ejecucin, y
otras que solamente se pueden ejecutar o consultar en solamente en tiempo de ejecucin. Se
detallan a continuacin las primeras. Las segundas se enumerarn tras estas, aunque se
nombran algunas de estas ltimas al explicar cada una de las propiedades del primer tipo.
CommPort
Indica el nmero del puerto serie usado. Admite los valores de 1 a 255. Cambiando esa
propiedad podemos cambiar el puerto de comunicacin 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 nmero de puerto inexistente,
dar error.
Settings
Sintaxis

Velocidad, Paridad, Bits de informacin, Bits parada

Indica la velocidad, paridad, nmero de bits y bits de stop (parada) que se van a usar en la
comunicacin.
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 Gua del Estudiante

Cap. 20

Pg. 13

N - No enva bit de paridad ni hace comprobacin de paridad en la recepcin.

O - Enva y comprueba paridad, con el criterio de paridad IMPAR
E - Enva y comprueba paridad, con criterio de paridad PAR
Los valores para el parmetro Bits de Informacin pueden ser :
7 - Se envan / reciben 7 bits por trama de informacin.
8 - Se envan / reciben 8 bits por trama de informacin
5 - Se envan / reciben 5 bits por trama de informacin. Este valor de 5 bits es el tpico
del sistema Baudot para transmisin telegrfica
(Teletipos) que se ha conservado en
las comunicaciones informticas
por pura tradicin. Si se eligen 5 bits, los bits de parada
se ponen
automticamente a 1,5 (Tpico tambin del sistema Baudot.)
Los valores para el parmetro Bits de parada pueden ser :
1 - Se enva un bit de parada
2 - Se envan 2 bits de parada
(No es posible programar 1,5 bits de parada. Slo lo hace cuando se
bits de informacin y lo hace automticamente).

programan

Handshaking
Especifica el mtodo de control sobre el flujo de informacin. En una comunicacin serie se
necesita conocer si el puerto puede enviar informacin (necesita saber si el mdem est
preparado para recibirla) y necesita indicarle al mdem que l est preparado para recibir
informacin. A este proceso se le denomina Handshaking. (Handshaking = Control de Flujo)
(Como sabr por sus conocimientos de ingls, Handshaking significa apretn 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 seales auxiliares del
puerto (RTS, CTS, DSR, DTR), que son cables adicionales que tendrn una tensin positiva
respecto a los 0V del equipo si esa seal est activada, o una tensin negativa si no lo est.
Este tipo de control del flujo de informacin es el tpico para comunicarse el ordenador con un
mdem.
Existe otra forma de controlar el flujo de informacin : mediante seales especiales que se
envan por los dos cables que transportan la informacin. Mediante estas dos seales podemos
controlar que el ordenador enve informacin o deje de enviarla. De igual forma, podemos
indicarle al mdem que enve o no enve. Estas seales especiales se denominan X-ON y XOFF.
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 aplicacin.
InBufferSize
Mediante esta propiedad establecemos el tamao del Buffer (almacn de datos) de entrada.
Este Buffer sirve para poder recibir datos sin que tenga que intervenir la aplicacin
continuamente para controlar el puerto de entrada.

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 14

Puede conocerse el nmero de caracteres presentes en el Buffer de entrada consultando el

valor de la propiedad InBufferCount.
OutBufferSize
Mediante esta propiedad controlamos el tamao del Buffer de salida.
El tamao de los Buffers depender de la aplicacin y de la velocidad de comunicacin. Si la
aplicacin 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 nmero de caracteres presentes en el Buffer de salida (los que an estn
por transmitir), consultando el valor de la propiedad OutBufferCount.
RThreshold, SThreshold
Estas dos propiedades especifican el nmero de caracteres que deben estar presentes en los
Buffers de Recepcin y Transmisin respectivamente, para que se produzca el evento
OnComm relativo a recepcin y transmisin 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 aplicacin y del tiempo que
queramos que la aplicacin 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 mnimo), cada vez que reciba un carcter se producir el evento OnComm.
(Vea la descripcin de eventos mas adelante). Al producirse este evento, ejecutar el
procedimiento asociado a l, lo que har perder tiempo a la aplicacin, impidindole realizar
otras funciones. Si se pone un valor muy alto, el puerto no avisar que tiene caracteres
recibidos hasta que reciba un nmero igual al programado en esta propiedad, por lo que no
podremos procesar los datos recibidos hasta que el buffer tenga ese nmero de caracteres en
su interior. En nmero adecuado depender del tipo de aplicacin que vayamos a realizar. En
cualquier caso, este nmero ser inferior al nmero programado para la longitud del buffer,
(InBufferSize)
InputLen
Por defecto, cuando se lee el Buffer de recepcin, se leen todos los caracteres, quedando el
Buffer vaco. Si se le asigna a esta propiedad un valor distinto de 0, cada vez que leamos el
Buffer de recepcin leer un nmero de caracteres igual a esa cantidad, permaneciendo los
caracteres restantes en el Buffer a la espera de una nueva lectura. Asignndole el valor 0 (Valor
por defecto), el buffer se lee completo.
ParityReplace
Si la comunicacin se realiza con bit de paridad (Par o Impar), en recepcin se comprueba byte
a byte la recepcin de la paridad correcta. Si se recibe un Byte que no tiene paridad correcta, lo
mas probable es que ese Byte (carcter) se haya recibido defectuoso. Esta propiedad nos
permite sustituir un carcter que ha llegado con bit de paridad incorrecto por otro carcter. ( ?
predeterminado). Se puede sustituir por una cadena de caracteres (Error, por ejemplo).

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 15

NullDiscard
Cuando se recibe el carcter nulo (00000000) puede ser que no sirva para nada a efectos de
nuestra aplicacin, o que este carcter sea un dato mas. Esta propiedad acepta los valores
True / False. Si es True se desprecia el carcter Nulo. Si es False, se toma como un carcter
mas.
CTSTimeout
Es el tiempo (en milisegundos) que permanece esperando la seal CTS (Seal CTS Dispuesto para enviar), seal de entrada al ordenador que debe estar presente antes de que el
puerto comience a enviar informacin. El tiempo se mide desde que se pone activa la seal de
salida RTS (Peticin de envo). Si se supera este tiempo entre el instante de activacin de la
seal RTS y la recepcin de la seal 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 mximo de espera (en milisegundos) desde que se activa la seal DTR hasta que
se recibe la seal CD (Carrier Detect - Deteccin de portadora). Este tiempo solamente tendr
importancia en ciertas aplicaciones donde se espere recibir CD continuamente. No tendr
sentido cuando la aplicacin se queda en espera a recibir una comunicacin, 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 seal CD se espera la seal DSR. Esta
propiedad s tiene sentido, ya que si, por ejemplo, estamos conectados con un mdem, y
nuestra aplicacin se pone a la espera de recibir alguna llamada, activa la salida DTR, y espera
recibir inmediatamente la respuesta de que el mdem est dispuesto, mediante la lnea DSR.
Si transcurre el tiempo programado sin recibir la seal DSR se producir el evento DSRTO .
Ponindola a 0, se deshabilita esta propiedad y nunca ocurrir el evento DSRTO.
RTSEnable
Activa (Pone a 1) la seal RTS (Request To Send - Peticin de envo) Esta seal debe ponerse
a 1 para indicar al mdem (o al equipo que va a recibir nuestra comunicacin) que deseamos
enviar datos. Debe estar activada durante toda la transmisin 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 seal RTS, pues lo hace
automticamente 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 transmisin de datos por radio, donde podemos usar esta seal 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 seal
se emplea para decirle al mdem que el terminal (Ordenador) est preparado para recibir
datos.
Se hace la misma observacin que para la propiedad anterior respecto a los valores de la
propiedad Handshaking

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 16

Interval
Indica el tiempo (en milisegundos) del intervalo entre una y otra comprobacin del estado de
recepcin del puerto. El valor mnimo es de 55 ms.
El anlisis del puerto de comunicacin no tiene nada que ver con la generacin del evento
OnComm. Este evento se producir cuando se cumplan las condiciones para ello,
independientemente del tiempo programado en esta propiedad. La comprobacin del puerto
cada intervalo de tiempo marcado por esta propiedad solamente afecta a averiguar el estado
de las lneas auxiliares CD, DSR y CTS, y para saber el nmero de caracteres existentes en los
Buffers de transmisin y recepcin.
Las siguientes propiedades no difieren en nada respecto a otros controles :
Left, Name, Index, Top, Tag
Propiedades propias del tiempo de ejecucin
PortOpen
Abre el puerto de comunicacin. 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 nmero 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
Enva caracteres al Buffer de salida. Debe existir un signo igual ( = ) entre Output y lo que se
enva 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 Gua del Estudiante

Cap. 20

Pg. 17

Input
Lee el Buffer de recepcin. El nmero de caracteres ledos 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 nmero 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 diseo y es de slo
lectura en tiempo de ejecucin.
Sintaxis

NombredelMSComm.CommEvent

Break
Devuelve un valor (True / False) que indica que se ha recibido la seal Break.
variable = MSComm1.Break
CDHolding
Devuelve el estado de la lnea de control CD (Deteccin 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 lnea 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 lnea 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 cdigo apropiado en el procedimiento del MSComm ser
necesario analizar qu evento se ha producido y colocar, mediante una sentencia If .. Then el
cdigo 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 telfono). En esta sentencia

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 18

If Then deberemos colocar el cdigo necesario para que la aplicacin se prepare para
recibir una comunicacin a travs del mdem.
End If
Los eventos del Comm pueden identificarse por una constante o un nmero. La constante,
como todas las de Visual Basic, tiene una expresin bastante difcil. Se pone entre parntesis
el nmero que identifica a ese evento. Este nmero debe declararse como Integer.
Se ejecutar el Procedimiento OnComm cuando ocurra alguno de los siguientes eventos :
ComEvCD

(5)

Cambio en la lnea CD. Para conocer el estado actual de esa lnea

(Activado/Desactivado) deberemos invocar la propiedad CDHolding

ComEvCTS

(3)

Cambio en la lnea CTS. Igual que la anterior, este evento solamente

nos indica que ha existido un cambio. Para averiguar el estado en que
se encuentra esta lnea, debemos invocar la propiedad CTSHolding

ComEvDSR

(4)

Cambio en la lnea DSR. Igual que las anteriores. Debemos invocar la

propiedad DSRHolding para averiguar su estado actual.

ComEvRing

(6)

Cambio en la lnea de deteccin de llamada (Ring). Este evento se

produce cuando hay un cambio en la lnea Ring (Deteccin de
llamada en el mdem)
No existe una propiedad para averiguar el estado de la lnea Ring
pues no es necesario. Lo importante de esta lnea es que est
cambiando, es decir, el telfono est sonando y poco importa que
analicemos si la lnea Ring est a 1 o a 0, pues toda llamada
telefnica es intermitente. Dependiendo de la UART de su PC, puede
que este evento no lo soporte.

ComEvReceive( 2 )

Cuando se recibe un nmero igual o mayor de caracteres que el

indicado en la Propiedad RThreshold

ComEvSend

(1)

Cuando quedan en el bfer de transmisin menos caracteres que los

indicados en la Propiedad SThreshold

ComEvEOF

(7)

Recibido un carcter de fin de archivo (carcter ASCII 26) .

comEventBreak (1001)

Se ha recibido una seal de interrupcin. (Break)

ComEventCDTO (1007)
Tiempo de espera de Deteccin de portadora. La lnea
Deteccin de portadora (CD) estuvo baja durante el periodo de tiempo
especificado en la Propiedad CDTimeout, mientras se intentaba
transmitir un carcter.
ComEventCTSTO

1002 Tiempo de espera de Preparado para enviar. La lnea

Preparado para enviar (CTS) estuvo baja durante el periodo de tiempo
especificado en la propiedad CTSTimeout mientras se intentaba
transmitir un carcter.

ComEventDSRTO

1003 Tiempo de espera de Equipo de datos preparado. La lnea

Equipo de datos preparado (DSR) estuvo baja durante el periodo de
tiempo especificado en la Propiedad DSRTimeout mientras se
intentaba transmitir un carcter.

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 19

ComEventOverrun

1006 Se sobrepas la capacidad del Buffer de entrada sin haber

ledo todos los caracteres. Los caracteres no ledos se han perdido.
Debemos aprovechar este evento para solicitar al colateral una
repeticin de los datos perdidos.

ComEventRxOver

1008 Desbordamiento del bfer de recepcin. No hay espacio para

ms datos en el bfer de recepcin.

ComEventRxParity

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

paridad.

ComEventTxFull

1010 Bfer de transmisin lleno. El bfer de transmisin estaba

lleno cuando se ha intentado agregar un carcter a la cola de
transmisin. Este error es fcil 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

LSB

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

Visual Basic Gua del Estudiante

Cap. 20

Pg. 20

NOTA ADICIONAL

El puerto de comunicaciones.

El puerto de comunicaciones de un PC est formado por varias entradas / salidas. El soporte

fsico 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 distribucin de las seales en cada uno de sus pines es la siguiente :
GND

(Potencial de 0 V.).

TxD

Transmisin de datos. Es una salida del ordenador. Por ella salen los datos en serie.

RxD

Recepcin de datos. Es una entrada del ordenador. Por ella entran los datos en serie.

RTS

Request To Send. Peticin de envo. Es una salida del ordenador. El ordenador pone a
1 esta seal 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 mdem (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 mdem est encendido y listo para funcionar.

DCD o CD
Carrier Detect. Deteccin de portadora. Es una entrada del ordenador. Le
indica al ordenador que el mdem est detectado seal de audio (tonos) vlida.
DTR

Data Terminal Ready. Terminal de datos listo. Es una salida del ordenador. Indica que
est listo para trabajar. Suele emplearse para indicar al mdem que el ordenador est
dispuesto para recibir informacin.

Otra seal (disponible slo en los ordenadores que tengan conector de 25 pines, y no en todos)
es la seal RING (timbre del telfono) Es una entrada del ordenador. Le indica que est
sonando el timbre de la lnea telefnica del mdem.
Disposicin de los pines en el ordenador
Dependiendo de si tiene conector de 9 pines o de 25, la distribucin de estas seales
fsicamente en el conector es :
Conector de 9 pines
Pin
3
2
7
8
6
5
1
4

Conector de 25 pines
Seal
TxD
RxD
RTS
CTS
DSR
GND
CD
DTR
RING
Tierra de proteccin

Pin
2
3
4
5
6
7
8
20
22
1

(La seal RING no est disponible en el conector de 9 pines. La deteccin del Ring del
telfono se realiza directamente por la lnea RxD. El mdem enva la palabra RING cuando
suena el timbre del telfono. La tierra de proteccin tampoco se usa en este conector.

LSB

Visual Basic Gua del Estudiante

Cap. 20

Pg. 21