BOLETIN INFORMATIVO. Núm P022 Marzo 28 de 2001

(1)

ADMINISTRACION CENTRAL DE INFORMATICA Ing. Jorge Montoya Castro

DE INFORMATICA

BOLETIN INFORMATIVO

Núm P022 Marzo 28 de 2001

Con el presente se les informa que se deberán modificar el protocolo del servicio receptor de archivos en general en los equipos prevalidadores, para que las aplicaciones encargadas de obtener los catálogos autorizados (clincat o similares) puedan funcionar de manera adecuada.

Para lo anterior, se anexa documento que describe los protocolos para comunicación cliente-servidor UNIX-UNIX, siendo el mismo para aplicaciones PC-UNIX. El servicio en cuestión se describe en el apartado 2.2, y los cambios, en la secuencia de intercambio de información se tienen en los puntos 1, 1.1 y 1.2 (página 5), sólo que las funciones de lectura/escritura y otras para comunicación via sockets varían según la plataforma y lenguaje de desarrollo utilizados.

(2)

ADMINISTRACIÓN DE DESARROLLO PARA ADUANAS

SISTEMA DE AUTOMATIZACIÓN ADUANERA INTEGRAL (S. A. A. I.)

PROTOCOLOS DE COMUNICACIÓN ENTRE EQUIPOS PREVALIDADORES Y

EQUIPO DE MÓDULOS

(UNIX – UNIX)

(3)

Revisión 2.

Marzo de 2001 Página 1

PROTOCOLOS DE COMUNICACIÓN ENTRE EQUIPOS PREVALIDADORES Y EQUIPO DE MÓDULOS.

C O N T E N I D O

1. TRANSMISOR DE ARCHIVOS A VALIDAR (~diablo_tp)...2

2. SERVICIOS DE RECEPCIÓN DE ARCHIVOS ...4

2.1 RECEPTOR DE ARCHIVOS DE RESPUESTA DE VALIDACIÓN (receptor_p) ...4

2.2 RECEPTOR DE ARCHIVOS EN GENERAL (ftreceptor) ...5

3. PROGRAMA DE ACTUALIZACIÓN DE CATÁLOGOS (clincat) ...7

ANEXO A: Códigos de error. ...8

ANEXO B: Configuración de los servicios ...10

ANEXO C: Archivos generados por el programa de actualización de catálogos ...11

(4)

1. TRANSMISOR DE ARCHIVOS A VALIDAR (~diablo_tp)

Este programa es un programa demonio que entre otras funciones, detecta los archivos depositados en el directorio Arbol del equipo prevalidador y los transmite al equipo de módulos.

Un program a que sustituya a ~diablo_tp no tendría que ser por fuerza un programa demonio, ni llevar a cabo todas las tareas que actualmente tiene a su cargo. En este documento se describe sólo la parte del intercambio de información, a partir de que se logra la conexión vía sockets con el equipo de módulos.

En primer lugar, en el host local se obtiene un socket descriptor utilizando la función socket(), y se procede a establecer la conexión con el host remoto (equipo de módulos) a través del servicio trans_recep (puerto 50205), Los datos: familia de sockets a utilizar (AF_INET), dirección IP del host remoto y el número de puerto del servicio se almacenan en una estructura del tipo struct sockaddr_in (puede utilizar las funciones gethostbyname() y getservbyname() para obtener estos datos dinámicamente), que será uno de los argumentos para la función connect(). Si la llamada a la función es exitosa, se tendrá establecida una conexión con el servicio receptor de archivos en el equipo de módulos. Se puede proceder ahora a transmitir la información al equipo de módulos.

Secuencia de intercambio de información.

Transmisión de datos previos.

1. Se transmite una cadena de trece caracteres: los primeros doce son el nombre del archivo incluida la extensión; el carácter número 13 es el identificador del equipo prevalidador del que se transmite el archivo. Para este propósito, se utilizan las funciones write() o send().

2. A continuación, se transmiten cuatro bytes (un entero largo) que especifican el tamaño del archivo a transmitir, en bytes. Estos deben ser transmitidos del byte más significativo al byte menos significativo. Se debe tener cuidado con el orden de los bytes utilizados para el almacenamiento de datos enteros en una plataforma en particular. Consulte en algún manual lo relativo a la función htonl() (host to net long), utilizada para cambiar el orden de los bytes que componen un dato entero largo para que sean conformes para transmitirse a la red.

Recepción y análisis del primer acuse.

3. Se recibe 1 byte (primer acuse de recibo) como resultado de la validación de los datos previos.

Cuando el valor de este byte es diferente de 0, se tiene un error que debe interpretarse como se muestra en el anexo A para llevar a cabo las acciones correctivas correspondientes; a continuación se debe cerrar el socket y terminar la comunicación. Si el valor del byte recibido es cero, se procede a la transferencia de información.

Transmisión de la información (contenido del archivo a validar).

4. Se abre en modo lectura el archivo cuya información se transmitirá al equipo de módulos.

Véase la función open(). Se utiliza la función read() para leer bloques de 1024 caracteres del archivo. Si se utiliza la función fopen() para abrir el archivo, la información se podría transmitir línea a línea, en vez de bloques de bytes.

5. Se lee un bloque de 1024 bytes desde el archivo (o una línea de información). Si el valor devuelto por la función read() es mayor que cero, se debe transmitir ese número de bytes al equipo de módulos; el valor devuelto por la función write() (número de bytes transmitidos) debe ser igual al número de bytes leídos. Si se transmiten líneas, el número de bytes a ser transmitidos por write() debería ser el del tamaño de la línea leída.

(5)

Revisión 2.

6. Se repite el paso anterior hasta que la función read() devuelva un valor de cero, indicando que se ha terminado de leer el contenido del archivo. En este momento se bloquea la posiblidad de escritura al socket (véase la función shutdown()), indicando con esto el fin de la transmisión.

Recepción y análisis del segundo acuse.

7. Se recibe 1 byte (segundo acuse de recibo) como resultado de la verificación del número de bytes recibidos. Cuando el valor de este byte es diferente de 0, se tiene un error que debe interpretarse como se muestra en el anexo A para llevar a cabo las acciones correctivas correspondientes; a continuación se debe cerrar el socket y terminar la comunicación. Si el valor del byte recibido es cero, la información se ha recibido correctamente.

Cierre del socket.

8. Una vez concluida la transmisión de información, se debe cerrar por completo el socket. Se recomienda el uso combinado de las funciones shutdown() (en modo total) y close().Es importante recalcar la importancia del cierre adecuado del socket una vez concluida la transmisión, pues de no hacerlo así, se puede dejar establecida la conexión en con el equipo remoto y tener activo el servicio de recepción. Con un número elevado de conexiones activas, se puede degradar significativamente el rendimiento del equipo de módulos.

Resumen de la secuencia de intercambio de información.

TRANSMISIÓN RECEPCIÓN

13 bytes. Nombre del archivo más carácter de identificación del equipo.

4 bytes. Dato entero, el tamaño del archivo, del byte más significativo al menos significativo.

1 byte. Valor ASCII cero si todo está bien.

Consulte anexo A para otro caso.

n bytes. Contenido del archivo, en bloques de 1024 bytes o línea por línea. Al terminar, bloquear la escritura en el socket (shutdown())

(6)

2. SERVICIOS DE RECEPCIÓN DE ARCHIVOS

Estos servicios son la contraparte en el host local (prevalidador) de los programas encargados de la transmisión de archivos desde el host remoto (equipo de módulos). Son activados cuando alguno de los programas transmisores establece una conexión vía sockets con el equipo prevalidador. Para que esto pueda lograrse, los servicios deben estar registrados en los archivos /etc/services y /etc/inetd.conf. Véase el anexo B para el detalle de las líneas que deben ser incluidas en estos archivos.

Una vez configurados los archivos para estos servicios, el superusuario del sistema (root o cualquier otro usuario con los mismos privilegios) puede ponerlos en servicio indicando al superdemonio de UNIX (programa inetd) que atienda a la nueva configuración. La manera de lograr esto es variable dependiendo de la plataforma UNIX particular. Consulte la página del manual para inetd en su plataforma para saber cómo hacerlo. Se muestran ejemplos para dos plataformas:

Para HP-UX: inetd –c

SCO UNIX: kill –s HUP <pid de inetd>

kill –1 <pid de inetd>

2.1 RECEPTOR DE ARCHIVOS DE RESPUESTA DE VALIDACIÓN (receptor_p)

Este servicio es el programa complemento del demonio transmisor de archivos de respuesta, el cual reside en el equipo de módulos. Dado que este servicio es activado por el superdemonio, no se tienen que codificar las secciones encargadas de establecer la conexión con el socket, sólo las de intercambio de información. Este programa lee desde stdin (file descriptor 0) lo que le es enviado a través del socket utilizando la función read() o recv() y responde al programa transmisor por stdout (file descriptor 1) con las funciones write() o send().

Recepción de datos previos.

1. Se recibe una cadena de doce caracteres conteniendo el nombre del archivo, incluida la extensión (.err).

2. A continuación, se reciben cuatro bytes (un entero largo) que especifican el tamaño del archivo a recibir, en bytes. Estos bytes son transmitidos del más significativo al menos significativo. Si en el host receptor el orden de los bytes para el almacenamiento de datos enteros no es el mismo que el orden de transmisión en la red, se debe convertir, utilizando la función ntohl() (net to host long). Consulte en algún manual lo relativo a ésta función.

Envío del primer acuse de recibo.

3. Se revisa que el nombre de archivo recibido sea correcto en cuanto a sintaxis, además de otras condiciones que pudieran interferir con la recepción correcta de la información. Si todo está bien, se envía un byte con valor 0. En caso de error, el valor del byte enviado será alguno de los mostrados en el anexo A, según corresponda a la causa de error.

(7)

Revisión 2.

4. Se abre el archivo donde se almacenará la información recibida desde el equipo de módulos, con el nombre tal como se tiene en la cadena de doce caracteres de los datos previos y en modo escritura. Vea lo relativo a la función open() en el manual correspondiente.

Recepción de la información (contenido del archivo transmitido desde módulos).

5. Con la función read() o recv() se recibe la información transmitida desde el equipo de módulos, en bloques de 1024 bytes. Los bytes recibidos se escriben inmediatamente al archivo donde se almacena la información. Estos dos pasos se repiten cíclicamente, hasta que la función de lectura regrese un valor de cero, en cuyo caso se cierra el archivo receptor y se compara el número de bytes recibidos contra el número de bytes especificado en los datos previos.

Envío del segundo acuse de recibo.

6. Si se recibieron tantos bytes como especificados en los datos previos, se envía un byte con valor cero (nulo). En otro caso debe enviar un valor tal como se especifica en el anexo A

2.2 RECEPTOR DE ARCHIVOS EN GENERAL (ftreceptor)

Este servicio es el programa complemento del programa transmisor de archivos en general, el cual reside en el equipo de módulos. Este servicio es utilizado por la contraparte en módulos del programa clincat. A semejanza del receptor de archivos de respuesta, este servicio es activado por el programa inetd, por lo que no se tienen que codificar las secciones encargadas de establecer la conexión con el socket, sólo las de intercambio de información. Este programa lee desde stdin (file descriptor 0) lo que le es enviado a través del socket utilizando la función read() o recv() y responde al programa transmisor por stdout (file descriptor 1) con las funciones write() o send().

Recepción de la cadena "ruta y nombre del archivo destino".

1. Se reciben 4 bytes, que indican la longitud de la cadena que se recibirá a continuación. Estos bytes son transmitidos del más significativo al menos significativo. Si en el host receptor el orden de los bytes para el almacenamiento de datos enteros no es el mismo que el orden de transmisión en la red, se debe convertir, utilizando la función ntohl() (net to host long).

Consulte en algún manual lo relativo a ésta función. Por razones de protocolo interno entre ciertos equipos, este dato puede ser positivo o negativo. Si el dato es positivo, se puede continuar a partir del punto 2. Cuando sea negativo, se tiene que llevar a cabo lo indicado en los incidsos 1.1 y 1.2.

1.1 Cambiar el signo al dato, multiplicando por –1.

1.2 Se reciben a continuación 256 bytes, los cuales deberán ser ignorados. A continuación, se hace una segunda lectura de 256 bytes, que también deberán ser ignorados. Es importante que esta lectura se haga en dos bloques como se indica, en vez de un solo bloque de 512 bytes.

2. Se reciben a continuación tantos bytes como se indica en el dato del punto 1 (valor positivo).

Esta cadena de bytes contiene el nombre del archivo a ser creado; el nombre puede incluir la ruta en la que se depositará el archivo. Si la ruta es absoluta, se respeta como tal; en el caso de rutas relativas, se tomarán con relación al directorio /usr/users/saai/tmp. En ningún caso la longitud de la cadena será mayor de 160 bytes.

(8)

Envío del resultado de la validación del nombre del archivo destino.

3. A la cadena que especifica el archivo a recibir se le hacen varias validaciones con el fin de asegurar que no habrá problema para la recepción del archivo y se intenta crear el archivo con la función creat(). Si no hay ningún problema, se envía un byte con valor ASCII cero (nulo).

En caso de haber algún problema, en el byte de validación se almacena uno de los valores descritos en el anexo A, según sea la causa del problema.

Recepción del dato "tamaño del archivo".

4. Se reciben 4 bytes, que indican la longitud de la cadena que se recibirá a continuación. Estos bytes son transmitidos del más significativo al menos significativo. Si en el host receptor el orden de los bytes para el almacenamiento de datos enteros no es el mismo que el orden de transmisión en la red, se debe convertir, utilizando la función ntohl() (net to host long).

Consulte en algún manual lo relativo a ésta función.

Envío de la confirmación de recepción de dato "tamaño del archivo".

5. Si se recibieron sin problema los 4 bytes que especifican el tamaño del archivo, se envía un byte con valor ASCII cero (nulo). Si no se recibieron de manera adecuada estos 4 bytes, se envía un byte cuyo valor será el que se muestra en el anexo A.

de la información (contenido del archivo transmitido desde módulos).

6. Con la función read() o recv() se recibe la información transmitida desde el equipo de módulos, en bloques de 1024 bytes. Los bytes recibidos se escriben inmediatamente al archivo donde se almacena la información. Estos dos pasos se repiten cíclicamente, hasta que la función de lectura regrese un valor de cero, en cuyo caso se cierra el archivo receptor y se compara su tamaño contra el número de bytes especificado en los datos previos.

Envío del acuse de recibo final.

7. Si se recibieron tantos bytes como especificados en los datos previos, se envía un byte con valor cero (nulo). En otro caso debe enviar un valor tal como se especifica en el anexo A

Al concluir el envío del acuse de recibo final, el programa receptor cierra el socket y termina.

(9)

Revisión 2.

3 PROGRAMA DE ACTUALIZACIÓN DE CATÁLOGOS (clincat)

Este programa es un programa cliente cuya contraparte es el servicio de actualización de catálogos en el equipo de módulos. A continuación se describe la parte del intercambio de información, a partir de que se logra la conexión vía sockets con el equipo de módulos.

En primer lugar, en el host local se obtiene un socket descriptor utilizando la función socket(), y se procede a establecer la conexión con el host remoto (equipo de módulos) a través del servicio act_cat (puerto 50251), Los datos: familia de sockets a utilizar (AF_INET), dirección IP del host remoto y el número de puerto del servicio se almacenan en una estructura del tipo struct sockaddr_in (puede utilizar las funciones gethostbyname() y getservbyname() para obtener estos datos dinámicamente), que será uno de los argumentos para la función connect(). Si la llamada a la función es exitosa, se tendrá establecida una conexión con el servicio receptor de archivos en el equipo de módulos. Se puede proceder ahora a transmitir la información al equipo de módulos.

Transmisión argumentos.

1. Se transmiten cuatro bytes (un entero largo) que especifican el tamaño de la cadena de argumentos a transmitirse, en bytes. Estos deben ser transmitidos del byte más significativo al byte menos significativo. Se debe tener cuidado con el orden de los bytes utilizados para el almacenamiento de datos enteros en una plataforma en particular. Consulte en algún manual lo relativo a la función htonl() (host to net long), utilizada para cambiar el orden de los bytes que componen un dato entero largo para que sean conformes para transmitirse a la red.

2. A continuación se transmite la cadena de argumentos: los primeros dos caracteres son el número de catálogo que se desea extraer (ver anexo C), el carácter número 3 es un espacio en blanco, los caracteres restantes son el nombre del equipo prevalidador que desea obtener la información (ej, aaa470). Para este propósito, se utilizan las funciones write() o send().

Recepción del estado de ejecución del servidor.

3. Empleando la función recv() o read(), se recibe 1 byte como resultado de la ejecución del servidor en el equipo de módulos. Cuando el valor de este byte es diferente de 0, se tiene un error que debe interpretarse como se muestra en el anexo A para llevar a cabo las acciones correctivas correspondientes; a continuación se debe cerrar el socket y terminar la comunicación. Si el valor del byte recibido es cero, la ejecución del servidor se realizó correctamente

Los archivos generados por el servidor (ver anexo C) serán recibidos a través del servicio

“Receptor de Archivos en General”, los cuales serán depositados bajo la ruta /usr/users/saai/ACTUALIZA .

Resumen de la secuencia de intercambio de información.

TRANSMISIÓN RECEPCIÓN

4 bytes. Dato entero, el tamaño de la cadena de argumentos a transmitirse, del byte más significativo al menos significativo.

“n” bytes conteniendo la cadena de argumentos (ej. “01 aaa470”).

(10)

ANEXO A CÓDIGOS DE ERROR

RECIBIDOS POR EL PROGRAMA TRANSMISOR DE ARCHIVOS A VALIDAR (~diablo_tp).

VALOR SIGNIFICADO

Primer acuse de recibo.

1 El servicio receptor en el equipo de módulos no pudo leer correctamente alguno de los datos previos: los 13 bytes del nombre del archivo o los cuatro bytes que especifican el tamaño. Cerrar el socket y reintentar.

2 Ya existe una copia del archivo en el equipo de módulos. Cerrar el socket. Se puede intentar la transmisión de la información en un archivo con nombre distinto.

- 1 Error grave en el host remoto (equipo de módulos). Dar aviso al operador para que corrija el problema.

Segundo acuse de recibo.

1 Recepción incompleta de la información. Tamaño del archivo diferente al transmitido en los datos previos. Cerrar el socket y volver a transmitir la información.

- 1 Error grave en el host remoto (equipo de módulos). Dar aviso al operador para que corrija el problema.

ENVIADOS POR EL SERVICIO RECEPTOR DE ARCHIVOS DE RESPUESTA (receptor_p).

1 No se pudo leer correctamente alguno de los datos previos: los 12 bytes del nombre del archivo o los cuatro bytes que especifican el tamaño.

2 Ya existe una copia del archivo que se pretende recibir y ésta no se pudo respaldar (renombrar). Cerrar el socket. Revisar a detalle el por qué no se pudo efectuar el respaldo..

- 1 Error grave en el sistema (equipo local). No fue posible posicionarse en directorio de trabajo o abrir el archivo para recibir la información que transmitirá el equipo de módulos.

Dar aviso al administrador del equipo para que corrija el problema.

1 Recepción incompleta de la información. Tamaño del archivo diferente al transmitido en los datos previos..

- 1 Error grave en el sistema (equipo local). No se pudo registrar recepción del archivo. Dar aviso al administrador del equipo para que corrija el problema.

(11)

Revisión 2.

ENVIADOS POR EL SERVICIO RECEPTOR DE ARCHIVOS EN GENERAL (ftreceptor).

40 El programa no se pudo posicionar en el directorio de trabajo (/usr/users/saai/tmp). El administrador del equipo debe averiguar la causa y corregirla.

41 No fue posible leer los 4 bytes indicadores del tamaño de la cadena que especifica el nombre del archivo a recibir. El valor de retorno de la función read() indica la causa de la falla.

42 No se pudo leer el número de bytes que se indicaban como tamaño de la cadena que especifica el nombre del archivo.

43 La longitud de la cadena recibida (terminada con un nulo) es cero o mayor a 160 bytes.

44 Algún componente del path espedificado en la cadena no es un directorio válido.

45 Algún componente del path especificado en la cadena no tiene permisos de acceso.

46 El último directorio especificado en el path no permite escritura.

47 La función stat() utilizada para validar el archivo especificado en la cadena devolvió otro error diferente a los especificados en los valores 44 a 46.

48 El archivo destino ya existe, pero no es un archivo regular.

49 El archivo destino ya existe, pero no se puede reescribir.

50 No fue posible leer los 4 bytes indicadores del tamaño del archivo a recibir. El valor de retorno de la función read() indica la causa de la falla.

51 No se pudo crear el archivo destinado a recibir la información. El valor de retorno de la función creat() indica la causa del error.

52 Escritura incompleta en el archivo destino de los bytes recibidos. Una posible causa es la falta de espacio en disco.

53 El tamaño del archivo recibido no es el mismo que se indicó como tamaño del archivo a recibir.

54 Falló la función stat() al intentar calcular el tamaño del archivo recibido.

RECIBIDOS POR EL CLIENTE DE ACTUALIZACIÓN DE CATÁLOGOS (clincat).

10 Número incorrecto de argumentos.

11 Número de catálogo fuera de rango (ver Anexo C).

12 Error en el host remoto (equipo de módulos) al intentar abrir la Base de Datos. Dar aviso al operador para que corrija el problema.

13 Error el host remoto (equipo de módulos) al extraer los Datos. Dar aviso al operador para que corrija el problema.

20 El host remoto (equipo de módulos) no reconoce el nombre del host local especificado en la cadena de argumentos.

23 El host remoto (equipo de módulos) no pudo efectuar la conexión con el host local.

40-54 El host remoto (equipo de módulos) no pudo transmitir el archivo al host local. Los códigos de error corresponden a los del Rececptor de Archivos en General (primer y segundo acuse de recibo).

(12)

ANEXO B

CONFIGURACIÓN DE LOS SERVICIOS.

En este apartado se especifica la manera de configurar los servicios receptores en el equipo prevalidador. Se hará referencia conforme a la configuración actual, pudiendo ésta ser cambiada conforme se desarrolle el software para cada equipo.

Se agregarían líneas a los archivos de configuración de los servicios según se indica.

En el archivo /etc/services.

trans_recep 50205/tcp # para archivos de validación y respuesta saaift 50201/tcp # para el receptor de archivos en general act_cat 50251/tcp # para actualización de catálogos

En el archivo /etc/inetd.conf

trans_recep stream tcp nowait saai /usr/users/saai/bin/receptor_p receptor_p saaift stream tcp nowait saai /usr/users/saai/bin/ftreceptor ftreceptor

Los programas sevidores receptor_p y ftreceptor deberán tener permisos 100 y encontrarse en el directorio /usr/users/saai/bin, con propietario y grupo saai.

Una vez cumplido lo anterior, el usuario root o cualquier otro con privilegios semejantes puede activar dichos servicios haciendo que el superdemonio (programa inetd) vuelva a leer los archivos de configuración. Para logar lo anterior, consulte en el manual lo correspondiente a inetd. Se muestra a continuación cómo se haría en dos plataformas.

Para HP-UX: inetd –c

SCO UNIX: kill –s HUP <pid de inetd>

kill –1 <pid de inetd>

(13)

Revisión 2.

ANEXO C

ARCHIVOS GENERADOS POR EL PROGRAMA DE ACTUALIZACIÓN DE CATÁLOGOS

CATÁLOGO NÜMERO ARCHIVO GENERADO

Descripción de errores de validación de pedimentos normales. 01 errores.asc Descripción de errores de validación de pedimentos de

tránsitos. 02 errtran.asc

Padrón de importadores/exportadores. 03 rnie.asc

Sectores. 04 catsect.asc

Padrón de importadores sectoriales. 05 padsec.asc

Relación de Actualizaciones. 06 relact.asc

Descripción de errores de validación de ped. de SAAI M3 07 erroresM3.asc