Capitulo 20 Visual Basic

Visual Basic - Guía del Estudiante Cap. 20 APLICACIONES CLIENTE SERVIDOR COMUNICACIÓN PUERTO PUERTO SERIE: EL CONTROL CONTROL MSCOMM MSCOMM (Capítulo inacabado. ¿Algún estudiante quiere colaborar a su terminación?) Hasta ahora hemos visto aplicaciones que pueden utilizarse por sí solas. Pueden acceder a bases de datos que estén en el mismo ordenador que la aplicación o en otro, unido mediante una red de área local. local. La conexión a las bases bases de datos a las que accede accede se realiza, realiza, bien indicándole la dirección y carpeta (\\MiServidor\BasesdeDatos\MiBase.Mdb ( \\MiServidor\BasesdeDatos\MiBase.Mdb)) o bien “mapeando” esa direcci dirección ón (crear una unidad unidad de disco que contiene contienen n esa direcci dirección) ón).. De esta forma podemos acceder a una base de datos instalada en un equipo remoto y la aplicación debe funcionar perfectamente, aunque al abrir o leer la base de datos origine un tráfico elevado por la red de área local. Con esta configuración configuración podemos tener problemas de lentitud, sobre todo si la red es lenta y si hay muchos usuarios trabajando con esa aplicación en distintos ordenadores, accediendo todos ellos a través de la red a un servidor que contienen la base de datos. Esta lentitud se incrementaría en una gran escala si la red a utilizar fuese Internet mediante una conexión lenta. Pero lo que más se notaría sería la ocupación de los recursos de la red durante las consultas a esa base de datos. Dependiendo de cómo se crease el recordset, podría darse el caso de transmitir por la red todos los datos de la base de datos para que nuestra aplicación utilice únicamente únicamente los datos correspondientes correspondientes a un registro. Pensando Pensando en una aplicación aplicación bancaria, bancaria, por ejemplo la petición de saldo de una cuenta desde un cajero automático, los únicos datos relevantes de esa operación serán el número de cuenta corriente, un código para indicar que lo que se desea es el saldo, y como datos de retorno, el número de esa cuenta, el saldo actual disponible y quizás un número de comprobación (Checksum) para comprobar que no ha existido existido error en la comunicació comunicación. n. De nada nos serviría serviría en el cajero conocer conocer el estado estado de cantidades retenidas, operaciones pendientes, etc. Si en ese ejemplo del cajero creásemos un objeto Database, un recordset, leyésemos todos los datos del recordset y luego diésemos la orden de cerrarlo, estaríamos enviando información innecesaria a través de la red, con el coste de tiempo y ocupación que ello representa. Casi Casi llegam llegamos os a demost demostrar rar con esta esta introd introducc ucción ión que sería sería más conven convenien iente te hacer hacer una aplicación aplicación que tuviese tuviese dos partes: una, residente residente en el puesto de operación, operación, (que llamaremos aplicación cliente) que fuese capaz de enviar datos solicitando información a otra aplicación, instalada en el servidor donde está la base de datos. Esta segunda aplicación, que llamaremos aplicación servidor, abrirá la base, creará los recordsets necesarios, filtrará la información, realizará realizará con ella operaciones operaciones matemáticas, matemáticas, y una vez concluido todo el proceso, proceso, enviará a la aplicación cliente los datos estrictamente necesarios. Obviamente se necesita que ambas aplicaciones sean capaces de entenderse entre sí, es decir, que tengan un protocolo de comunicación entre ellas previamente definido. Esto es lo que se denomina una aplicación cliente – servidor. La aplicación cliente cliente – servidor más popular popular es el navegador navegador de Internet. Internet. Esta aplicación aplicación está formada por una aplicación cliente (Navegador IEXplore, NetScape, etc) y una aplicación servidor (Internet Information Server IIS, Apache, etc). El protocolo para que se comuniquen entre ellas es el protocolo Http o el Ftp. Estos protocolos al ser públicos, permiten a cualquier empresa hacer su propia aplicación cliente o servidor. No es nuestro deseo llegar a tanto. El navegador de Internet es una aplicación cliente–servidor que sobrepa sobrepasa sa cualqu cualquier ier proyect proyecto o que podamos podamos imaginar imaginar para para realiz realizarl arlo o por medio medio de programación en VB. Cualquier navegador de Internet Internet comercial lleva asociadas asociadas una serie de funciones, muchas de ellas transparentes para el usuario, que sería imposible crear una aplicación de este calibre, sobre todo como ejemplo de un curso de VB. Pensemos en una

LSB

Visual Basic Guía del Estudiante

Cap. 20

Pág. 1

aplicación más sencilla, que nos permita conocer como funcionan las aplicaciones cliente – servidor, y sirva además para algo útil. Esa aplicación aplicación no puede ser otra que una guía telefónica, telefónica, (versión novísima del Listatel) cuya base de datos está en un servidor conectado a Internet, al que se podrá acceder desde un número ilimitado de puestos cliente. En la base de datos del servidor, en un conjunto de tablas, figurarán los nombres, números de teléfono, despacho, etc. de una serie de personas, y el organigrama de esas personas dentro de la organización. Estas tablas serán estáticas, es decir, tendrán datos que solamente se actualizarán cuando exista un cambio en esas personas, pero no variarán durante la ejecución del programa. En otra tabla, esta dinámica, tendremos el registro de los usuarios que están conectados en ese momento al servicio. Así podremos saber si un usuario usuario está presente y de esta forma conocer un dato importante para otro servicio que va a tener este programa: su dirección IP actual. Sabiendo que está conectado y con su dirección IP podremos enviarle mensajes directamente. Creo que ya vemos que se trata de una agenda telefónica que lleva incorporado un servicio de mensajería. El servicio de mensajería enviará mensajes con texto plano o RTF y puede llevar ficheros anexados. A esta agenda, y a su protocolo de comunicación le vamos a denominar SML. No se preocupe preocupe de no conocer conocer las siglas. Al protocolo SMTP tampoco lo conocían en el momento de su creación. Una aplicación cliente puede comportarse como aplicación servidor de otra aplicación, incluso de sí misma. Este es el caso de la aplicación cliente del SML. Cuando vamos a pedir la información de un abonado telefónico al servidor, el cliente se comporta como tal. Sin embargo cuando otro usuario de SML nos envía un mensaje, es nuestra aplicación la que realiza las funciones de servidor. Verá esto con mucha más claridad cuando comencemos el ejemplo. Toda aplicación cliente - servidor debe tener un sistema de comunicación entre la aplicación cliente y la aplicación servidor. servidor. Parece que la comunicación que ha de tener es a través de una red IP (Red de Area Local, Red Privada Virtual, Internet) pero puede ser cualquier otro sistema de comunicación entre ordenadores. Sin ir más lejos, a través del puerto de comunicación serie COM-1 ó COM-2. A efectos de los programas de la aplicación cliente o servidor solamente variará en la forma forma en la que reciban reciban y transmitan los los datos. En nuestro nuestro ejemplo vamos vamos a utilizar la comunicación a través de una red IP, usando el control Winsock ya estudiado. Tanto la aplicación cliente como la aplicación servidor deberán tener un Winsock. Como en nuestro caso, según explicamos más atrás, la aplicación cliente se convierte en aplicación servidor para recibir mensajes, ésta deberá tener dos Winsocks, uno para la función cliente, y otro para la función servidor. Cuando se diseña una aplicación cliente – servidor hay que comenzar pensando en las funciones que va a realizar y sobre esas funciones comenzar a escribir el protocolo de comunicación. No es fácil tener terminado el protocolo de comunicación antes de escribir la primera línea de código del programa. Según se van concretando cada una de las acciones que debe realizar vemos que es necesario introducir introducir nuevos códigos de operación operación en nuestro nuestro protocolo. protocolo. No se preocupe que eso no es improvisar improvisar.. Pero sí es muy importante importante tener las cosas claras desde el principio y saber que es lo que va a hacer nuestra aplicación para de esta forma poder saber dar respuesta correcta a cada uno de los dos programas. Y para tener las cosas claras, el autor recomienda que el protocolo de comunicación se establezca antes de comenzar a escribir el código en tanto se pueda. Y que se escriba en un documento en el propio ordenador o mejor aún, en una base de datos u hoja de cálculo, que nos permita ordena ordenarr las órdenes órdenes y avisos avisos de nuestra nuestra aplicac aplicación ión para evitar evitar de esta esta forma forma cualquier cualquier repetición involuntaria. Es muy importante a la hora de pensar el protocolo de comunicación que este no pueda inducir a error al programa. Si el programa tiene como función función la transmisión transmisión de mensajes (Tal (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 del SML (frut fruto o únic únicam amen ente te de la imagi magina naci ción ón del del auto autorr y no sujet ujeto o a norm normas as ni recomendaciones internacionales de ningún tipo)

LSB


Cap. 20

Pág. 2

Protocolo de comunicación de la aplicación SML. (Vea el ANEXO ANEXO 1 Protocolo de comunicación SML) La comunicación entre ambas aplicaciones se establece mediante palabras en ASCI que indica indican n una operac operación ión.. A estas estas palabr palabras as las denomin denominamos amos Acrónimos. Las operaci operacione oness pued pueden en ser ser órde órdene ness o avis avisos os.. Son Son órden órdenes es aquel aquella lass comu comuni nica caci cion ones es del del clie client nte e que que desencadenan una operación en el servidor. servidor. Son avisos aquellas respuestas del servidor para enviarle enviarle datos o comunicar comunicar algo al cliente. Cada orden orden o aviso, puede llevar llevar uno o varios parámetros. parámetros. Los parámetros parámetros contienen la información necesaria necesaria para que la operación operación que se va a realizar por esa orden o aviso pueda llevarse a cabo. En esta aplicación SML los acróni acrónimos mos todos todos son de 3 caractere caracteres, s, utilizan utilizando do los signos signos < > como como delimita delimitadore doress del acróni acrónimo. mo. Si el acróni acrónimo mo lleva lleva paráme parámetros tros,, la separac separación ión entre entre los tres caract caractere eress y el parámetro o parámetros es la barra / Volvamos a lo comentado anteriormente respecto a la limitación del contenido de un mensaje. Si el mensaje contiene un carácter <, > ó / puede que el programa se confunda y piense que ese carácter carácter forma parte de un acrónimo. Para evitar cualquier cualquier confusión, confusión, si uno de estos caracteres forma parte de un texto, se le antepondrá el signo &. &. De esta forma la recepción de la pareja de caracteres &<, &> ó &/ significa que no son parte de un acrónimo sino texto. Observe ahora que ese mismo problema lo vamos a tener con el carácter &. Si queremos enviar ese carácter, sin que haya posibilidad de error pensando que se trata del carácter & antepuesto a cualquiera de los signos anteriores, deberemos poner delante de él también el signo &. Así, && significa que se está transmitiendo el signo &. Es obvio pensar que esas tres combinaciones no pueden formar parte de ningún acrónimo. Pero como los acrónimos los definimos nosotros, basta con hacer que ninguno contenga esas secuencias de caracteres. Preocúpese de estos detalles que son los realmente importantes. Verá cuando se ponga a escribir código que siempre ha de faltar algo en el protocolo de comunicación. No se preocupe por tener que ir rectificándo rectificándolo. lo. Eso sí, mantenga siempre actualizado actualizado el documento documento o base de datos con el protocolo, explicando debidamente cada una de sus partes, los parámetros que lleva y la función que realiza. Es documento indispensable a la hora de distribuir la aplicación. A modo de recordator recordatorio, io, los protocolo protocolos s de comunicaci comunicación ón de las aplicaci aplicacione ones s cliente – servidor para Internet se encuentran en las RFCs, (Request For Coments) son públicas, y han tardado en desarrollarse varios años a base de continuas aportaciones y correcciones por parte de sus creadores de todo el mundo mundial. Basta con que teclee RFC en un buen buscador y le llevará a muchas páginas donde puede ver todas las recomendaciones para todos los servicios de Internet.

El protocolo de comunicación debe hacerse preferentemente en ASCII puro y caracteres que tengan representación física. Esto nos permite depurar el programa analizando la comunicación mediante un programa externo externo y debidamente probado. Utilizar caracteres sin representación ASCII lo único que puede hacerle es complicarle la vida a Ud. y a quien analice su aplicación. Cuando se envíe una cifra, hágalo en decimal o en hexadecimal. Evite en lo posible enviar cifras sustituyendo su valor por su carácter equivalente. La mayoría de los caracteres no los va a pode poderr repr repres esen enta tarr y tend tendrá rá seri serios os prob proble lema mass para para depu depura rarr su prog progra rama ma.. Esto Esto es especialmente importante con el cheksum de un mensaje, por ejemplo. Le recomiendo que use preferentemente numeración Hexadecimal. Un buen programador nunca oculta el protocolo de comunicación. Esto permite que otros mejoren su aplicación. Sólo los programadores mediocres temen que se les plagie. Y por supuesto supuesto,, nadie nadie debería debería aceptar aceptar una aplicaci aplicación ón cliente cliente – servidor servidor si el programa programador dor no suministra ese protocolo.

LSB


Cap. 20

Pág. 3

Asp spec ecto toss qu quee de debe be tene tenerr siem siempr pree en cu cuen enta ta cu cuan ando do dise diseñe ñe un unaa aplicación cliente – servidor. Si como como es norm normal al,, util utiliz iza a una una red red IP para para la tran transm smis isió ión n de infor informa maci ción ón entr entre e ambas ambas aplica aplicacio ciones, nes, deberá deberá poner un Winsoc Winsockk en la aplica aplicació ción n client cliente, e, que deberá deberá conoce conocerr la dirección dirección IP o el DNS de la aplicación servidor servidor,, y el puerto en el que está escuchando. escuchando. En el servidor deberá poner un Winsock que estará siempre a la escucha en el puerto determinado para la aplicación, y atenderá a todas las llamadas que reciba creando una instancia de ese Winsoc Winsock. k. Creará una instan instancia cia para cada cada comuni comunicac cación ión entrante entrante desde los client clientes. es. La comunicación en el servidor se mantendrá abierta hasta que el cliente la cierre. Solamente en circunstancias excepcionales, cerrará la comunicación el servidor. Por ejemplo, en aquellos casos en los que pase un tiempo predeterminado sin recibir ni enviar ningún dato al cliente. Para eso se utilizará una tecnología muy sencilla, denominada Watch Dog consistente en un contador que se pone a cero cada vez que se recibe o se envían datos al cliente. Ese contador incrementa su cuenta en una unidad cada cierto tiempo. Si llega a un número predeterminado, prueba evidente evidente de que ha pasado un tiempo tiempo sin que reciba ni envíe informaci información, ón, cierra la conexión conexión del Winsock Winsock asociado. De cualquier forma hay que tener cuidado y pensar muy bien lo que se hace antes de cerrar la comunicación desde el servidor. El programa cliente debe conocer el número IP o dirección dirección DNS del servidor servidor.. Pero el servidor no tiene porque conocer la dirección ni DNS del cliente, ya que debe ser el cliente el que inicie siempre la comunicación. Al cliente nunca se le le debe forzar el puerto en el que emite (Propiedad LocalPort del Winsock). El servidor contestará siempre al cliente usando la conexión abierta por éste, es decir, usando la instancia de su Winsock correspondiente a la conexión realizada para ese cliente) Normalmente el servidor no podrá comunicar directamente con el cliente, ya que el cliente no está a la escucha. Solamente en algunas aplicaciones se le dota al cliente de otro Winsock para que sea este segundo Winsock quien esté a la escucha de una posible llamada del servidor servidor. Esto se emplea para dar una batida por todos los clientes clientes (Hacer Pooling) Pooling) y ver los clientes que están conectados en este momento. Solamente lo he visto en algunas aplicaciones de seguridad. Generalmente este pooling se sustituye por llamadas periódicas desde cada cliente para indicarle al servidor que están activos. La comunicación comunicación entre cliente cliente y servidor debe debe ser siempre TCP. TCP. El uso de UDP simplifica simplifica mucho las comunicaciones, pero no sirve para salir a Internet, donde las tramas UDP son generalmente eliminadas por los servidores. Vale más trabajar un poco más el código y trabajar con comunicaciones comunicaciones seguras seguras aunque sea en una red de área local que garantice la llegada de UDP. Los paquetes broadcast deben evitarse también. Solamente deben usarse en configuraciones donde no se conocen las direcciones de los servidores. Esto ocurre cuando la red tiene asignación dinámica de direcciones. (Puede ocurrirle si usa una red VSAT) VSAT) En cualquier caso, los paquetes broadcast deben evitarse en lo posible. Los servidores de Internet los eliminan automáticamente. Posiblemente Posiblemente haya más recomendaciones recomendaciones relativas relativas a la comunicación. comunicación. Veamos ahora otras recomendaciones acerca del código y de la funcionalidad. Dado que la aplicación cliente y la aplicación aplicación servidor son completament completamente e independient independientes, es, es muy fácil realizar modificaciones en una de ellas, sobre todo en el servidor, sin que el cliente se entere. Basta para ello mantener invariable el protocolo de comunicación. Pero puede llegar el caso en el que al servidor se le hayan introducido mejoras que puede aportar al cliente si este es capaz de reconocer un nuevo protocolo. Estamos en el caso de un servidor servidor que debe atender a dos versiones versiones distintas distintas de cliente. Si el cliente tiene tiene la versión mejorada, usará con él un protocolo de comunicación que permita las nuevas prestaciones. Si el cliente tiene la versión más antigua, deberá seguir usando con él el protocolo anterior.

LSB


Cap. 20

Pág. 4

Esto nos lleva a que el cliente siempre debe indicar al servidor su versión. Esto no ocupa unos recursos excesivos y puede ser muy útil cuando prevemos introducir una modificación. Esta práctica puede incluso servir para conocer aquellos clientes a los que hay que realizar el cambio de versión versión y enviarles una nueva. nueva. En el ejemplo de este curso, curso, el cliente comunica comunica al servidor su versión en el acto de conectarse mediante el acrónimo . El servidor también debería enviar su versión al cliente. cliente. No está previsto en la aplicación aplicación SML pero pero confie confieso so que no sobrarí sobraría a que al identi identific ficarse arse el client cliente e y devolve devolverle rle el servid servidor or la conformidad conformidad del registro, registro, le devolviese también también la versión del servidor. servidor. ¿Se da cuenta que según se avanza en la definición del protocolo aparecen nuevas necesidades? La apli aplica caci ción ón clie client nte e debe debe most mostrar rar de form forma a clara clara al usua usuari rio o el estad estado o de cone conexi xión ón o desconexión con el servidor. Y a ser posible, que indique la causa de la no conexión (Fallo en la RAL, fallo en el servidor) Esta información se obtienen de forma muy sencilla analizando los errores generados en el Winsock a la hora de realizar la conexión. Cuando utilice el puerto COM para la comunicación, bien sea directamente o a través de módem, debe indicar indicar claramente claramente al usuario el estado de esa conexión, conexión, analizando analizando la señal DSR (esta señal está activa cuando el módem está conectado, y en caso de comunicación directa, directa, cuando se use, el Host debe poner a 1 esta señal para poder trabajar). trabajar). Recuerde que la comunicación por el puerto COM es asíncrona respecto a la ejecución del programa. En el ejem ejempl plo o de apli aplica caci ción ón clie client nte e – serv servid idor or se han han ensa ensaya yado do tambi también én los los cont control roles es avanzados de Visual Basic (Capitulo 16). La aplicación tal como se dijo es una guía telefónica, que presenta en un TreeView TreeView el organigrama organigrama del Organismo o empresa a la que pertenece pertenece la guía. Esto facilita la búsqueda de una persona, haciéndolo por departamento. La guía permite también buscar por nombre, primer apellido, segundo apellido apellido o combinación de ambos. Una vez encontrada la persona, se cubren todos los datos de la misma, para presentarlos en la solapa de la guía propiamente dicha, y el dato de su alias (dato que define de forma única a cada usuario) usuario) aparece en la dirección dirección de correo para poder enviarle un mensaje. mensaje. Para hacer una práctica con el puerto de comunicaciones COM-1 ó COM-2 utilizaremos un módem, conectado al PC a través de uno de estos puertos, para marcar el número telefónico. Todas las operaciones de búsqueda de datos las haremos mediante consultas a la base de dato datoss que que está está en el serv servid idor or.. Las Las cons consul ulta tass se real realiz izará arán n sigu siguie iendo ndo el prot protoc ocol olo o de comunicaciones. El organigrama se guardará en el cliente, en una base de datos, para evitar en lo posible el envío desde el servidor. La razón para esto es que el organigrama puede ser muy extenso, y no va a variar muy a menudo. Como esta información habría que enviarla nada más conectarse el cliente, y como puede ser bastante amplia, esto podría originar un tráfico intenso por la red, que es justamente lo que queríamos evitar. Solamente se va a enviar cuando haya cambiado. ¿Cómo sabe el cliente que ha cambiado?. ¿Cómo sabe el servidor que el cliente tiene ya la información actualizada? La idea más sencilla para conocerlo es que el cliente envíe cada vez que se registra (al comienzo de la conexión) el nombre de la revisión del organigrama organigrama que tienen. El nombre puede ser cualquiera. cualquiera. Lo que hace el servidor servidor por defecto defecto para poner el nombre a la revisión es combinar una cadena de texto con el nombre de la organización organización seguido seguido de la fecha (día/mes/año) (día/mes/año) en la que se realiza la revisión. De esta forma es imposible imposible que haya dos fichero con el mismo nombre. Al recibir recibir ese nombre el servidor, servidor, si es igual al de la última revisión, le devuelve un OK. Si no es igual, le devuelve una instrucción para que el cliente solicite solicite al servidor que le envíe la nueva revisión. El cliente la solicita solicita y el servidor se la envía. Y al recibirla, el cliente reemplaza el contenido de la base de datos por los nuevos valores recibidos. Y razonando los procedimientos de esta misma forma, vamos completando el mecanismo de comunicación entre cliente y servidor, y paralelamente creando el protocolo de comunicación. Por eso es muy probable que el protocolo de comunicación no esté acabado hasta que esté acabada la aplicación. Al día de hoy (30 de Octubre de 2002) no está terminada la aplicación. Posiblemente no lo esté nunca porque sea una aplicación en continua continua ampliación. Esto es lo bonito de los programas ejemplo de los cursos de visual basic.

LSB


Cap. 20

Pág. 5

LSB


Cap. 20

Pág. 6

ANEXO 1 SERVIDOR DE BASES DE DATOS Y MENSAJERIA LISTATEL (SML) PROTOCOLO DE COMUNICACIÓN CLIENTE – SERVIDOR La comunicación entre cliente y servidor se realizará mediante el protocolo descrito más adelante, a través de cualquier medio de comunicación. Generalmente será comunicación a través de red IP, pero esto no debe impedir que los clientes se puedan conectar al servidor a través de otros medios de comunicación, como puede ser un módem telefónico o un enlace vía satélite. En cualquier caso, el contenido de las órdenes y comandos de este protocolo será siempre en ASCII, con caracteres alfanuméricos que permitan ver perfectamente el tráfico entre ambos interl interlocu ocutor tores. es. El hecho hecho de utiliz utilizar ar solame solamente nte caract caractere eress legibl legibles es asegura asegura igualm igualmente ente la comunicación a través de cualquier medio de telecomunicación, incluyendo dispositivos de cifrado on-line colocados entre cliente y servidor. La comunicación puede iniciarse tanto en el servidor como en cualquiera de los clientes. Una comunicación puede estar compuesta de: Ordenes Respuestas Confirmaciones Avisos

Ordenes: Son aquellas partes de la comunicación que inician una operación en el equipo colateral. Respuestas. Son siempre respuesta a una orden, y contendrán el resultado de la operación generada por la orden, o en su defecto, la notificación de que esa orden no ha sido ejecutada o que dio resultado nulo. Son el recon reconoc ocim imie ient nto o de recep recepci ción ón de una una comu comuni nica caci ción ón.. Pued Pueden en Confirmaciones: Son emplearse tanto para responder a un aviso como para confirmar que una orden se ha recibido, y que está siendo tratada. También pueden existir confirmaciones para avisar que una orden o una respuesta no ha llegado en un tiempo determinado.

Avisos: Son aquellas comunicaciones que no ejecutan ninguna acción en el colateral, pero informan de algo. Por ejemplo, servidor fuera de servicio temporalmente, servidor restablecido. Pueden ser individuales, en cuyo caso generarán normalmente una confirmación, o broadcast, en cuyo caso no generarán confirmación. Formato de las tramas de comunicaciones. La trama de una comunicación estará compuesta de unos acrónimos que indicarán la orden, respuesta, confirmación o aviso que envían, dirección IP, IP, nombre de la máquina o nombre del servidor que envía, dirección IP, nombre de la máquina o nombre del servidor destino, datos, cheksum de la trama y acrónimo de fin de trama. Cada uno de estos componentes irá metido entra los símbolos < > y su longitud longitud puede ser variable. variable. Cuando se envíe información, esta se colocará detrás del acrónimo que la define, separada por la barra /. Ejemplos: Servidor Atención. Inicia una sesión de un cliente con el servidor. servidor. Dirección IP del equipo origen > Dirección Dirección IP del del equipo equipo destino

LSB


Cap. 20

Pág. 7

Si hubiese hubiese que emplear los símbolos símbolos /, &, < o > como símbolos de la informaci información, ón, deberá anteponerse a cada uno de ellos el símbolo &. Por ejemplo: 25> El cheksum será el resultado de realizar la función XOR sobre todos los caracteres de los componentes de la trama, exceptuando los correspondientes precisamente a este cheksum y al fin fin de tram trama. a. El cheksu cheksum m se indica indicará rá en deci decima mal,l, con el acrón acrónim imo o CHK. CHK. Por Por ejem ejempl plo, o, El acrónimo de fin de trama será El orden de los componentes de una trama no debe ser estricto, si bien debe ir en primer lugar el acrónimo que inicie la sesión de comunicaciones, en penúltimo lugar el cheksum, y en último lugar el Una trama puede contener varias ordenes siempre y cuando estas sean congruentes.

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

LSB

Remote Hos Host Con Conect ectado ado. Lo dev devuelv elve el serv serviidor o un cli cliente cua cuando ndo otr otro equipo se conecta a él. Servi rvidor AT ATención. Inicia una sesión de comunicación desde el cl cliente nte al servidor. Cliente Atención. Inicia una sesión de comunicación desde una máquina (Servidor o cliente) a una máquina cliente. Logi ogin Cl Cliente nte. Indica qu que el el cl cliente de desea ha hacer Log Logiin en en es ese se servidor. or. Pa Pasa como parámetros el alias y el password (en claro o cifrado) del cliente. LogO LogOut ut de clie client nte. e. Ese Ese cli clien ente te quie quiere re hace hacerr Log LogOu Outt de de ese ese serv servid idor or.. Pas Pasa a com como o parámetros el alias y el password (en claro o cifrado) del cliente. Alias de de cl cliente nte. Ll Lleva evará co como da dato el el al alias de de es ese cl cliente. Alias lias de serv servid idor or.. Llev Llevar ará á como como dat dato el alia aliass de ese ese serv servid idor or.. Password del cliente. Lleva como parámetro el password (en claro o encriptado) del cliente IP de de la la máq máqui uin na ori orige gen. n. Llev Llevar ará á com como o dat dato o el el núm númer ero o IP IP de la máqu máquiina orig origen en de la trama. IP de de la má máquina des destino. Lle Llevará com como dat dato el nú número IP de de la la máq máquina destino. Nomb Nombre re máqu máquin ina a ori orige gen. n. Llev Llevar ará á com como o dat dato o el el nom nombr bre e de de la la máq máqui uina na dent dentro ro de la red. Nombr ombre e máqu máquin ina a dest destin ino. o. Lle Lleva vará rá com como o dato dato el el nomb nombre re de de la la máqu máquin ina a dent dentro ro de la red. Nomb Nombre re Serv Servid idor or orig origen en.. Lle Lleva vará rá como como dato dato el nomb nombre re del del ser servi vido dorr ori orige gen. n. Este Este nombre de servidor será el nombre de un programa servidor, no el nombre de la máquina donde se alberga el programa servidor. Nombre servidor destino. Igual que el anterior. Consulta a un una ba base de de da datos. Llev Llevar ará á co como dat datos la la co consulta co completa en en SQL Cons Consul ulta ta ya prep prepro rogr gram amad ada a en en el el serv servid idor or.. Lle Lleva va como como pará paráme metr tro o el el nom nombr bre e de de esa consulta, y los datos que necesite esa consulta para su ejecución. Resul esulta tado do de de la la cons consul ulta ta a la la base base de de dato datos. s. Lle Lleva vará rá co como dat datos os el el res resul ulta tado do de esa consulta. Si el resultado genera varios registros, cada uno de ellos irá entre brackets ( [ ] ) Consu onsult lta a de de los los datos atos del del cor corre reo o de de un un usu usuar ario io.. Env Envía ía como omo par parám ámet etro ro el Alia Aliass del usuario del que se quieren conocer los datos. Devuelve los datos con el acrónimo


Cap. 20

Pág. 8

Consulta los los dat datos del del cor correo de un us usuario pasándole en est este cas caso com como parámetro parámetro la dirección dirección de correo SML. Devuelve Devuelve los datos con el acrónimo acrónimo Consulta los los dat datos del del corr corre eo de un un usu usuario pas pasándole la di direc rección de de cor correo SMTP. SMTP. Devuelve los datos d atos con el acrónimo Orden de env envíío del del mis mismo dat dato en la la res respuesta a esa esa ord orden. Se Se env envía, por 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 em emplea pa para dev devol olvver el mi mismo dato rec reciibido con Inicia Inicia o finaliza finaliza una operación operación de cifrado cifrado de datos. Lleva como parámetro parámetro INI para para inic inicia iarr y FIN FIN para para term termin inar ar.. En el caso caso de inic iniciar iar,, llev lleva a uno uno o dos dos parámetros más, el número de clave o el nombre de un usuario con clave asoc asocia iada da.. Pued Puede e llev llevar ar dos dos nomb nombre ress de usua usuari rio o en caso caso que que se cifr cifre e doblemente con la clave privada del remitente y la clave publica del destino, en cuyo caso se envían como dos parámetros Si el inicio no llevase parámetros de clave, el servidor entenderá que se cifra con la clave asignada en el servidor al usuario que envía

...

Datos iniciales. es. Son da datos que se se envían entre ap aplicaci acione ones para ara su su in inicializació ción. Va Van de del 0 al 9 . Pu Pueden us usarse rse en en am ambos sentidos. Preferentemente, DI5 como contestación a DI0, DI6 como contestación a DI1, etc.

> >

Mensaje dirigido a todos los clientes Mensaje di dirigido a todos lo los se servidores Mens Mensaj aje e dir dirig igid ido o a todo todoss los los equi equipo poss (Cli (Clien ente tess y serv servid idor ores es)) Versión de del pro prog grama cl cliente. Se en envía al al re registrars arse. Soli Solici cita ta la vers versió ión n de de sof softw twar are e del del serv servid idor or.. Dev Devue uelv lve e la la ver versi sión ón del del sof softw twar are e del del servidor. Busca usca IP. IP. Se Se us usa par para a com compr prob obar ar que que un un cli clien ente te está está disp dispon onib ible le actu actual alme ment nte e en en la red. No lleva parámetros. Es la re respuesta del del cli cliente a la lla llamada Lle Lleva com como par parámetro la dirección SML o el nombre del usuario de ese cliente. Usua Usuari rio o Cli Clien ente te Cone Conect ctad ado. o. Se devu devuel elve ve cuan cuando do un clie client nte e rec recib ibe e una una soli solici citu tud d de conexión. Es equivalente al RHC del servidor. Infor nforma maci ción ón del del mens mensaj aje. e. Núme Número ro de de men mensa sajje. Es Es una una cade caden na de car carac acte tere ress generada por el origen, para definir el mensaje enviado. Consiste en una cadena de 4 caracteres programable por el usuario, seguida de un número que indica el año, mes, día, hora, minuto y segundo del envío, todos ellos de dos dígitos. (abcdyymmddhhnnss) Orig Origen en del del mens mensaj aje e (Fro (From) m) Llev Lleva a como como pará paráme metr tro o la dire direcc cció ión n SML SML del del orig origen en.. Dirección IP de desde la qu que se en envía el me mensaje. Es si similar a per pero solamente se utiliza al enviar un correo. Infor nforma maci ción ón del del men mensa saje je.. Ind Indic ica a dir direc ecci ción ón de de cor corre reo o a la la que que se se est está á env envia iand ndo o el mensaje. Lleva como parámetro la dirección SML o SMTP del destino. Informa rmación del del men mensaje. Ind Indica el As Asunto (Su (Subjet) del del men mensaje. Llev Lleva a com como parámetro el contenido del asunto. Infor nforma maci ción ón del del men mensa saje je.. Ind Indiica el el nom nombr bre e del del fic fiche hero ro Anexa nexado do env envia iado do en el el mensaje. Puede haber varios anexos dentro de un mismo mensaje, en este caso se enviarán varios grupos . Lleva como parámetro el nombre del fichero en el origen y el tamaño (en bytes) del fichero. Cheks heksum um del fich ficher ero o ane anexa xado do.. Ll Lleva eva com como o par parám ámet etro ro 8 byt bytes es con el cheks heksum um en Hexa Hexade deci cima mal. l. (El (El chek cheksu sum m son son 32 bits bits –4 byte bytess- expr expres esad ados os en hexadecimal. Si no envía cheksum, estos 8 bytes se sustituyen por la cadena YYYYZZZZ. Comi Comien enza za la tran transm smis isió ión n del del anex anexo. o. No llev lleva a par parám ámet etro ros. s. El prim primer er cará caráct cter er del del anexo debe transmitirse inmediatamente después de este acrónimo.

> >

> > >

>

>

LSB


Cap. 20

Pág. 9

>

>

Termina la transmisión del anexo. Este acrónimo debe enviarse inmediatamente después del ultimo carácter del anexo. Cuerp uerpo o del del mens mensaj aje e env envia iado do com como o text texto. o. Lle Lleva va com como o pará paráme metr tro o el tex texto to del del mensaje. cheks heksum um del del men mensa saje je.. Se Se env envía ía cuan cuando do se se sol solic icit ita a acu acuse se de rece recepc pció ión n o de de lectura, para comprobar la exactitud de la transmisión. Se usa también para devolver el cheksum del mensaje al origen en la confirmación de recibo o lectur lectura. a. Lleva Lleva como parámetr parámetro o los dos bytes del checsum checsum codific codificado adoss en hexadecimal (4 caracteres). Infor nforma maci ción ón del del men mensa saje je.. Ind Indic ica a que que el cont conten enid ido o del del men menssaje aje est está á en en for forma mato to RTF RTF. Puede Puede no llevar llevar ningún ningún parámetr parámetro, o, en cuyo cuyo caso indica indica que todo el cuerpo del mensaje está en formato RTF, o llevar le parámetro INI para indicar que comienza el formato RTF y FIN para indicar que termina. Afecta solamente al cuerpo del mensaje enviado con Solicitado acuse de rec recibo. Pu Puede llevar evar com como o par parámetro una dir direcc ección de correo SML o SMTP que será en este caso a quien enviará acuse de recibo del mensaje. Si no lleva ningún parámetro enviará el acuse de recibo al origen del mensaje. El acuse de recibo implica solamente que se ha recibido el mensaje correctamente en el destino, pero no indica que se haya leído. Solic olicit itad ado o Avi Aviso so de de Lect Lectur ura. a. Pue Puede de lle lleva varr como como par parám ámet etro ro una una di direcc recciión SML SML o SMTP que será en este caso a quien se envíe el aviso de lectura del mensaje. Si no lleva parámetro se le enviará al origen del mensaje. Este aviso de lectura indica solamente que se ha abierto el mensaje, pero no puede asegurar que el usuario destino lo haya leído. Fin del del men mensaje aje. Ind Indica que que se ha ha tra transmitido tod todo el me mensaje con con tod todos los los anex anexos os.. En caso caso de una trans transmi misi sión ón de mensa mensaje jess múlti múltipl ples es,, lleva lleva como como parámetro el número del mensaje que termina. En caso de mensaje único no lleva ningún parámetro o puede llevar el número del mensaje.

Una máquina puede identificarse bien por su dirección IP o por su nombre dentro de una red. Puede Puede tambié también n identi identific ficarse arse por ambos, ambos, en aquell aquellas as situaci situaciones ones en las que la máquin máquina a receptora del mensaje deba retransmitirlo a otra máquina. Este es el caso, por ejemplo, de una red conectada a través de una conexión conexión ADSL. El módem ADSL tiene asignado asignado un número IP verdadero, y en esa red existen varias máquinas que cada una de ellas tendrá un nombre distinto, y un número IP distinto, (número IP que para estas máquinas será ya de la numeración interna) Al poder identificar una máquina por su IP y nombre, basta con poner como IP de destino el numero IP real del módem ADSL, y como nombre, el nombre de la máquina dentro de la red privada. Por ejemplo: Este mensaje devuelve el resultado de una consulta a la máquina Administracion_1 que está en la red de área local cuyo acceso desde Internet se realiza por un módem ADSL cuyo número IP es el 217.126.179.96. 217.126.179.96. Lógicamente, Lógicamente, la máquina máquina real que recibe esta comunicación comunicación no es la máquina Administracion_1, sino otra máquina colocada en la misma red de área local, sobre la cual se ha hecho NAT desde Internet para el puerto que use este sistema, y esta máquina, una vez recibido el mensaje, lo reenvía a la máquina Administracion_1 que será quien lo trate. Si la comunicación no llevase más que el número IP, se entiende que el destino es la máquina que tiene ese número IP. ORDENES PREPROGRAMADAS Las órdenes preprogramadas son aquellas que el servidor ya tienen programadas en su código. Deben ir necesariamente tras el acrónimo ya que en caso contrario no serán tratadas.

LSB


Cap. 20

Pág. 10

LSB

Pide / dev devu uelve lve el el or organigra grama. No lllleva má más par pará ámetros Pide devuelve el nombre t Teléfono 1 de los abonados de un departamento. Se le pasa como parámetro el ID de ese departamento (Campo Ag_Departamento_ID) Pide / devu devuel elve ve todo todoss los los dato datoss de de un un abo abona nado do.. Lle Lleva va como omo par parám ámet etro ro el ID de ese abonado. Pide / de devuelve lve to todos los los dat datos de de los los ab abonados dos de de un de departamen mento. Se Se le le pasa como parámetro el ID del departamento. Pide tod todos los los dat datos de lo los abo abonados de un un des despacho. Se le le pas pasa com como parámetro el número de despacho. Los datos se devuelven con el acrónimo Pide todos los dat datos de los abonados que tienen un determinado nombre (Búsqueda aproximada por ambos lados) Se pasa como parámetro el nombre por el que se quiere buscar, buscar, o las letras del nombre por el que se va a realizar realizar búsqueda aproximada. Devuelve los datos con el acrónimo Pide todos datos de los abonados con un determinado primer apellido (Búsqueda aproximada por la derecha) Se pasa como parámetro el apellido a buscar, o la cadena de caracteres por la que hará la búsqueda. Devuelve los datos con el acrónimo Pide todo todoss los los datos atos de los los abo abona nado doss con con un dete determ rmiinado nado segu segund ndo o ape apelllido lido.. (Búsqueda aproximada por la derecha) Se pasa como parámetro el apellido a buscar, o la cadena de caracteres por la que hará la búsqueda. Devuelve los datos con el acrónimo Pide tod todos os los los dat datos os de los abon abonad ados os con con el mism mismo o pri prime merr ape apelllido lido (B (Búsqu úsqued eda a aproximada por la derecha) y segundo apellido (Búsqueda aproximada por la derecha). Se pasan como parámetros los apellidos a buscar, o las cadenas de caracteres por las que hará la búsqueda. Devuelve los datos con el acrónimo Pide tod todos los los dat datos de los abo abonados con el mis mismo nombre (Bú (Búsqueda apro aproxi xima mada da por los los dos dos lado lados) s) y el mism mismo o prim primer er apel apellilido do (Bús (Búsqu queda eda aproximada por la derecha) Se pasa como parámetro el nombre y apellido a buscar, o las cadenas de caracteres por la que hará la búsqueda. Devuelve los datos con el acrónimo Igual qu que el el an anterior rior,, co con no nombre bre y segu egundo ap apellido.


Cap. 20

Pág. 11

LSB


Cap. 20

Pág. 12

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

El control MSComm no está normalmente en la caja de herramientas, por lo que será necesario introducirlo mediante Proyecto | Componentes. En el formulario solamente solamente se le ve en tiempo de diseño. El icono que lo representa representa en la caja de herramientas coincide con el que presenta en el formulario:

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

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

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

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

Indica la velocidad, paridad, número de bits y bits de stop (parada) que se van a usar en la comunicación. Los valores posibles para velocidad son : Indica la velocidad en baudios. 50

100 110 300 600 1200 2400 4800

9600 14400

19200 y 28800

Los valores posibles para paridad son :

LSB


Cap. 20

Pág. 13

N - No envía bit de paridad ni hace comprobación de paridad en la recepción. O - Envía y comprueba paridad, con el criterio de paridad IMPAR IMPAR E - Envía y comprueba paridad, con criterio de paridad PAR PAR Los valores para el parámetro Bits de Información pueden ser : 7 - Se envían / reciben 7 bits por trama de información. 8 - Se envían / reciben 8 bits por trama de información 5 - Se envían / reciben 5 bits por trama de información. Este valor de 5 bits es el típico del sistema sistema Baudot para transmisión transmisión telegráfica telegráfica (Teletip (Teletipos) os) que se ha conservado conservado en las comunicaciones informáticas por pura tradición. Si se eligen 5 bits, los bits de parada se ponen automáticamente a 1,5 (Típico también del sistema Baudot.) Los valores para el parámetro Bits de parada pueden ser : 1 - Se envía un bit de parada 2 - Se envían 2 bits de parada (No es posible programar programar 1,5 bits de parada. Sólo lo hace cuando se bits de información y lo hace automáticamente).

programan programan

5

Handshaking Especifica el método de control sobre el flujo de información. En una comunicación serie se necesita conocer si el puerto puede enviar información (necesita saber si el módem está preparado para recibirla) y necesita indicarle al módem que él está preparado para recibir información. A este proceso se le denomina Handshaking. (Handshaking = Control de Flujo) (Como (Como sabrá sabrá por sus conoci conocimie mientos ntos de inglés inglés,, Handsh Handshaki aking ng signif significa ica apretó apretón n de manos, manos, ponerse de acuerdo. Y ponerse de acuerdo entre dos terminales que van a comunicarse es establecer las condiciones de control que uno va a tener sobre otro.) El Control de Flujo puede hacerse de dos formas : Una mediante las señales auxiliares del puerto (RTS, CTS, DSR, DTR), que son cables adicionales que tendrán una tensión positiva respecto a los 0V del equipo si esa señal está activada, o una tensión negativa si no lo está. Este tipo de control del flujo de información es el típico para comunicarse el ordenador con un módem. Existe otra forma de controlar el flujo de información : mediante señales especiales que se envían por los dos cables que transportan la información. Mediante estas dos señales podemos controlar controlar que el ordenador envíe informació información n o deje de enviarla. enviarla. De igual forma, podemos podemos indicarle al módem que envíe o no envíe. Estas Estas señales especiales se denominan X-ON y XOFF. La propiedad propiedad Handshaking contro controla la la forma forma de realiza realizarr este este proces proceso. o. Puede Puede tomar tomar los siguientes valores : 0 - No existe Control de Flujo 1 - Control de Flujo mediante XON - XOFF 2 - Control de Flujo mediante Request To To Send (RTS) y Clear To To Send (CTS) 3 - Control de Flujo mediante XON - XOFF y RTS - CTS Los tres tipos de Control de Flujo tiene cada uno su aplicación.

InBufferSize Mediante esta propiedad establecemos el tamaño del Buffer (almacén de datos) de entrada. Este Este Buff Buffer er sirve sirve para para pode poderr reci recibir bir datos datos sin sin que que tenga tenga que inte interve rveni nirr la apli aplica caci ción ón continuamente para controlar el puerto de entrada. LSB


Cap. 20

Pág. 14

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

OutBufferSize Mediante esta propiedad controlamos el tamaño del Buffer de salida. El tamaño de los Buffers dependerá dependerá de la aplicación aplicación y de la velocidad velocidad de comunicación comunicación.. Si la aplicación tiene muchas cosas que hacer, aparte de controlar el puerto de comunicaciones, se debe deberá rá pone ponerr un Buff Buffer er gran grande de.. Tanto anto mas mas gran grande de cuan cuanta ta mayo mayorr sea sea la velo veloci cida dad d de transferencia de datos. Puede conocerse el número de caracteres presentes en el Buffer de salida (los que aún están por transmitir), consultando el valor de la propiedad OutBufferCount.

RThreshold, SThreshold Estas dos propiedades especifican el número de caracteres que deben estar presentes en los Buffer Bufferss de Recepc Recepción ión y Trans Transmis misión ión respect respectivam ivament ente, e, para que se produzc produzca a el evento evento OnComm relativo a recepción y transmisión de caracteres. (Eventos EvReceive y EvSend) Si el valo valorr de una una de esta estass prop propie ieda dade dess está está a 0, no se prod produc uce e el even evento to OnComm correspondiente. El valor que se debe dar a estas dos propiedades depende de la aplicación y del tiempo que queramos que la aplicación está atendiendo al puerto de comunicaciones. Concretamente para la propiedad propiedad RThreshold debemos pensar muy bien el valor que se le pone. Si ponemos un valor corto (1 es el mínimo), cada vez que reciba un carácter se producirá el evento OnComm . (Vea (Vea la desc descri ripc pció ión n de event eventos os mas adel adelan ante te). ). Al prod produc ucir irse se este este even evento to,, ejec ejecut utar ará á el procedimiento asociado a él, lo que hará perder tiempo a la aplicación, impidiéndole realizar otras otras funcione funciones. s. Si se pone pone un valor valor muy alto, alto, el puerto puerto no avisará avisará que tiene tiene caractere caracteress recibidos hasta que reciba un número igual al programado en esta propiedad, por lo que no podremos procesar los datos recibidos hasta que el buffer tenga ese número de caracteres en su interior. En número adecuado dependerá del tipo de aplicación que vayamos a realizar. En cualquier caso, este número será inferior al número programado para la longitud del buffer, (InBufferSize)

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

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

LSB


Cap. 20

Pág. 15

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

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

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

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

RTSEnable Activa (Pone a 1) la señal RTS (Request To Send - Petición de envío) Esta señal debe ponerse a 1 para indicar al módem (o al equipo que va a recibir nuestra comunicación) que deseamos enviar datos. Debe estar activada durante toda la transmisión de datos. Cuando se pone la propiedad Handshaking a 2 (control con RTS / CTS) ó 3 (Control con RTS / CTS y con X-ON / X-OFF) no debemos preocuparnos de poner a 1 la señal RTS, pues lo hace automáticamente el puerto de comunicaciones. Esta propiedad está ahí para aplicaciones donde no se emplee ese tipo de Handshaking y necesitemos activar algo antes de transmitir. (Caso por ejemplo de transmisión de datos por radio, donde podemos usar esta señal de salida para activar el PTT (Push To Talk - Pulse para hablar) y poner el transmisor en marcha)

DTREnable Activa (Pone a 1) la salida DTR (Data Terminal Terminal Ready - Terminal de Datos Listo). Esta señal se emplea para decirle al módem que el terminal (Ordenador) está preparado para recibir datos. Se hace la misma observación que para la propiedad anterior respecto a los valores de la propiedad Handshaking

LSB


Cap. 20

Pág. 16

Interval Indica el tiempo (en milisegundos) del intervalo entre una y otra comprobación del estado de recepción del puerto. El valor mínimo es de 55 ms. El análisis del puerto de comunicación no tiene nada que ver con la generación del evento OnComm. Este Este even evento to se prod produc ucir irá á cuan cuando do se cump cumpla lan n las las cond condic icio ione ness para para ello ello,, independientemente del tiempo programado en esta propiedad. La comprobación del puerto cada intervalo de tiempo marcado por esta propiedad solamente afecta a averiguar el estado de las líneas auxiliares CD, DSR y CTS, y para saber el número de caracteres existentes en los Buffers de transmisión y recepción. Las siguientes propiedades no difieren en nada respecto a otros controles :

Left, Name, Index, Top, Tag Propiedades propias del del tiempo de de ejecución PortOpen Abre el puerto de comunicación. Puede tener los valores True (Para abrirlo) y False (Para cerrarlo) Si tenemos un MSComm con Nombre (Name) MSComm1, para abrirlo ejecutaremos la siguiente sentencia : MSComm1.PortOpen = True Para cerrarlo, ejecutaremos : MSComm1.PortOpen = False

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

OutBufferCount Nos Nos perm permitite e cono conoce cerr cuan cuantos tos carac caracte tere ress qued quedan an por por tran transm smititir ir en el Buff Buffer er de sali salida da.. Emplearemos la sentencia : caracteressinenviar = MSComm1.OutBufferCount

Output Envía caracteres caracteres al Buffer de salida. Debe existir un signo igual ( = ) entre Output y lo que se envía al Buffer. Para enviar la frase Curso de Visual Basic ejecutaremos la sentencia : MSComm1.Output = “Curso de Visual Basic” Si deseamos enviar el contenido de una variable MSComm1.Output = variable LSB


Cap. 20

Pág. 17

Input Lee el Buffer de recepción. El número de caracteres leídos dependerá del valor de la propiedad InputLen. Cuando la propiedad InputLen tiene el valor 0, el Buffer se lee completo. Si InputLen tiene un valor distinto de 0, se leerá un número de caracteres igual al valor de esta propiedad.

CommEvent Devuelve el evento mas reciente que ha ocurrido para generar el evento general OnComm (Vea mas adelante adelante). Esta propiedad no está disponible en tiempo de diseño y es de sólo lectura en tiempo de ejecución. NombredelMSComm.CommEvent

Sintaxis

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

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

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

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

EVENTOS DEL MSComm El MSComm tiene varios eventos, pero un solo Procedimiento : el Procedimiento OnComm. Este procedimiento se ejecuta cada vez que se produce alguno de los eventos del MSComm . Esto quiere decir que para escribir el código apropiado en el procedimiento del MSComm será necesario analizar qué evento se ha producido y colocar, mediante una sentencia If .. Then el código apropiado para cada uno de los eventos que se produzcan. Para averiguar qué evento se ha producido puede hacerse consultando el valor de la propiedad CommEvent. (Se toma como nombre del MsComm el de MsComm1) If MsComm1.CommEvent = ComEvRing Then 'Se ha consultado si el evento particular que ha producido el evento general OnComm 'ha sido el ComEvRing (Se está recibiendo la llamada del teléfono). En esta sentencia LSB


Cap. 20

Pág. 18

‘If Then deberemos colocar el código necesario para que la aplicación se prepare para ‘recibir una comunicación a través del módem. End If Los eventos del Comm pueden identificarse por una constante o un número. La constante, como todas las de Visual Visual Basic, tiene una expresión bastante difícil. Se pone entre paréntesis el número que identifica a ese evento. Este número debe declararse como Integer . Se ejecutará el Procedimiento OnComm cuando ocurra alguno de los siguientes eventos :

ComEvCD

(5)

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

ComEvCTS

(3)

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

ComEvDSR

(4)

Cambio en la línea DSR. Igual que las anteriores. Debemos invocar la propiedad DSRHolding para averiguar su estado actual.

ComEvRing

(6)

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

ComEvReceive( 2 )

Cuando se recibe un número igual o mayor de caracteres que el indicado en la Propiedad RThreshold

ComEvSend

(1)

Cuando quedan en el búfer de transmisión menos caracteres que los indicados en la Propiedad SThreshold

ComEvEOF

(7)

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

comEventBreak (1001)

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

Tiempo de espera de Detección de portadora. La línea ComEventCDTO ComEventCDTO (1007) ( 1007) Detección de portadora (CD) estuvo baja durante el periodo de tiempo especi especific ficado ado en la Propie Propiedad dad CDTimeout , mien mientr tras as se inte intent ntab aba a transmitir un carácter.

ComEventCTSTO

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

ComEventDSRTO

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

LSB


Cap. 20

Pág. 19

ComEventOverrun

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

ComEventRxOver

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

ComEventRxParity

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

ComEventTxFull

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

ComEventDCB

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

ComEventFrame

1004

LSB

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


Cap. 20

Pág. 20

NOTA ADICIONAL ADICION AL El puerto de comunicaciones. El puerto de comunicaciones de un PC está formado por varias entradas / salidas. El soporte físico es un conector tipo Sub-D de 9 ó 25 contactos, macho en ambas versiones. Se necesita por tanto un cable con conector Sub-D hembra de 9 o 25 pines para acceder a él. La distribución de las señales en cada uno de sus pines es la siguiente :

GND

(Potencial de 0 V.).

TxD

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

RxD

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

RTS

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

CTS

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

DSR

Data Set Ready. Dispositivo de datos preparado. Es una entrada del ordenador. Le indica que el módem está encendido y listo para fu ncionar.

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

DTR

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

Otra señal (disponible sólo en los ordenadores que tengan conector de 25 pines, y no en todos) es la señal RING (timbre del teléfono) Es una entrada del ordenador. Le indica que está sonando el timbre de la línea telefónica del módem. Disposición de los pines en el ordenador Dependiendo de si tiene conector de 9 pines o de 25, la distribución de estas señales físicamente en el conector es :

Conector de 9 pines Pin 3 2 7 8 6 5 1 4

Conector de 25 pines Señal T xD RxD RTS CTS DSR GND CD DTR RING Tierra de protección

Pin 2 3 4 5 6 7 8 20 22 1

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


Cap. 20

Pág. 21

Capitulo 20 Visual Basic

Recommend Documents