Por lo que veo si quiero dedicar mas tiempo de nómina al analizador de código será via un cambio de licencia. El proyecto puede servir para el software SaaS que estamos usando, así que habrá mas respaldo usandolo como LGPL que como GPL, eso si, versión 2.

Por otra parte ayer instalé una Maquina virtual con XP para pruebas del tunneling en el windows 7. No me gustan las máquinas virtuales, pero como necesito acceso a ciertos correos de outlook express por las pruebas, no se puede hacer con windows 7. Así que en el windows xp irá outlook express.

Noté que por no estar usando lightspeed, en ocasiones algunos procesos de apache usan cada uno 6% de CPU en el servidor.

Actividades autoasignadas de hoy:
1 ) Terminar el analizador de Reporte de TD, porque la información origen viene dañada.
2 ) Instalar Tunneling.
3 ) Preferentemente avanzar en el mecanismo de parser

La perdida de paquetes de ayer no coincide con lo que yo emití.

¿Tendremos una PC en modo promiscuo respondiendo paquetes ajenos?

Haciendo una revisión por encima, el hecho que usemos redes WAN crea ruido en el sentido que no toda la señal se está utilizando, y los problemas de celulares y la zona pueden ser de saturación.

Se me ocurren dos alternativas:

1 ) Tunneling via un file_get_contents sobre un servidor con timeout de 5 minutos. Si el problema es sniffer o interferencia debe mejorarse. Lo que si es que no tenemos autoridad para cambiar la contraseña del hub, y tampoco creo que sea el problema. La instrucción debería ser un CPM para ver si hay modo promiscuo activado en la red.

2 )E-go.

A final de cuentas el problema no se ve bien, y es solo del recurso técnico, vamos a seguir con problemas secundarios como los cambios de organigrama.

Si no usan los principios básicos de la dirección, menos pueden controlar los recursos de la red. Así que una vez mas la medida provisional es hacer enlaces para quitar los parásitos.