i want to know tornado's internal workflow, and have seen this article, it's great, but something i just can't figure out
within the ioloop.py, there is such a function
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)
so what's this mean? every request will trigger add_handler or it's just triggered once when init?
every socket connect will generate a file descriptor , or it's just generated once?
what's the relationship between ioloop and iostream ?
how does httpserver work with ioloop and iostream ?
is there any workflow chart, so i can see it clearly ?
sorry for these questiones, i just confused
any link, suggestion, tip helps. many thanks :)
In Tornado 6.0, IOLoop is a wrapper around the asyncio event loop, with a slightly different interface. The IOLoop interface is now provided primarily for backwards compatibility; new code should generally use the asyncio event loop interface directly.
Tornado is a Python web framework and asynchronous network library, originally developed at FriendFreed. Tornado uses non-blocking network-io. Due to this, it can handle thousands of active server connections. It is a saviour for applications where long polling and a large number of active connections are maintained.
If using Ubuntu, open a terminal and type python . Then import tornado and the write command tornado. version . You will get output like '4.2.
If you want to daemonize tornado - use supervisord. If you want to access tornado on address like http://mylocal.dev/ - you should look at nginx and use it like reverse proxy. And on specific port it can be binded like in Lafada's answer.
I'll see if I can answer your questions in order:
Here _impl
is whichever socket polling mechanism is available, epoll
on Linux, select
on Windows. So self._impl.register(fd, events | self.ERROR)
passes the "wait for some event" request to the underlying operating system, also specifically including error events.
When run, the HTTPServer
will register sockets to accept connections on, using IOLoop.add_handler()
. When connections are accepted, they will generate more communication sockets, which will likely also add event handlers via an IOStream
, which may also call add_handler()
. So new handlers will be added both at the beginning, and as connections are recieved.
Yes, every new socket connection will have a unique file descriptor. The original socket the HTTPServer
is listening on should keep its file descriptor though. File descriptors are provided by the operating system.
The IOLoop
handles events to do with the sockets, for example whether they have data available to be read, whether they may be written to, and whether an error has occured. By using operating system services such as epoll
or select
, it can do this very efficiently.
An IOStream
handles streaming data over a single connection, and uses the IOLoop
to do this asynchronously. For example an IOStream
can read as much data as is available, then use IOLoop.add_handler()
to wait until more data is available.
On listen()
, the HTTPServer
creates a socket which it uses to listen for connections using the IOLoop
. When a connection is obtained, it uses socket.accept()
to create a new socket which is then used for communicating with the client using a new HTTPConnection
.
The HTTPConnection
uses an IOStream
to transfer data to or from the client. This IOStream
uses the IOLoop
to do this in an asynchronous and non-blocking way. Many IOStream
and HTTPConnection
objects can be active at once, all using the same IOLoop
.
I hope this answers some of your questions. I don't know of a good structural chart, but the overall idea should be fairly similar for other webservers too, so there might be some good info around. That in-depth article you linked to did look pretty useful, so if you understand enough I'd recommend giving it another go :).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With