Visual Basic -Guía del Estudiante Cap. 20

Visual Basic - Guía del EstudianteCap. 20APLICACIONES CLIENTE SERVIDORCOMUNICACIÓN PUERTO SERIE: EL CONTROL MSCOMM

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

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

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

Pero lo que más se notaría sería la ocupación de los recursos de lared durante las consultas a esa base de datos. Dependiendo de cómo secrease el recordset, podría darse el caso de transmitir por la redtodos los datos de la base de datos para que nuestra aplicaciónutilice únicamente los datos correspondientes a un registro. Pensandoen una aplicación bancaria, por ejemplo la petición de saldo de unacuenta desde un cajero automático, los únicos datos relevantes de esaoperación serán el número de cuenta corriente, un código para indicarque lo que se desea es el saldo, y como datos de retorno, el número deesa cuenta, el saldo actual disponible y quizás un número decomprobación (Checksum) para comprobar que no ha existido error en lacomunicación. De nada nos serviría en el cajero conocer el estado decantidades retenidas, operaciones pendientes, etc.

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

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

file://MiServidor/BasesdeDatos/MiBase.Mdb

file://MiServidor/BasesdeDatos/MiBase.Mdb

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

La aplicación cliente – servidor más popular es el navegador deInternet. 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 paraque se comuniquen entre ellas es el protocolo Http o el Ftp. Estosprotocolos al ser públicos, permiten a cualquier empresa hacer supropia aplicación cliente o servidor.

No es nuestro deseo llegar a tanto. El navegador de Internet es unaaplicación cliente–servidor que sobrepasa cualquier proyecto quepodamos imaginar para realizarlo por medio de programación en VB.Cualquier navegador de Internet comercial lleva asociadas una serie defunciones, muchas de ellas transparentes para el usuario, que seríaimposible crear una aplicación de este calibre, sobre todo comoejemplo de un curso de VB. Pensemos en una 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ónnovísima del Listatel) cuya base de datos está en un servidorconectado a Internet, al que se podrá acceder desde un númeroilimitado de puestos cliente. En la base de datos del servidor, en unconjunto de tablas, figurarán los nombres, números de teléfono,despacho, etc. de una serie de personas, y el organigrama de esaspersonas dentro de la organización. Estas tablas serán estáticas, esdecir, tendrán datos que solamente se actualizarán cuando exista uncambio en esas personas, pero no variarán durante la ejecución delprograma. En otra tabla, esta dinámica, tendremos el registro de losusuarios que están conectados en ese momento al servicio. Así podremossaber si un usuario está presente y de esta forma conocer un datoimportante para otro servicio que va a tener este programa: sudirección IP actual. Sabiendo que está conectado y con su dirección IPpodremos enviarle mensajes directamente. Creo que ya vemos que setrata de una agenda telefónica que lleva incorporado un servicio demensajería. El servicio de mensajería enviará mensajes con texto planoo RTF y puede llevar ficheros anexados. A esta agenda, y a suprotocolo de comunicación le vamos a denominar SML. No se preocupe de


no conocer las siglas. Al protocolo SMTP tampoco lo conocían en elmomento de su creación.

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

Toda aplicación cliente - servidor debe tener un sistema decomunicació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 sercualquier otro sistema de comunicación entre ordenadores. Sin ir máslejos, a través del puerto de comunicación serie COM-1 ó COM-2. Aefectos de los programas de la aplicación cliente o servidor solamentevariará en la forma en la que reciban y transmitan los datos. Ennuestro ejemplo vamos a utilizar la comunicación a través de una redIP, usando el control Winsock ya estudiado. Tanto la aplicacióncliente como la aplicación servidor deberán tener un Winsock. Como ennuestro caso, según explicamos más atrás, la aplicación cliente seconvierte en aplicación servidor para recibir mensajes, ésta deberátener dos Winsocks, uno para la función cliente, y otro para lafunción servidor.

Cuando se diseña una aplicación cliente – servidor hay que comenzarpensando en las funciones que va a realizar y sobre esas funcionescomenzar a escribir el protocolo de comunicación. No es fácil tenerterminado el protocolo de comunicación antes de escribir la primeralínea de código del programa. Según se van concretando cada una de lasacciones que debe realizar vemos que es necesario introducir nuevoscódigos de operación en nuestro protocolo. No se preocupe que eso noes improvisar. Pero sí es muy importante tener las cosas claras desdeel principio y saber que es lo que va a hacer nuestra aplicación parade esta forma poder saber dar respuesta correcta a cada uno de los dosprogramas. Y para tener las cosas claras, el autor recomienda que elprotocolo de comunicación se establezca antes de comenzar a escribirel código en tanto se pueda. Y que se escriba en un documento en elpropio 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ónpara evitar de esta forma cualquier repetición involuntaria.

Es muy importante a la hora de pensar el protocolo de comunicación queeste no pueda inducir a error al programa. Si el programa tiene comofunción la transmisión de mensajes (Tal como es nuestro caso) losmensajes no pueden estar limitados ni en su longitud ni en sucontenido por el formato del protocolo de comunicaciones. Se entiendemejor esto analizando el protocolo del SML (fruto únicamente de la


imaginación del autor y no sujeto a normas ni recomendacionesinternacionales de ningún tipo)


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

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

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

Volvamos a lo comentado anteriormente respecto a la limitación delcontenido de un mensaje. Si el mensaje contiene un carácter <, > ó /puede que el programa se confunda y piense que ese carácter formaparte de un acrónimo. Para evitar cualquier confusión, si uno deestos 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 ahoraque ese mismo problema lo vamos a tener con el carácter &. Si queremosenviar ese carácter, sin que haya posibilidad de error pensando que setrata del carácter & antepuesto a cualquiera de los signos anteriores,deberemos poner delante de él también el signo &. Así, && significaque se está transmitiendo el signo &.

Es obvio pensar que esas tres combinaciones no pueden formar parte deningún acrónimo. Pero como los acrónimos los definimos nosotros, bastacon 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 elprotocolo de comunicación. No se preocupe por tener que irrectificándolo. Eso sí, mantenga siempre actualizado el documento obase de datos con el protocolo, explicando debidamente cada una de suspartes, los parámetros que lleva y la función que realiza. Esdocumento indispensable a la hora de distribuir la aplicación.

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


El protocolo de comunicación debe hacerse preferentemente en ASCIIpuro y caracteres que tengan representación física. Esto nos permitedepurar el programa analizando la comunicación mediante un programaexterno y debidamente probado. Utilizar caracteres sin representaciónASCII lo único que puede hacerle es complicarle la vida a Ud. y aquien analice su aplicación. Cuando se envíe una cifra, hágalo endecimal o en hexadecimal. Evite en lo posible enviar cifrassustituyendo su valor por su carácter equivalente. La mayoría de loscaracteres no los va a poder representar y tendrá serios problemaspara depurar su programa. Esto es especialmente importante con elcheksum de un mensaje, por ejemplo. Le recomiendo que usepreferentemente numeración Hexadecimal.

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

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

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

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


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

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

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

Los paquetes broadcast deben evitarse también. Solamente deben usarseen configuraciones donde no se conocen las direcciones de losservidores. Esto ocurre cuando la red tiene asignación dinámica dedirecciones. (Puede ocurrirle si usa una red VSAT) En cualquiercaso, los paquetes broadcast deben evitarse en lo posible. Losservidores 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 lafuncionalidad.

Dado que la aplicación cliente y la aplicación servidor soncompletamente independientes, es muy fácil realizar modificaciones enuna 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 hayanintroducido mejoras que puede aportar al cliente si este es capaz dereconocer un nuevo protocolo. Estamos en el caso de un servidor quedebe atender a dos versiones distintas de cliente. Si el clientetiene la versión mejorada, usará con él un protocolo de comunicaciónque permita las nuevas prestaciones. Si el cliente tiene la versiónmás antigua, deberá seguir usando con él el protocolo anterior.

Esto nos lleva a que el cliente siempre debe indicar al servidor suversión. Esto no ocupa unos recursos excesivos y puede ser muy útilcuando prevemos introducir una modificación. Esta práctica puedeincluso servir para conocer aquellos clientes a los que hay que


realizar el cambio de versión y enviarles una nueva. En el ejemplo deeste curso, el cliente comunica al servidor su versión en el acto deconectarse 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 alidentificarse el cliente y devolverle el servidor la conformidad delregistro, le devolviese también la versión del servidor. ¿Se dacuenta que según se avanza en la definición del protocolo aparecennuevas necesidades?

La aplicación cliente debe mostrar de forma clara al usuario el estadode conexión o desconexión con el servidor. Y a ser posible, queindique la causa de la no conexión (Fallo en la RAL, fallo en elservidor) Esta información se obtienen de forma muy sencillaanalizando los errores generados en el Winsock a la hora de realizarla conexión.

Cuando utilice el puerto COM para la comunicación, bien seadirectamente o a través de módem, debe indicar claramente al usuarioel 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óndirecta, cuando se use, el Host debe poner a 1 esta señal para podertrabajar). Recuerde que la comunicación por el puerto COM es asíncronarespecto a la ejecución del programa.

En el ejemplo de aplicación cliente – servidor se han ensayado tambiénlos controles avanzados de Visual Basic (Capitulo 16). La aplicacióntal como se dijo es una guía telefónica, que presenta en un TreeViewel 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, segundoapellido o combinación de ambos. Una vez encontrada la persona, secubren todos los datos de la misma, para presentarlos en la solapa dela guía propiamente dicha, y el dato de su alias (dato que define deforma única a cada usuario) aparece en la dirección de correo parapoder enviarle un mensaje. Para hacer una práctica con el puerto decomunicaciones COM-1 ó COM-2 utilizaremos un módem, conectado al PC através de uno de estos puertos, para marcar el número telefónico.

Todas las operaciones de búsqueda de datos las haremos medianteconsultas a la base de datos que está en el servidor. Las consultas serealizarán siguiendo el protocolo de comunicaciones. El organigrama seguardará en el cliente, en una base de datos, para evitar en loposible el envío desde el servidor. La razón para esto es que elorganigrama puede ser muy extenso, y no va a variar muy a menudo. Comoesta información habría que enviarla nada más conectarse el cliente, ycomo puede ser bastante amplia, esto podría originar un tráficointenso por la red, que es justamente lo que queríamos evitar.Solamente se va a enviar cuando haya cambiado. ¿Cómo sabe el clienteque 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 elcliente envíe cada vez que se registra (al comienzo de la conexión) elnombre de la revisión del organigrama que tienen. El nombre puede sercualquiera. Lo que hace el servidor por defecto para poner el nombre ala revisión es combinar una cadena de texto con el nombre de laorganización seguido de la fecha (día/mes/año) en la que se realiza larevisión. De esta forma es imposible que haya dos fichero con el mismonombre. 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 unainstrucción para que el cliente solicite al servidor que le envíe lanueva revisión. El cliente la solicita y el servidor se la envía. Yal recibirla, el cliente reemplaza el contenido de la base de datospor los nuevos valores recibidos.

Y razonando los procedimientos de esta misma forma, vamos completandoel mecanismo de comunicación entre cliente y servidor, y paralelamentecreando el protocolo de comunicación. Por eso es muy probable que elprotocolo de comunicación no esté acabado hasta que esté acabada laaplicació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 continuaampliación. Esto es lo bonito de los programas ejemplo de los cursos de visual basic.



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

PROTOCOLO DE COMUNICACIÓN CLIENTE – SERVIDOR

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

En cualquier caso, el contenido de las órdenes y comandos de esteprotocolo será siempre en ASCII, con caracteres alfanuméricos quepermitan ver perfectamente el tráfico entre ambos interlocutores. Elhecho de utilizar solamente caracteres legibles asegura igualmente lacomunicación a través de cualquier medio de telecomunicación,incluyendo dispositivos de cifrado on-line colocados entre cliente yservidor.

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

OrdenesRespuestasConfirmacionesAvisos

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

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

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

Avisos: Son aquellas comunicaciones que no ejecutan ninguna acción enel colateral, pero informan de algo. Por ejemplo, servidor fuera deservicio temporalmente, servidor restablecido. Pueden serindividuales, en cuyo caso generarán normalmente una confirmación, obroadcast, 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 queindicará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 deestos componentes irá metido entra los símbolos < > y su longitudpuede 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 elservidor.<IPO/10.3.22.119> Dirección IP del equipo origen<IPD/217.126.179.96> Dirección IP del equipo destino<QRY/Select * From Agenda_Personal Where Apellido1 Like ‘FERN%’>

Si hubiese que emplear los símbolos /, &, < o > como símbolos de lainformació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 todoslos caracteres de los componentes de la trama, exceptuando loscorrespondientes precisamente a este cheksum y al fin de trama. Elcheksum 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 biendebe ir en primer lugar el acrónimo que inicie la sesión decomunicaciones, en penúltimo lugar el cheksum, y en último lugar el<EOT>

Una trama puede contener varias ordenes siempre y cuando estas seancongruentes.

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

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

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

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


<LIC> Login Cliente. Indica que el cliente desea hacer Login enese 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 eseservidor. Pasa como parámetros el alias y el password (enclaro o cifrado) del cliente.

<ALC> Alias de cliente. Llevará como dato el alias de esecliente.

<ALS> Alias de servidor. Llevará como dato el alias de eseservidor.

<PWC> Password del cliente. Lleva como parámetro el password (enclaro o encriptado) del cliente

<IPO> IP de la máquina origen. Llevará como dato el número IP dela máquina origen de la trama.

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

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

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

<NSO> Nombre Servidor origen. Llevará como dato el nombre delservidor origen. Este nombre de servidor será el nombre deun programa servidor, no el nombre de la máquina donde sealberga 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 quenecesite esa consulta para su ejecución.

<RQY> Resultado de la consulta a la base de datos. Llevará comodatos el resultado de esa consulta. Si el resultado generavarios registros, cada uno de ellos irá entre brackets( [ ] )

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

<QIR> Consulta los datos del correo de un usuario pasándole eneste 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 ladirección de correo SMTP. Devuelve los datos con elacró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 enun 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 elcaso 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 cifredoblemente con la clave privada del remitente y la clavepublica del destino, en cuyo caso se envían como dosparámetros<CRY/INI/PUB_LUIS.RODRIGUEZ/PRI_JOSE.LOPEZ>Si el inicio no llevase parámetros de clave, el servidorentenderá que se cifra con la clave asignada en el servidoral 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 esecliente.

<UCC> Usuario Cliente Conectado. Se devuelve cuando un clienterecibe una solicitud de conexión. Es equivalente al RHC delservidor.

<MN_> Información del mensaje. Número de mensaje. Es una cadenade caracteres generada por el origen, para definir elmensaje enviado. Consiste en una cadena de 4 caracteresprogramable por el usuario, seguida de un número que indicael año, mes, día, hora, minuto y segundo del envío, todosellos de dos dígitos. (abcdyymmddhhnnss)

<FR_> Origen del mensaje (From) Lleva como parámetro la direcciónSML 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 laque se está enviando el mensaje. Lleva como parámetro ladirección SML o SMTP del destino.

<SJ_> Información del mensaje. Indica el Asunto (Subjet) delmensaje. Lleva como parámetro el contenido del asunto.

<NX_> Información del mensaje. Indica el nombre del ficheroAnexado enviado en el mensaje. Puede haber varios anexosdentro de un mismo mensaje, en este caso se enviarán varios


grupos <NX_>. Lleva como parámetro el nombre del fichero enel origen y el tamaño (en bytes) del fichero.

<CX_> Cheksum del fichero anexado. Lleva como parámetro 8 bytescon el cheksum en Hexadecimal. (El cheksum son 32 bits –4bytes- 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. Elprimer carácter del anexo debe transmitirse inmediatamentedespués de este acrónimo.

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

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

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

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

<SAR> Solicitado acuse de recibo. Puede llevar como parámetro unadirección de correo SML o SMTP que será en este caso aquien enviará acuse de recibo del mensaje. Si no llevaningún parámetro enviará el acuse de recibo al origen delmensaje. El acuse de recibo implica solamente que se harecibido el mensaje correctamente en el destino, pero noindica que se haya leído.

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

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

Una máquina puede identificarse bien por su dirección IP o por sunombre dentro de una red. Puede también identificarse por ambos, enaquellas situaciones en las que la máquina receptora del mensaje debaretransmitirlo 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 tieneasignado un número IP verdadero, y en esa red existen varias máquinasque cada una de ellas tendrá un nombre distinto, y un número IPdistinto, (número IP que para estas máquinas será ya de la numeracióninterna) Al poder identificar una máquina por su IP y nombre, bastacon poner como IP de destino el numero IP real del módem ADSL, y comonombre, 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áquinaAdministracion_1 que está en la red de área local cuyo acceso desdeInternet se realiza por un módem ADSL cuyo número IP es el217.126.179.96. Lógicamente, la máquina real que recibe estacomunicación no es la máquina Administracion_1, sino otra máquinacolocada en la misma red de área local, sobre la cual se ha hecho NATdesde 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_1que será quien lo trate. Si la comunicación no llevase más que elnúmero IP, se entiende que el destino es la máquina que tiene esenúmero IP.

ORDENES PREPROGRAMADAS

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

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

departamento. Se le pasa como parámetro el ID de esedepartamento (Campo Ag_Departamento_ID)

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

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

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

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


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

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

<ABF> Pide todos los datos de los abonados con el mismo primerapellido (Búsqueda aproximada por la derecha) y segundoapellido (Búsqueda aproximada por la derecha). Se pasancomo parámetros los apellidos a buscar, o las cadenas decaracteres por las que hará la búsqueda. Devuelve los datoscon 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 primerapellido (Búsqueda aproximada por la derecha) Se pasa comoparámetro el nombre y apellido a buscar, o las cadenas decaracteres por la que hará la búsqueda. Devuelve los datoscon el acrónimo <ABL>

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



EL CONTROL PERSONALIZADO MICROSOFT COMM

Este control permite la comunicación de una aplicación VB con el puerto serie. Parece enprincipio que los puertos serie del PC se usan para muy pocas cosas. Prácticamente paraconectarnos a Internet a través de un módem telefónico. Existen muchísimas aplicacionesindustriales para las cuales son fundamentales los puertos COM. Las redes de área local pareceque 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 enVisual Basic. La unión entre el PC y la radio, separados muchos kilómetros, se realizó medianteel puerto COM, conectado a una línea telefónica mediante un módem. El puerto COM es elgran olvido de los informáticos…

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

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

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

PRPIEDADES

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

CommPort Indica el número del puerto serie usado. Admite los valores de 1 a255. Cambiando esa propiedad podemos cambiar el puerto de comunicaciónque vamos a usar (Un PC tiene normalmente 2 puertos serie : El Com1 yel Com2. Puede tener sin grandes problemas Hardware hasta 4 (Com3 yCom4) 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 enbaudios.

50 100 110 300 600 1200 2400 4800 960014400 19200 y 28800

Los valores posibles para paridad son :

N - No envía bit de paridad ni hace comprobación de paridad enla recepción.

O - Envía y comprueba paridad, con el criterio de paridad IMPARE - Envía y comprueba paridad, con criterio de paridad PAR

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

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

valor de 5 bits es el típico del sistema Baudot para transmisióntelegráfica (Teletipos) que se ha conservado en lascomunicaciones 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 delsistema Baudot.)

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

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

(No es posible programar 1,5 bits de parada. Sólo lo hace cuandose 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 unacomunicación serie se necesita conocer si el puerto puede enviarinformación (necesita saber si el módem está preparado para recibirla)y necesita indicarle al módem que él está preparado para recibirinformación. A este proceso se le denomina Handshaking. (Handshaking= Control de Flujo)(Como sabrá por sus conocimientos de inglés, Handshaking significaapretón de manos, ponerse de acuerdo. Y ponerse de acuerdo entre dosterminales que van a comunicarse es establecer las condiciones decontrol que uno va a tener sobre otro.)


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

Existe otra forma de controlar el flujo de información : medianteseñales especiales que se envían por los dos cables que transportan lainformación. Mediante estas dos señales podemos controlar que elordenador 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ñalesespeciales se denominan X-ON y X-OFF.

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

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

Send (CTS)3 - Control de Flujo mediante XON - XOFF y RTS - CTS

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

InBufferSize

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

Puede conocerse el número de caracteres presentes en el Buffer deentrada 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 velocidadde comunicación. Si la aplicación tiene muchas cosas que hacer, apartede controlar el puerto de comunicaciones, se deberá poner un Buffergrande. Tanto mas grande cuanta mayor sea la velocidad detransferencia de datos.

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

RThreshold, SThreshold


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

El valor que se debe dar a estas dos propiedades depende de laaplicación y del tiempo que queramos que la aplicación está atendiendoal puerto de comunicaciones. Concretamente para la propiedadRThreshold debemos pensar muy bien el valor que se le pone. Si ponemosun valor corto (1 es el mínimo), cada vez que reciba un carácter seproducirá el evento OnComm. (Vea la descripción de eventos masadelante). Al producirse este evento, ejecutará el procedimientoasociado a él, lo que hará perder tiempo a la aplicación, impidiéndolerealizar otras funciones. Si se pone un valor muy alto, el puerto noavisará que tiene caracteres recibidos hasta que reciba un númeroigual al programado en esta propiedad, por lo que no podremos procesarlos datos recibidos hasta que el buffer tenga ese número de caracteresen su interior. En número adecuado dependerá del tipo de aplicaciónque vayamos a realizar. En cualquier caso, este número será inferioral número programado para la longitud del buffer, (InBufferSize)

InputLen

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

ParityReplace

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

NullDiscard

Cuando se recibe el carácter nulo (00000000) puede ser que no sirva


para nada a efectos de nuestra aplicación, o que este carácter sea undato mas. Esta propiedad acepta los valores True / False. Si es Truese desprecia el carácter Nulo. Si es False, se toma como un caráctermas.

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 quedebe estar presente antes de que el puerto comience a enviarinformación. El tiempo se mide desde que se pone activa la señal desalida RTS (Petición de envío). Si se supera este tiempo entre elinstante 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, sedeshabilita, y en estas condiciones no se producirá nunca el eventoCTSTO.

CDTimeout

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

DSRTimeout

Similar a la anterior, pero en vez de esperar la señal CD se espera laseñ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 laespera de recibir alguna llamada, activa la salida DTR, y esperarecibir inmediatamente la respuesta de que el módem está dispuesto,mediante la línea DSR. Si transcurre el tiempo programado sin recibirla señal DSR se producirá el evento DSRTO . Poniéndola a 0, sedeshabilita 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 vaa recibir nuestra comunicación) que deseamos enviar datos. Debe estaractivada 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 preocuparnosde poner a 1 la señal RTS, pues lo hace automáticamente el puerto de


comunicaciones. Esta propiedad está ahí para aplicaciones donde no seemplee ese tipo de Handshaking y necesitemos activar algo antes detransmitir. (Caso por ejemplo de transmisión de datos por radio, dondepodemos 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 deDatos Listo). Esta señal se emplea para decirle al módem que elterminal (Ordenador) está preparado para recibir datos.

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

Interval

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

El análisis del puerto de comunicación no tiene nada que ver con lageneración del evento OnComm. Este evento se producirá cuando secumplan las condiciones para ello, independientemente del tiempoprogramado en esta propiedad. La comprobación del puerto cadaintervalo de tiempo marcado por esta propiedad solamente afecta aaveriguar el estado de las líneas auxiliares CD, DSR y CTS, y parasaber el número de caracteres existentes en los Buffers de transmisióny recepción.

Las siguientes propiedades no difieren en nada respecto a otroscontroles :

Left, Name, Index, Top, Tag

Propiedades propias del tiempo de ejecución

PortOpen

Abre el puerto de comunicación. Puede tener los valores True (Paraabrirlo) 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 deentrada. Con el mismo MSComm anterior, comprobaremos el número decaracteres sin leer con la sentencia :

caracteressinleer = MSComm1.InBufferCount

OutBufferCount

Nos permite conocer cuantos caracteres quedan por transmitir en elBuffer 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 fraseCurso de Visual Basic ejecutaremos la sentencia :

MSComm1.Output = “Curso de Visual Basic”

Si deseamos enviar el contenido de una variable

MSComm1.Output = variable

Input

Lee el Buffer de recepción. El número de caracteres leídos dependerádel valor de la propiedad InputLen. Cuando la propiedad InputLen tieneel valor 0, el Buffer se lee completo. Si InputLen tiene un valordistinto de 0, se leerá un número de caracteres igual al valor de estapropiedad. CommEvent Devuelve el evento mas reciente que ha ocurrido para generar el eventogeneral OnComm (Vea mas adelante). Esta propiedad no está disponible entiempo 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 laseñ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 esTrue, 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 : elProcedimiento OnComm. Este procedimiento se ejecuta cada vez que seproduce alguno de los eventos del MSComm.Esto quiere decir que para escribir el código apropiado en elprocedimiento del MSComm será necesario analizar qué evento se haproducido y colocar, mediante una sentencia If .. Then el códigoapropiado para cada uno de los eventos que se produzcan.

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

If MsComm1.CommEvent = ComEvRing Then

'Se ha consultado si el evento particular que ha producido elevento general OnComm

'ha sido el ComEvRing (Se está recibiendo la llamada delteléfono). En esta sentencia

‘If Then deberemos colocar el código necesario para que laaplicació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 unnúmero. La constante, como todas las de Visual Basic, tiene unaexpresión bastante difícil. Se pone entre paréntesis el número queidentifica a ese evento. Este número debe declararse como Integer.

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

ComEvCD ( 5 ) Cambio en la línea CD. Para conocer el estadoactual de esa línea

(Activado/Desactivado) deberemos invocar la propiedadCDHolding

ComEvCTS ( 3 ) Cambio en la línea CTS. Igual que la anterior, esteevento solamente

nos indica que ha existido un cambio. Para averiguarel estado en que

se encuentra esta línea, debemos invocar lapropiedad 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 Ringpues no es necesario. Lo importante de esta línea es

que está cambiando, es decir, el teléfono está sonando y poco

importa que analicemos si la línea Ring está a 1 o a 0, pues

toda llamada telefónica es intermitente. Dependiendo de la UARTde su PC, puede que este evento no lo soporte.

ComEvReceive( 2 ) Cuando se recibe un número igual o mayor decaracteres que el

indicado en la Propiedad RThreshold

ComEvSend ( 1 ) Cuando quedan en el búfer de transmisión menoscaracteres que los

indicados en la Propiedad SThreshold

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


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

ComEventCDTO (1007) Tiempo de espera de Detección de portadora. Lalínea

Detección de portadora (CD) estuvo baja durante elperiodo de tiempo

especificado en la Propiedad CDTimeout, mientras seintentaba transmitir un carácter.

ComEventCTSTO 1002 Tiempo de espera de Preparado para enviar. Lalínea

Preparado para enviar (CTS) estuvo baja durante elperiodo de tiempo

especificado en la propiedad CTSTimeout mientras seintentaba

transmitir un carácter.

ComEventDSRTO 1003 Tiempo de espera de Equipo de datos preparado.La línea

Equipo de datos preparado (DSR) estuvo baja duranteel periodo de

tiempo especificado en la Propiedad DSRTimeoutmientras se

intentaba transmitir un carácter.

ComEventOverrun 1006 Se sobrepasó la capacidad del Buffer de entradasin haber

leído todos los caracteres. Los caracteres noleídos se han perdido.

Debemos aprovechar este evento para solicitar alcolateral una

repetición de los datos perdidos.

ComEventRxOver 1008 Desbordamiento del búfer de recepción. No hayespacio para

más datos en el búfer de recepción.

ComEventRxParity 1009 Error de paridad. El hardware ha detectado unerror de

paridad.

ComEventTxFull 1010 Búfer de transmisión lleno. El búfer detransmisión estaba

lleno cuando se ha intentado agregar un carácter ala 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 decontrol de

dispositivos (DCB) para el puerto.

ComEventFrame 1004 Error de trama. El hardware ha detectado unerror de trama.


NOTA ADICIONAL El puerto de comunicaciones.

El puerto de comunicaciones de un PC está formado por variasentradas / salidas. El soporte físico es un conector tipo Sub-D de 9 ó25 contactos, macho en ambas versiones. Se necesita por tanto un cablecon 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 lasiguiente :

GND (Potencial de 0 V.).

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

RxD Recepción de datos. Es una entrada del ordenador. Por ellaentran 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 delordenador. Si está a 1

significa que el ordenador puede enviar datos pues el módem (oel dispositivo que

vaya a recibirlos) está preparado para hacerlo.

DSR Data Set Ready. Dispositivo de datos preparado. Es una entradadel 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 delordenador. 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 delordenador. Indica que

está listo para trabajar. Suele emplearse para indicar al módemque el ordenador está

dispuesto para recibir información.

Otra señal (disponible sólo en los ordenadores que tengan conector de25 pines, y no en todos) es la señal RING (timbre del teléfono) Es unaentrada del ordenador. Le indica que está sonando el timbre de lalí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ónde estas señales físicamente en el conector es :

Conector de 9 pines Conector de 25 pines

Pin Señal Pin

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

RING 22Tierra de protección 1

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


Documents

Visual Basic -Guía del Estudiante Cap. 20