wynton escribió:Uy uyuyuyuyu, si me prometes por la Gloria del Amarfilamiento que te vas a poner a desarrollar ese plug-in, me pongo yo a mi parte.
¿XML-RPC te va bien? Es que es un protocolo que aunque sobrecarga el flujo con las cabeceras http es muy sencillo y bastante extendido.
Hay dos grupos de datos que tienen que viajar hacia el cliente de alguna manera:
- Eventos de activo/inactivo.
- Niveles del pico-metro. Son diez datos por segundo por canal. Se puede disminuir incluso.
Se puede hacer polling cada cierto tiempo pero se puede implementar otra opción que es un doble enlace cliente-servidor. El cliente XML-RPC a la que se registra activa su propio servidor, y el servidor a la que recibe la conexión del cliente activa su propio cliente con ese servidor.
Incluso se pueden ofrecer ambas formas de enlace, de modo que el cliente decida como se conecta, aún perdiendo ciertas prestaciones.
El API disponible te lo pasaría documentado. Se podría implementar un cliente con funcionalidades reducidas (sin llegar a gestionar la parte de medida).
'Por la Gloria del Amarfilamiento!!!!' ¿Tienes un SB o un Transporter? Porque no creí que esto fuese a interesarte algo... Yo me comprometo a hacer el Plug-in, lo que no te puedo decir es en cuanto tiempo porque estoy muy liado y, dentro de poco, mucho más.
XML-RPC me parece genial como protocolo de control, pero sigo sin verlo claro para mandar los datos del picómetro. De momento he estado haciendo pruebas de rendimiento de los servidores XML-RPC más usados con Perl y Python, siendo este último un poco más rápido. El problema es que, lógicamente, la velocidad de XML-RPC va íntimamente ligada con la potencia de la máquina y yo creo que el objetivo sería correr DrCop con la mínima configuración posible; de hecho creo que las VIA EPIA son el objetivo natural.
No he podido hacer pruebas extensas pero con mi actual EPIA 5000 (533Mhz, SDRAM) teniendo el cliente y el servidor corriendo en la misma máquina y siendo el procedimiento remoto una simple suma, he consiguido de media unas 30 llamadas por segundo. En un P-IV a 2.8 (como servidor) unas 140 con el cliente y el servidor ya en diferentes máquinas. Si bien pudiera parecer suficiente para la EPIA (10/seg/ch) el rendimiento no es consistente, haciendo pausas que se reflejarían claramente en el cliente. Las implementaciones que he usado han sido Frontier para Perl y SimpleXMLRPCServer para Python, aunque seguro que exiten implementaciones más rápidas.
Sigo pensando que para los datos del picómetro lo ideal sería UDP. Así nos quitamos, no solo el overhead de HTTP sino el tiempo de 'parsing' del XML y la selección del procedimiento remoto. Mi idea de implementación sería la siguiente.
1) Cliente hace petición XML-RPC al servidor cuyos parametros son: IP del cliente y puerto UDP en el cliente que quedará a la escucha, además de otros posibles parámetros de inicialización.
2) Cliente lanza un thread que abrirá el socket quedandose a la escucha.
3) Servidor recibe peticion XML-RPC del cliente con sus datos de conexión.
4) Servidor lanza un thread que mandará los datos del picómetro al puerto del cliente especificado anteriormente.
5) Servidor puede aceptar una petición XML-RPC para parar el envío de datos del picómetro si no son necesarios en ese momento.
En este caso se usaría algo así como el doble enlace que has comentado. Si fuese XML-RPC puro (sin utilizar el socket UDP) no entiendo que función podría tener el doble enlace.
En una cosa estamos deacuerdo: para todo el control de DrCOP, XML-RPC es lo apropiado.
Otras cuestiones de diseño por discutir:
-¿Mono o multi cliente?
-Autenticación (teniendo en cuenta que XML-RPC es stateless)
Voy a ir mirando la arquitectura de plug-ins y librerías de SlimServer y a darle una vueltecita a Perl, que ya lo tengo más que olvidado
Cuéntame que te parece para ir concretando un poco el tema. En cuanto lo del API, de momento con una lista de procedimientos que tengas pensados con sus parámetros nos debería valer.
Un saludo,
J.
