Universidad del Tchira

Departamento de Ingeniera Electrnica

Instrumentacin Electrnica
















Elaboracin de un Servidor y un Cliente
TCP/IP usando LabView

Hecho Por:
Ing. Rafael Chacn
Ing. Jos Andrickson
Br. Juan Parada


San Cristbal, 2003
Servidor TCP

En esta gua se muestra un ejemplo de cmo elaborar un servidor TCP que
envi dos seales, la primera de ellas ser un dato que puede ser establecido por el
usuario en una perilla giratoria que tiene un rango de 0 a 100. El segundo dato es
obtenido a travs del puerto serial (en realidad es solo una simulacin con fines
educativos). Ambos datos se muestran en el panel frontal de nuestro VI.



La estructura principal de nuestro VI es una secuencia o sequence. En el
primer marco o frame es donde se inicializan las variables y se hace cualquier tipo
de ajuste preliminar a la ejecucin propiamente dicha del VI. Cuando se utilizan los
puertos es aqu donde se deben inicializar condiciones tales como: la paridad, la
velocidad de transferencia, entre otras.


En primer termino vamos a mostrar cual es la direccin IP de la maquina en la
que se est ejecutando este VI. Este indicador aparece en el panel frontal de nuestro
VI. Si no se ha configurado ninguna red es probable que la direccin sea: 127.0.0.1

En la parte intermedia se utiliza la funcin TCP Create Listener para
establecer un puerto de servicio. Estos puertos son nmeros que los sistemas
operativos utilizan para identificar el servicio que se necesita de un servidor. Si se
tiene, por ejemplo, un servidor llamado: www.servidor.com; est puede ofrecer varios
servicios tales como correo electrnico, buscador, servicios noticiosos, entre otros.
Entonces, se concluye que la forma de pedir un servicio especifico de un servidor es
haciendo referencia al numero del puerto asociado con dicho servicio. Debido a que
los sistemas operativos, marcas registradas, empresas de Internet, etc., ya han
apartado a nivel mundial algunos nmeros de puertos, se recomienda usar valores
superiores a 48000. La funcin TCP Create Listener tiene como salida un valor
Listener ID que se utilizara ms adelante para hacer referencia al puerto de servicio.

En la parte inferior se inicializa nuestra lista de clientes con una lista que est
vaca. Lo referente a la lista de clientes se detalla mas adelante.


Ahora vamos a describir el segundo marco de nuestra estructura principal. En
l se puede apreciar que se va a utilizar un sistema multitarea o multi-hilos.
Especficamente vamos a tener 3 hilos (representados por estructuras de ciclos
while) que se van a ejecutar de manera simultnea.


Primer hilo

En el primer ciclo while (superior izquierdo) es donde se crea la lista de
clientes y estos se introducen en ella a medida van llegando. En este VI, un cliente
es un cluster que contiene 2 campos. El primero es el connection ID que entrega la
funcin TCP Wait on Listener cuando un cliente se conecta a este servidor y a
este puerto (El puerto es referenciado a travs del Listener ID conseguido
anteriormente). Este connection ID es la referencia nica a la conexin TCP hecha
entre el cliente que se acaba de conectar y el servidor.

El segundo campo del cluster cliente, es un valor boolean que interpretaremos
como: TRUE = cliente activo y FALSE = cliente inactivo. As pues, la primera vez
que llega un cliente a la lista se le asigna el valor TRUE.

La lista de clientes no es otra cosa que un array unidimensional de clusters,
donde cada cluster es un cliente que est siendo atendido por el servidor. En este
primer hilo, cada nuevo cliente que llega se agrega automticamente a la lista.

Los tres hilos de este VI son ciclos while infinitos, es decir se coloc una
constante TRUE como control de los mismos. Por eso para finalizar la ejecucin del
servidor se debe utilizar el abort button del men del LabView.

Segundo hilo

En el segundo ciclo while (inferior izquierdo) es donde se gestionan los datos
que van a ser entregados a los clientes. En nuestro caso se tiene un SubVI
denominado TransSerial, el cual pretende ser un proceso de recepcin de datos a
travs del puerto serial. De este SubVI se obtiene un dato numrico llamado
2do Dato (que es mostrado en el panel frontal). El dato etiquetado como 1er Dato
se vara al girar la perilla en el panel frontal.

Ambos datos se empaquetan en un cluster que contiene toda la data a ser
enviada a los clientes.

Tercer hilo

En este hilo es donde se gestionan las peticiones de servicio por parte de los
clientes. Tambin es aqu donde se va a revisar la lista para determinar el estado de
actividad de los clientes que se encuentran en proceso de atencin.

La estructura de este hilo contiene una secuencia, la cual en su primer marco
tiene un simple retardo de tiempo. Este retardo se debe colocar para dar tiempo al
sistema operativo y a la red de gestionar la llegada de nuevos clientes en el primer
hilo. La no colocacin de este retardo puede traer como consecuencia errores
inesperados en tiempo de ejecucin, tales como: Clientes fantasmas, Clientes que
no se desconectan nunca, etc.



En el siguiente marco de la estructura dentro del tercer hilo, se tiene el
despacho de datos hacia los clientes. Primero se revisa el tamao del array de
clusters, este nmero obviamente es igual al nmero de clientes que existe en la
lista. Este dato se muestra en el panel frontal del VI.

La lista entra a un ciclo for donde se revisan (uno por uno) todos los clientes.
Ntese que el ciclo for se ejecuta tantas veces como clientes existan.

Cada cliente entra al SubVI Procesar (identificado con la letra P) y es aqu
donde se le enva la data del segundo hilo. A continuacin, en el SubVI Verificar,
se determina el estado del cliente que se est procesando (igual al ndice del ciclo
for). Si este se desconect se cambia el estado de su campo boolean a FALSE.


En el ltimo marco del ciclo se eliminan a todos aquellos clientes que hayan
marcados como inactivos en el marco anterior. Esto se hace a travs del SubVI
Eliminar.






SubVI Procesar

Este SubVI recibe como datos de entrada un cluster equivalente al cliente que
se va a atender y un cluster con la data que se va a enviar a este cliente.

Lo primero que se hace es obtener el connection ID del cliente, para usarlo en
la funcin TCP Write con la cual escribimos en la conexin TCP nica entre
este cliente y nuestro servidor.

Pero antes de escribir cualquier data, la funcin TCP Write necesita conocer
el tamao (cantidad de bytes) de la data que se va a transmitir. Por esta razn
primero se convierte la data en un string, con la funcin Flatten To String ,
seguidamente se obtiene el tamao de esta cadena con la funcin String Length
, con lo cual se obtiene un dato long (I32 o de 4 bytes) este dato se convierte en
una cadena de caracteres (obviamente de 4 bytes de largo) usando la funcin Type
Cast .

Entonces, primero se enva a la red el tamao de la data y luego si se enva la
data propiamente dicha. Y como salida de este SubVI se enva el cluster de error que
sale de la funcin TCP Write.






SubVI Verificar

Este SubVI recibe como entrada el cluster de error que viene del SubVI
Procesar, el nmero del cliente que se va a procesar (este nmero normalmente es
igual al ndice del ciclo for donde se esta procesando la lista) y la lista de clientes
actual. Como salida se obtiene una lista igual a la original o modificada, eso
depende del estado de los clientes.

Para cada cliente que se verifica el estado de su conexin TCP, de ah que se
revisa el campo status del cluster de error entrante. Si existe un error, se interpreta
que no se puede establecer una conexin TCP con este cliente y por lo tanto debe ser
eliminado de la lista. De hecho, si el cliente se desconecta, se genera el error de
cdigo 62.

Para eliminar el cliente de la lista, se modifica el estado de su campo boolean
activo. Esto lo marca para ser eliminado despus en otro proceso.



Si no existe error el cliente se considera activo y no se marca.





SubVI Eliminar

A este SubVI le entra la lista de clientes actual (incluyendo los inactivos) y
tiene como salida una lista de clientes con solo los clientes que estn activos.

La lista de clientes entrante se utiliza para indexar un ciclo for, dentro del
mismo se revisa uno por uno cada cliente para verificar su estado de actividad.

Dentro del SubVI creamos una variable lista de clientes pero que est vaca.
Esta lista vaca se utiliza para crear una nueva lista, que ser la salida del SubVI.

Si el estado del cliente que se esta revisando es activo (TRUE) se aade a la
lista vaca.



Si el cliente se desconect su estado ser inactivo (FALSE) y no ser
incorporado a la nueva lista, eliminndose de esta manera permanentemente de la
lista de clientes.



Obsrvese el uso de Shift Register dentro del ciclo for para crear la lista
cluster a cluster, o lo que es lo mismo cliente a cliente (solo los activos).

Elaboracin de un cliente TCP compatible con el servidor ya diseado.

Ahora vamos a disear un cliente TCP que sea capaz de conectarse con el
servidor que se dise, para poder obtener de l los datos respectivos. Estos datos se
mostraran con indicadores en el panel frontal de nuestro cliente.

Lo que necesitamos conocer para poder establecer una conexin TCP es la
direccin IP del servidor y el nmero del puerto de servicios. Se puede hacer la
prueba sin necesidad de una red fsica, es decir corriendo el servidor y el cliente en
la misma maquina si se especifica como direccin IP del servidor como: 127.0.0.1

En el panel frontal de nuestro VI se colocaran 2 controles para poder
modificar los valores de la direccin IP (string) y del nmero del puerto (numrico).




La estructura de nuestro VI se basa en un sistema multitarea, en este caso se
tienen solo dos hilos de procesamiento simultneo, cada uno representado por un
ciclo while, a los que se les condicion su culminacin por el estado del control
boolean Encendido (ubicado en el panel frontal) y al hecho de que no se presente
ningn error TCP.

Es importante recordar que: no se deben conectar variables entre hilos que
se ejecutan independientemente, ya que esto trae como consecuencia errores
lgicos al momento de correr el VI, debido a las prioridades de ejecucin que
LabView asignara a cada hilo. En vez de eso se deben usar variables locales, tal y
como se hizo en el diseo del servidor y ahora se har en el diseo del cliente.





Primer hilo

Antes de ejecutarse por primera vez el ciclo superior se introduce la direccin
IP del servidor y el nmero del puerto en la funcin TCP Open Connection , la
cual abre la conexin con el servidor y suministra un connection ID que ser
utilizado posteriormente.

Una vez dentro del ciclo se utiliza la funcin TCP Read para leer los datos
que llegan desde el servidor. A esta funcin se le introduce el connection ID obtenido
previamente y se le dice que se lean 4 bytes. Estos 4 bytes contienen la informacin
del tamao de la data (cantidad de bytes) que va llega desde el servidor
(Nota: revisar lo relacionado con el segundo marco del tercer hilo del servidor). Esta
informacin se transforma a un valor numrico usando la funcin Type Cast,
colocndole como dato de ejemplo una constante numrica tipo I32.

La segunda funcin TCP Read lee la data propiamente dicha que llega desde
el servidor. Esta data llega como una cadena o string, por lo tanto es necesario
transformarla a la forma original de cluster (tiene que ser idntica a la manejada por
el servidor, as que se recomienda copiar una variable de estas desde el servidor).

La cadena pasa a travs de la funcin Unflatten From String para ser
convertida en el cluster que necesitamos. Pero esta funcin para su correcto uso
debe colocrsele un dato ejemplo del tipo de dato final que se quiere obtener a
partir de la cadena, es por esto que en nuestro caso le colocamos una variable local
del mismo cluster Data.

Una vez que se decide apagar el VI usando el control Encendido o cuando
ocurre un error TCP, se sale del ciclo y la funcin TCP Close Connection cierra
la conexin con el servidor.

Ntese que la funcin General Error Handler se puede utilizar tanto en
el servidor como en el cliente para manejar cualquier mensaje de error (como los
TCP) que ocurran en tiempo de ejecucin.


Segundo hilo

En este hilo es donde la data se procesa para ser mostrada en el panel frontal.

Alguien podra pensar que este manejo de datos se puede hacer en el primer
hilo, esto puede ser cierto para algunos procesos con lo cual el cliente nos quedara
estructurado en un hilo sencillo. Pero en casos en los que se tengan valores
formateados (como por ejemplo valores digitales que deban ser convertidos a
anlogos) es mejor separar el tratamiento de los datos en dos hilos