Nuevo tipo de transporte y lector en Twisted

Question

Estoy tratando de agregar un nuevo transporte a Twisted, que leerá los datos de una secuencia, ya sea un archivo de una manera tail -f , o desde una tubería, pero tengo algunos problemas con arquitectura retorcida.

Tengo el transporte en sí (implementa ITransport ) listo: maneja todas las aperturas de archivos. Tengo listas las funciones de transmisión / aplazado. ¿Cómo lo preparo ahora? Me gustaría informar los nuevos datos a los dataReceived () de algunos protocolos.

Por supuesto, podría crear un nuevo objeto que configurará los monitores de E / S con las devoluciones de llamada adecuadas, registrará una devolución de llamada al apagar el reactor (para cerrar los archivos / protocolos) e iniciará todo manualmente, pero es eso " la forma correcta? ¿Hay alguna mejor abstracción que pueda usar? He visto reactor.connectWith () , pero en realidad no proporciona mucha abstracción ...

Además, ¿cómo se supone que debo pasar los datos de mi lector al protocolo? ITransport no define ninguna interfaz para él, a pesar de que parece exactamente la responsabilidad del transporte.

Answer 1

Parece que en su mayoría has descubierto cómo hacer esto. Puede que le interese twisted.internet.fdesc.readFromFD , pero solo tiene unas pocas líneas y no está haciendo nada particularmente complicado (sin embargo, son algunas líneas que no tiene que mantener). Aparte de eso, sí, debe hacer el monitoreo de E / S en este caso, porque los descriptores de archivos regulares no son compatibles con select / poll / epoll (siempre se informan como listos, no lo que desea).

Se ha realizado algún trabajo para admitir inotify en Twisted ( http://twistedmatrix.com/trac/ticket / 972 ) pero esto aún no está completo, por lo que no te será directamente útil ahora (a menos que quieras ayudar a terminarlo y luego usarlo). Suponiendo que solo usa encuestas basadas en el tiempo, gran parte de lo que hay en el reactor no lo ayudará mucho, ya que ese código se centra en usar una API de preparación proporcionada por el sistema (es decir, seleccionar / sondear / epoll) para activar eventos .

Sin embargo, para el caso de la tubería, debería poder usar y beneficiarse de los métodos de IReactorFDSet - addReader et al.

Su transporte de sondeo basado en el tiempo aún puede beneficiarse de la implementación de ITransport , aunque no estoy seguro de cómo implementaría write para un tail -f -como el transporte. Definitivamente se beneficiará de que su transporte entregue datos a través de la interfaz IProtocol , ya que esto simplifica la reutilización del código. IProtocol.dataReceived es exactamente cómo desea pasar los datos de su lector (creo que es lo mismo que su transporte , ¿no es así? ) Esto no está definido en ITransport porque es un método que se llama en otro objeto que no es el transporte.

reactor.connectWith probablemente no te va a comprar nada. Como dices, no es una gran abstracción; Yo diría que es más un error. :)

No se preocupe demasiado por no poder agregar métodos directamente al reactor. Una función libre que acepta un reactor como parámetro es igual de fácil de usar.

Para la devolución de llamada de apagado, addReader debería llevarte a la mayor parte del camino. Cualquier lector en el reactor en el momento del apagado tendrá connectionLost llamado (parte de IFileDescriptor ). Debe implementar esto para limpiar los archivos y el protocolo.