2011-08-16 5 views
24

Quiero saber flujo de trabajo interno del tornado, y han visto this article, es muy bueno, pero algo que simplemente no puede averiguar¿cuál es el tornado ioloop y el flujo de trabajo del tornado?

dentro del ioloop.py, hay una función de este tipo

def add_handler(self, fd, handler, events): 
    """Registers the given handler to receive the given events for fd.""" 
    self._handlers[fd] = handler 
    self._impl.register(fd, events | self.ERROR) 

por lo ¿que significa esto? cada solicitud activará add_handler o simplemente se activa una vez cuando init?

cada socket connect generará un descriptor de archivo, o solo se genera una vez?

¿Cuál es la relación entre ioloop y iostream?

¿cómo funciona httpserver con ioloop y iostream?

¿hay algún gráfico de flujo de trabajo, así que puedo verlo claramente?

pena por estas questiones, i confundido

estos vínculos, sugerencia, sugestión ayuda. muchas gracias :)

Respuesta

29

Voy a ver si puedo responder a sus preguntas con el fin de:

  • Aquí es lo que _impl mecanismo de toma de votación está disponible, epoll en Linux, select en Windows. Por lo tanto, self._impl.register(fd, events | self.ERROR) pasa la solicitud "esperar por algún evento" al sistema operativo subyacente, que también incluye específicamente eventos de error.

    Cuando se ejecuta, el HTTPServer registrará sockets para aceptar conexiones, usando IOLoop.add_handler(). Cuando se aceptan conexiones, generarán más sockets de comunicación, lo que probablemente también agregue controladores de eventos a través de un IOStream, que también puede llamar al add_handler(). Por lo tanto, se agregarán nuevos controladores al principio y a medida que se reciban las conexiones.

  • Sí, cada nueva conexión de socket tendrá un descriptor de archivo único. El socket original en el que está escuchando el HTTPServer debe mantener su descriptor de archivo. Las descripciones de archivos son provistas por el sistema operativo.

  • El IOLoop maneja eventos relacionados con los sockets, por ejemplo, si tienen datos para leer, si se pueden escribir y si se ha producido un error. Al usar servicios del sistema operativo como epoll o select, puede hacerlo de manera muy eficiente.

    Un IOStream maneja el flujo de datos a través de una sola conexión, y utiliza el IOLoop hacer esto de forma asíncrona. Por ejemplo, un IOStream puede leer tantos datos como estén disponibles, luego use IOLoop.add_handler() para esperar hasta que haya más datos disponibles.

  • En listen(), HTTPServer crea un socket que utiliza para escuchar conexiones usando IOLoop. Cuando se obtiene una conexión, usa socket.accept() para crear un nuevo socket que luego se usa para comunicarse con el cliente usando un nuevo HTTPConnection.

    El HTTPConnection utiliza un IOStream para transferir datos hacia o desde el cliente. Este IOStream usa el IOLoop para hacer esto de forma asíncrona y sin bloqueo. Muchos objetos IOStream y HTTPConnection pueden estar activos a la vez, todos usan el mismo IOLoop.

Espero que responda algunas de sus preguntas. No sé de un buen cuadro estructural, pero la idea general debería ser bastante similar para otros servidores web también, por lo que podría haber alguna buena información. Ese artículo en profundidad con el que te vinculaste se ve bastante útil, así que si entiendes lo suficiente, te recomendaría darle otra oportunidad :).

+0

"generarán más sockets de comunicación", son los sockets linux sockets internos (sockets de dominio de Unix)? – limboy

+1

@ Izyy Creo que son "sockets de internet" (del tipo socket.AF_INET en python). Wikipedia tiene buena información. El zócalo principal de escucha solo tendrá una dirección de recepción + puerto, pero cada nuevo zócalo de comunicación tendrá una dirección + puerto local y remoto, lo que les permitirá aplicar de forma exclusiva a cada conexión de cliente, aunque tengan la misma dirección local en el servidor . Aunque no estoy seguro de los detalles de implementación exactos :). – mesilliac

+0

gracias por su explicación :) – limboy