martes, 15 de julio de 2008

Otras Cosas

Por Hacer

  • Por supuesto, integrar los comentarios y sugerencias que nos manden amablemente en este documento. Realimentación, graciaaas.
  • Estudiar el ibod para la gestión dinámica de conexiones a 128K por demanda de tráfico.
  • ToDo lo que se nos vaya ocurriendo... ;-)

Copyright y Propiedad Intelectual

El RDSI-Como es Copyright (c) 1998 Antonio Verdejo García & Francisco José Montilla Blanco.

Este trabajo puede ser reproducido en su totalidad o en parte, tanto de forma impresa como electrónica, sujeto a las siguientes condiciones:

  1. La notificación del copyright y esta licencia debe preservarse completa en todas las copias, tanto completas como parciales.
  2. Cualquier traducción o trabajo derivado debe de ser aprobado por los autores por escrito antes de su distribución.
  3. Si se distribuye el Trabajo parcialmente, deben de incluirse instrucciones de dónde obtener la versión completa original (en forma impresa o electrónica), así como los medios para conseguirla.
  4. Pueden ser reproducidas pequeñas porciones como ilustraciones para revistas o citas para otros trabajos sin esta notificación de permiso si se cita apropiadamente su procedencia.

Problemas Frecuentes

Al lanzar la conexión miro el /var/log/messages y sólo veo(una vez tras otra):

Apr 15 10:34:08 wanda kernel: ippp0: dialing 0 055...
Apr 15 10:34:08 wanda kernel: ippp0: dialing 1 055...
Apr 15 10:34:08 wanda kernel: ippp0: dialing 2 055...

pero no veo nada más, ¿a qué puede ser debido?

Es un problema físico. Revise la conexión del cable tanto en la tarjeta como en el TR1. Revise la continuidad del cable así mismo. Cámbielo en último término. Asegúrese de que su TR1 tiene servicio... ;-) y Asegúrese de no estar pasando por ninguna centralita.

La conexión se corta tras un mensaje como:

Apr 15 15:58:28 wanda pppd[208]: Could not determine remote IP address

y seguidamente:

Apr 15 15:58:28 wanda pppd[208]: LCP terminated at peer's request
Apr 15 15:58:28 wanda kernel: isdn_net: local hangup ippp0
Apr 15 15:58:28 wanda kernel: ippp0: Chargesum is 0
Apr 15 15:58:28 wanda pppd[208]: Modem hangup
Apr 15 15:58:28 wanda pppd[208]: Connection terminated.

Es un problema bastante común debido a que Infovía (en el supuesto de que la use para conectar) no nos asigna, ---o no lo hace con suficiente rapidez--- una dirección remota del enlace PPP. Hay un solución que funciona tanto en conexiones RDSI como RTC que consiste en pasarle nosotros una dirección en el establecimiento de la conexión. En el caso de conexiones vía RTC (módem corriente y moliente) incluya una línea en el /etc/ppp/options tal que:

:172.16.1.96

y deje el parámetro que le indica que, a pesar de todo, aceptaremos la IP que el extremo nos asigne como remota (ipcp-accept-remote). La IP que pongamos puede ser cualquiera, pero como siempre, y por seguir una regla, ponga una de las que normalmente nos asigna Infovía de su rango (172.16.x.x por ejemplo).

Gracias a Horacio J. Peña por este detalle (el primero al que se lo leimos en la lista del SLUG).

El caso de conexiones vía RDSI (sobre todo en el caso de que usemos el primer método) se puede proceder de la misma forma, pues aunque se le pasen parámetros al (i)pppd, el demonio leerá el fichero /etc/ppp/options.

Al inicializar el demonio ipppd obtengo el mensaje ``Can't find usable ippp device''. ¿A qué es debido?

Según Frank Meyer, del grupo de desarrollo isdn4linux, se debe a que al lanzar el ipppd, este calcula un número aleatorio basándose en la función gethostid() que provoca una resolución DNS, usando para ello el servidor de nombres que aparezca en /etc/resolv.conf.

Si no tenemos la conexión activa, esto lógicamente no es posible y el DNS no puede ser alcanzado (y hablamos en el caso general de que no se disponga de un DNS local, como suele suceder comúnmente).

Para solucionarlo, incluya el nombre de su máquina (incluido localhost) en el /etc/hosts con el dominio completo que haya especificado en /etc/resolv.conf. Hay otra solución basada en un parche no oficial para evitar este comportamiento por parte del ipppd; el fichero syncPPP FAQ incluído en el directorio de documentación de las utilidades ISDN amplía este tema.

Instalación y configuración de Software de Aplicación

Mi tarjeta parece que ya está lista. ¿Puedo usar los scripts de conexión a Infovía que usaba hasta ahora?

No tal cual; necesitará hacer ciertas modificaciones. Usaremos otro método para conectarnos a iNET. En vez de usar el pppd asíncrono de toda la vida, usaremos un pppd especial, síncrono, que permite algunas lindezas: el ipppd.

Arranque su cliente ftp favorito, y diríjase a ftp://ftp.franken.de/pub/isdn4linux/v2.0/isdn4linux*.tar.gz que es el sitio oficial del ISDN4Linux. Ahí tiene una mágnifica (aunque algo falta de actualización) FAQ en un perfecto inglés que debería tener al menos como punto de referencia.

Le remitiríamos a ella, pero si ha llegado hasta aquí y hacemos eso igual empezamos a sentir agudos pitidos en los oidos... ;-)

Descomprimimos, configuramos, compilamos e instalamos. De la lista de utilidades las que más nos interesan, son isdnctrl (directorio isdn) y el ipppd (directorio ppp4i4k/ipppd/version) porque son las que usaremos en el método que describiremos después.

Normalmente, casi todas las distribuciones suelen llevar un paquete de utilidades RDSI que incluyen los programas que mencionamos, amén de abundante documentación y scripts de ejemplo. Busque en su distribución favorita.

No obstante, si por alguna razón no consigue compilar los elementos necesarios, en ftp://ftp.insflug.org/pub/RDSI/ tiene a su disposición el software mínimo necesario ya compilado.

Como en todo sistema UN*X la comunicación con los dispositivos físicos (tarjetas, discos...) se realiza por medio de ficheros. Necesitaremos crear los dispositivos que harán que el kernel pueda trabajar con la tarjeta RDSI. Si usa un paquete de una distribución es casi seguro que creará, si no lo están ya, las entradas necesarias en el directorio /dev, si no es así, ejecute make devices en el directorio raíz de las isdn4utils que bajó antes, será sufiente.

Pero bueno, ¡¿qué cómo conectooo?!

Vamos con ello. Dos métodos, uno de ellos mencionado someramente. Se basa en aprovechar los scripts de conexión (que suponemos le funcionan) usados con un módem analógico normal. Las variaciones son mínimas. Añada en el guión de chat la cadena de inicio

ATS14=3&xxxxxxxxx (siendo xxxxxxxxx el numero de su linea RDSI)

y sustituya donde corresponda el dispositivo /dev/modem por /dev/ttyI0. Usaremos el pppd normal y corriente que usábamos antes con el módem. Nada más que decir de este método, salvo que no haga uso del parámetro +ua en el fichero options, está obsoleto en las últimas versiones del paquete pppd. .

El segundo hace uso de las utilidades que nos bajamos anteriormente, y nos permitirá conseguir llamadas bajo demanda (dial on demand, DoD).

Opción ésta muy interesante en redes donde se vaya a usar la conexión RDSI para dar servicio iNET, por medio del enmascaramiento IP, a varios puestos de una red local, pues posibilitará el que la llamada se efectúe automáticamente por tráfico de paquetes (abrir un navegador, lanzar el programa de correo, hacer un ping, etc.).

La parte más importante de este método reside en los scripts usados para configurar la conexión. Los hay de múltiples formas, más o menos "sofisticados". Los incluidos en este documento puede que no sean para ganar un Nobel, pero funcionan bastante bien. En este sentido, estamos abiertos (no hace falta decirlo) a modificaciones y/o comentarios, pero de eso hablaremos más tarde.

Unos puntos a destacar. Si queremos usar DoD, necesitaremos tener dos scripts en /etc/ppp también incluidos, para asegurarnos que la ruta por defecto apunte siempre a una dirección de iNET y al dispositivo RDSI.

Esto, y, por supuesto, NO tener ninguna ruta por defecto a la(s) tarjeta(s) de red (ethernet normalmente) que ya tuviéramos en nuestro sistema: el demonio de PPP (pppd o ipppd) no reemplaza la ruta por defecto, es un problema muy común en los grupos de noticias y en los canales de Linux de IRC.

El síntoma es que la conexión se establece, pero no podemos salir a iNET porque no tenemos señalizado por dónde hacerlo. No es el propósito de este documento extenderse demasiado en temas de rutado, pero en condiciones normales, no necesitaremos ruta por defecto, podemos usar rutas estáticas; dejaremos que el (i)pppd la establezca cuando así sea necesario.

Y será uno de los scripts (ip-down) el que se encargará de que en todo momento haya una ruta por defecto a iNET por la tarjeta RDSI.

Scripts

Hace cosa de un mes fueron enviados a la lista de correo (¿aún no está suscrito? ¿a qué espera? ;-) del SLUG ( l-linux@calvo.teleco.ulpgc.es), de modo que si está suscrito y no borra los mensajes, imagino que los tendrá.

Pero como no todo el mundo está en dicha lista (y este Como, que duda cabe, no sería tal sin ellos), aquí van:

rc.isdn para un solo canal

#!/bin/sh
#
# Thanks to Rainer Birkenmaier
# Hacked by Antonio Verdejo Garcia
# & Francisco J Montilla

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

LOCAL_NUMBER="xxxxxxxxx"
REMOTE_NUMBER="xxx"
LOCAL_IP="195.76.154.169" # IP falsa por la que establecer ruta por
# defecto, a fin de que salte el DoD
DEVICE="ippp0"
USER="user@ISP"

isdnctrl addif $DEVICE # Creamos un interfaz nuevo,'DEVICE'
isdnctrl addphone $DEVICE out $REMOTE_NUMBER # Numero al que llamar
isdnctrl eaz $DEVICE $LOCAL_NUMBER # EAZ: el numero de su RDSI
isdnctrl l2_prot $DEVICE hdlc # para PPP sincrono
isdnctrl l3_prot $DEVICE trans #
isdnctrl encap $DEVICE syncppp # encapsulacion de paquetes IP en
# en tramas PPP
isdnctrl huptimeout $DEVICE 300 # tiempo de inactividad tras el que
# desconectar: 300 sec. -> 5min
isdnctrl chargehup $DEVICE off # Colgar antes del siguiente paso
isdnctrl secure $DEVICE on # Aceptar llamadas de numeros
# autorizados solamente
ifconfig $DEVICE $LOCAL_IP
route add -net 195.76.154.0 $DEVICE
route add default $DEVICE

/sbin/ipppd user $USER remotename infovia -d defaultroute noipdefault \
ipcp-accept-local ipcp-accept-remote mru 1500 mtu 1500 lock -bsdcomp -pc -ac /dev/ippp0 &

las últimas dos líneas son una en realidad; puede indicar que se interprete como una sola tal y como se hace en el script con el \; o bien ponerlo en una sola línea sin retorno de carro.

Asegúrese de que ipppd está en /sbin si transcribe tal cual este script; si no es así, modifique el path en el script.

Vea la sección expl para una explicación acerca de qué parámetros ha de modificar y una explicación sobre este script.

rc.isdn para dos canales

#!/bin/sh
#
# Thanks to Rainer Birkenmaier
# Hacked by Antonio Verdejo Garcia

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

LOCAL_NUMBER="xxxxxxxxx"
REMOTE_NUMBER="xxx"
LOCAL_IP="195.76.154.169" # dummy; the IPCP negotiation overwrite it
DEVICE="ippp0"
USER="user@ISP"

# additional for channel bundling:
DEVICE1="ippp128"

isdnctrl addif $DEVICE # Create new interface 'DEVICE'
isdnctrl addphone $DEVICE out $REMOTE_NUMBER # Set outgoung phone-number
isdnctrl eaz $DEVICE $LOCAL_NUMBER # Set local EAZ ..
isdnctrl l2_prot $DEVICE hdlc # for sync PPP: set Level 2 to HDLC
isdnctrl l3_prot $DEVICE trans # not really necessary, 'trans' is default
isdnctrl encap $DEVICE syncppp # encap the IP Pakets in PPP frames
isdnctrl huptimeout $DEVICE 300 # Hangup-Timeout is 300 sec. -> 5 min
isdnctrl chargehup $DEVICE off # Hangup before next Charge-Info
isdnctrl secure $DEVICE on # Accept only configured phone-number

# additional for channel bundling:
isdnctrl addslave $DEVICE $DEVICE1 # Create new slave interface 'DEVICE1'
isdnctrl addphone $DEVICE1 out $REMOTE_NUMBER # Set outgoung phone-number
isdnctrl eaz $DEVICE1 $LOCAL_NUMBER # Set local EAZ ..
isdnctrl l2_prot $DEVICE1 hdlc # for sync PPP: set Level 2 to HDLC
isdnctrl l3_prot $DEVICE1 trans # not really necessary, 'trans' is default
isdnctrl encap $DEVICE1 syncppp # encap the IP Pakets in PPP frames
isdnctrl huptimeout $DEVICE1 300 # Hangup-Timeout is 300 sec. -> 5 min
isdnctrl chargehup $DEVICE1 off # Hangup before next Charge-Info
isdnctrl secure $DEVICE1 on # Accept only configured phone-number

ifconfig $DEVICE $LOCAL_IP
route add -net 195.76.154.0 $DEVICE
route add default $DEVICE

/sbin/ipppd user $USER remotename infovia -d defaultroute noipdefault ipcp-accept-local \
ipcp-accept-remote mru 1500 mtu 1500 +mp lock -bsdcomp -pc -ac /dev/ippp0 /dev/ippp1 &

Explicación de los scripts

Los scripts no necesitan demasiadas explicaciones. Sustituir user e ISP por su nombre de usuario y el nombre de su proveedor (pepe@arrakis por ejemplo) y poner los valores adecuados en LOCAL_NUMBER (el número de su RDSI) y en REMOTE_NUMBER (055 si usa Infovía).

La dirección de LOCAL_IP es una dirección falsa, la negociación IPCP la sobreescribe, pero por una simple razón de coherencia, conviene darle una IP válida del rango de su proveedor, y asignarle a ella la ruta por defecto, (lo mismo se aplica para la dirección de red de la ruta del final del script) esto es necesario para que funcione el DoD.

Las direcciones del ejemplo son de Intercom, pero valen de cualquier manera (funciona también usando las mismas con otros proveedores). Estas direcciones son las mismas que aparecen en los scripts ip-up e ip-down:

ip-up

#!/bin/sh
/sbin/route del default
/sbin/route add default ippp0

ip-down


#!/bin/sh
/sbin/route del default
/sbin/ifconfig ippp0 down
/sbin/ifconfig ippp0 195.176.154.169
/sbin/route add -net 195.176.154.0 ippp0
/sbin/route add default ippp0

Es posible que alguno de los comandos que aparecen en estos dos últimos guiones sean redundantes. De nuevo, estamos abiertos a sugerencias.

El rc.isdn de la sección isdn2 está preparado para el uso de dos canales y por lo tanto una conexión a 128 Kbps, usando uno de los canales como esclavo del primero. La opción +mp es necesaria en este caso, además de que haya seleccionado en la compilación del kernel, en la sección general de RDSI, Support Generic MP (RFC 1717). (Compruebe que exista la línea CONFIG_ISDN_MPP=y en el fichero /usr/src/linux/.config, que es donde se almacena por defecto la configuración del núcleo).

Tenga en cuenta que, como es lógico, pagará el doble... Aunque esto en empresas no suele ser un problema, cuidado en casa, o verá como las facturas de Telefónica tienden a infinito... ;-)

Para lanzar manualmente el segundo canal, ejecute isdnctrl addslave ippp128; colgará automáticamente tras un periodo sin tráfico, tardando lo que hayamos especificado en el parámetro huptimeout del rc.isdn (en segundos).

Con determinados proveedores no se nota demasiado el lanzar el segundo canal (Arrakis), con otros sin embargo, y también dependiendo del origen de nuestro tráfico, si se nota, y bastante...

Hay un demonio que se encarga de disparar/colgar el segundo canal según el tráfico y la saturación que detecte; puede obtenerse de http://www.compound.se.

En futuras versiones, tendrá sección propia; por ahora, si tiene un trabajo donde permitirse eso, se supone que tendrá nivel como para manejarse con él sin problemas.

Software de Aplicacion Imagenes



martes, 1 de julio de 2008

Proceso de creación de software

Se define como Proceso al conjunto ordenado de pasos a seguir para llegar a la solución de un problema, en este caso particular, para lograr la obtención de un producto software que resuelva el problema.

Ese proceso de creación de software puede llegar a ser muy complejo, dependiendo de su porte, características y criticidad del mismo. Por ejemplo la creación de un sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo programa (ejemplo: resolución de una ecuación de segundo orden), éste puede ser realizado por un solo programador (incluso aficionado) fácilmente. Es así que normalmente se dividen en tres categorías según su tamaño (lineas de codigo) y/o costo: de Pequeño, Mediano y Gran porte. Existen varias metodologías para estimarlo, una de las más populares es el sistema COCOMO que provee métodos y un software (programa) que calcula estimadamente todos los costos de producción en un "proyecto software" (relación horas/hombre, costo monetario, cantidad de líneas fuente de acuerdo a lenguaje usado, etc.).

Considerando los de gran porte, es necesario realizar tantas y tan complejas tareas, tanto técnicas, de gerenciamiento, fuerte gestión y análisis diversos (entre otras) que toda una ingeniería hace falta para su estudio y realización: es la ingenieria de software.

En tanto que en los de mediano porte, pequeños equipos de trabajo (incluso un avesado analista-programador solitario) puede realizar la tarea. Aunque, siempre en casos de mediano y gran porte (y a veces también en algunos de pequeño porte, según su complejidad), se deben seguir ciertas etapas que son necesarias para la construcción del software. Tales etapas, si bien deben existir, son flexibles en su forma de aplicación, de acuerdo a la metodología o Proceso de Desarrollo escogido y utilizado por el equipo de desarrollo o analista-programador solitario (si fuere el caso).

Los "procesos de desarrollo de software" poseen reglas preestablecidas, y deben ser aplicados en la creación del software de mediano y gran porte, ya que en caso contrario lo más seguro es que el proyecto o no logre concluir o termine sin cumplir los objetivos previstos y con variedad de fallos inaceptables (fracasan, en pocas palabras). Entre tales "procesos" los hay ágiles o livianos (ejemplo XP), pesados y lentos (ejemplo RUP) y variantes intermedias; y normalmente se aplican de acuerdo al tipo y porte y tipología del software a desarrollar, a criterio del líder (si lo hay) del equipo de desarrollo. Algunos de esos procesos son Extreme Programming (XP), Rational Unified Process (RUP), Feature Driven Development (FDD), etc.

Cualquiera sea el "proceso" utilizado y aplicado en un desarrollo de software (RUP, FDD, etc), y casi independientemente de él, siempre se debe aplicar un "Modelo de Ciclo de Vida".

Se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrazan y un 26% son totalmente exitosos. Cuando un proyecto fracasa, rara vez es debido a fallas técnicas, la principal causa de fallos y fracasos es la falta de aplicación de una buena metodología o proceso de desarrollo. Entre otras, una fuerte tendencia, desde hace pocas décadas, es mejorar las metodologías o procesos de desarrollo, o crear nuevas y concientizar a los profesionales en su utilización adecuada. Normalmente los especialistas en el estudio y desarrollo de estas áreas (metodologías) y afines (tales como modelos y hasta la gestión misma de los proyectos) son los Ingenieros en Software, es su orientación. Los especialistas en cualquier otra área de desarrollo informático (analista, programador, Lic. en Informática, Ingeniero en Informática, Ingeniero de Sistemas, etc.) normalmente aplican sus conocimientos especializados pero utilizando modelos, paradigmas y procesos ya elaborados.

Es común para el desarrollo de software de mediano porte que los equipos humanos involucrados apliquen sus propias metodologías, normalmente un híbrido de los procesos anteriores y a veces con criterios propios.

El proceso de desarrollo puede involucrar numerosas y variadas tareas, desde lo administrativo, pasando por lo técnico y hasta la gestión y el gerenciamiento. Pero casi rigurosamente siempre se cumplen ciertas etapas mínimas; las que se pueden resumir como sigue:


  • Captura (elicitacion) y Especificación de requisitos (ERS)
  • Análisis
  • Diseño
  • Codificación
  • Pruebas (unitarias y de integración)
  • Instalación y paso a Producción
  • Mantenimiento


En las anteriores etapas pueden variar ligeramente sus nombres o ser más globales, por ejemplo indicar como una única fase (a los fines documentales e interpretativos) el Análisis y el Diseño; o indicar como "Implementación" lo que está dicho como "Codificación"; pero en rigor, todas existen e incluyen, básicamente,las mismas tareas específicas.