Reconocimiento de tokens de una er ya insertada en la estructura

Hasta ahora el automática nos decía si una cadena cumplía alguna o varias de las expresiones regulares que con anterioridad habían sido procesadas. Lo que no nos decía era cuales habían sido los tokens que había reconocido hasta llegar a los estados finales.

Si por ejemplo:

- palabra: sucesión de símbolos del alfabeto.

- parámetro: puede ser a su vez:
    - seguido de letra
    Número natural

- espacio: un espacio en blanco

Y la expresión comando = ((palabra)(espacio)*)+((palabra)(espacio)((parametro)(parametro)*(espacio)*)

Si le pasamos la cadena 'algo' devolverá 'palabra' y 'comando'. Si se le pasa 'algo -p 1234 -k' nos devolverá 'comando'

Pero ¿y si queremos averiguar sus tokens? En función de sus parámetros nuestra aplicación que utilice este comando podrá hacer una cosa u otra.

Me he basado en el autómata de la versión 2. Este era simple: no trabajaba con hilos ni tenía grafo para las dependencias entre las expresiones regulares.  Después lo implementaré en la versión más reciente, pero ahora he creído más conveniente usar un código más sencillo al tener que tocar el núcleo del autómata.

Lo primero de que me percaté fue que reconocía de más.  12/ me decía que era un número fraccionario. El fallo lo localicé cuando pasaba de un ANDF_LANDA  a AFD al reconocer los estados finales añadía transiciones landa de más.  Queda solucionado.

Lo que se me ocurrió para que reconociese los tokens fue que según se recorre el autómata reconociendo los estados con el carácter correspondiente pudiéramos saber si ese estado concreto pertenece a una sub expresión concreta. Si recordamos la estructura general era un ANDF_LANDA que desde su estado 0 salían transiciones landa a AFD mínimos, una por cada  er. Esto significa que para nuestro ejemplo existirá un autómata mínimo del que su estado final nos dirá que es un comando. El problema es que es mínimo, observando sus estados es imposible saber donde comenzaba o terminaba una sub expresión. 

La solución era evidente, trabajar con otra ANDF_LANDA  que conecte las sub expresiones.

Conforme vaya generándose, cuando inserte, concatene o realice el producto de las sub expresiones irá almacenado y actualizando recursivamente el número de estado que justo en ese momento empieza.

Lo mejor de todo es que las sub expresiones ya están en los diccionarios del autómata y siendo mínimos.

Modificando el código he obtenido una función del autómata que pasándole el nombre de la expresión regular y la cadena a reconocer, nos devuelva una lista de tokens.

Ahora nos informa que [0-3 palabra] [4 - 10 parámetro] [ 12 - 18 parametro]. Significa que según se reconozca la cadena y el número del estado en el que se encuentra en ese momento, ahora podemos saber qué está en ese instante reconociendo.  Si está en el estado 2 está reconociendo el token palabra.

En nuestro ejemplo nos daría una palabra de valor 'algo', un parámetro de valor '-p ', otro parámetro de valor '1234 ' y por último otro con valor '-k'.

Notar que los dos primeros parámetros contienen espacios en blanco (porque así está definido según si er), para saber el valor del número habría que repetir la operación: autómata. GetTokens ("parametro","1234 "), obtendría el autómata especial que hemos descrito y como resultado sería un único token número natural de valor '1234'.

Y ya nos devuelve los tokens de una cadena dada su expresión regular.

Antes de empezar... reorganizar

Esta noche, para evitar que me entrara sueño en el trabajo, me ha dado por pensar un poco en la aplicación y he llegado a la conclusión de que siguiendo el planteamiento que entradas anteriores propuse para seguir avanzando, se pueden cambiar de lugar algunos conceptos.

Le voy a dar más peso al Lanzador. Me refiero a que éste será el que haga de Oyente, el que haga de Coordinador cuando le corresponda y de servidor de actualizaciones.

Pero aún se me han ocurrido más cosas. Sería ideal llegar con un nuevo equipo, conectarme a la red y mediante Telnet conectarme al puerto Oyente de algún participante del que ya conozca su IP (no necesariamente debe de ser el Coordinador). Una vez conectado habría una conversación entre ese participante y yo en el que me solicitaría el nombre mi nombre de usuario del equipo en el que estoy. Con esta información y usando el Participante el comando scp, usuario y mi IP podrá enviarme el Lanzador.

Pero más aún, he leído cómo generar claves públicas para poderlas usar con SSH de modo que si el Coordinador quiere ejecutar comandos remotos en el resto de los participantes sin estar escribiendo las claves contínuamente, a la vez que se envía el Lanzador se podría enviar las claves públicas correspondientes. Aunque tendría que ver qué pasa cuando cambia un participante de rol y deja de ser Coordinador para serlo otro, supongo que copiando las claves públicas y privadas del antiguo Coordinador al nuevo, funcionaría. No lo sé, habrá que comprobarlo.

Si esto funciona, tras recibir el Lanzador y las claves para que el Coordinador pueda ejecutar comandos remotos sobre mi equipo, podría lanzarme automáticamente el Lanzador y cerrarme la conexión Telnet ya obsoleta. Éste, al ejecutarse por primera vez se percatará de que no tiene la aplicación GR y a través del servicio de actualización de código que ahora ha asumido el Lanzador, lo descargará en mi equipo.

Si consigo programarlo así, simplemente conectandome a un Participante cualquiera obtendría el Lanzador y a través de éste de modo automático, el GR y el Coordinador me generará las claves públicas y privadas para  controlarme remotamente.

Según creo que he entendido, aunque las claves son para evitar estar escribiendo la password del usuario cada vez que se pretenda realizar un ssh, por lo menos una vez (para poder generar las claves) sí es necesario escribirlo. Lo que tengo que pensar es cómo pasar la contraseña de mi equipo al Coordinador de forma segura. Ya veremos, sobre la marcha.