what is exactly the name of the protocol that tornado uses?

[aliane abdelouahab]

hi,
sorry for that question, but when using a python file on internet, we
use: CGI (non supported by Nginx) or WSGI (which is the standard for
python) and uWSGI (which Ngnix supports) for Fast-CGI (the CGI with on
long process) and SCGI (simple CGI).... but

HOW DO WE CALL TORNADO? what does it use?
i've also asked the question on stackoverflow:
http://stackoverflow.com/questions/8427830/what-is-exactly-tornado

[Gavin M. Roy]

HTTP

[Didip Kerabat]

tornado can also be run as WSGI.

Sent from my iPhone

[aliane abdelouahab]

@Gavin: wsgi is also http no? and http is in general! but i want a
specification like cgi, wsgi, fastcgi....
@Didip: yes, but it's only for compatibility purpose and it will lose
the non-blocking feature :(

2011/12/8, Didip Kerabat <did...@gmail.com>:

[Gavin M. Roy]

The use I've seen is typically as a HTTP server with a reverse HTTP proxy in front of the Tornado application.

http://www.tornadoweb.org/documentation/overview.html#running-tornado-in-production

While Tornado supports WSGI, it's not the native strength of Tornado.

http://www.tornadoweb.org/documentation/overview.html#wsgi-and-google-appengine

[Андрей Григорьев]

Tornado is HTTP server. It uses HTTP.

09.12.2011 01:14, aliane abdelouahab пишет:

--
С уважением,
Андрей Григорьев

[David Birdsong]

TCP/IP and in many cases, ethernet.

does this help?

2011/12/8 Андрей Григорьев <and...@ei-grad.ru>:

[aliane abdelouahab]

yes, HTTP and TCP/IP are general, but what about the specific
protocol, for example we say that Werkzeug and Cherrypy are WSGI
servers, we can run Python or Perl scripts using a CGI or FastCGI, but
how the Python file served by Tornado is "served" using CGI? no, so
how? what's its exact name, it should have one no?

2011/12/9, David Birdsong <david.b...@gmail.com>:

[Sergey Koval]

You're mixing different things up.

1. WSGI interface defines how WSGI container (uwsgi, cherrypy running HTTP server, Werkzeug running development server, etc) will call your WSGI application. Tornado can expose your application through WSGI interface, but you will lose all asynchronous features.

2. Tornado can also serve your application through its built-in HTTP server. In this case, you need to setup reverse HTTP proxy in your nginx server.

3. If you want to have fun, you can wrap Tornado WSGI app through FastCGI container (by using fcgi.WSGIServer) and serve it through the FastCGI.

Serge.

2011/12/9 aliane abdelouahab <alabde...@gmail.com>

[aliane abdelouahab]

so tornado will serve python file as a "tornado way"?

2011/12/9, Sergey Koval <serge...@gmail.com>:

[Gavin M. Roy]

When writing Tornado applications, you are writing a HTTP server (like Apache, Nginx, Cherokee, Lighttpd) with application logic, say on port 8080 instead of port 80.

To serve it, it is recommended that you put a HTTP server like Apache, Nginx, Cherokee, Lighttpd in front of it acting as a reverse proxy to filter out malformed or otherwise bad requests so that the Tornado application does not see said requests. This approach also allows you to load balance multiple instances of a Tornado application running on different ports.

It is not a WSGI (this is a protocol that is used between web servers and applications) nor a CGI (likewise a protocol used between webservers and applications), it is a HTTP server.

You should do the base hello world example from http://www.tornadoweb.org/ it should clear things up considerably.

import tornado.ioloop
import tornado.web

class MainHandler(tornado.web.RequestHandler):
    def get(self):
        self.write("Hello, world")

application = tornado.web.Application([
    (r"/", MainHandler),
])

if __name__ == "__main__":
    application.listen(8888)
    tornado.ioloop.IOLoop.instance().start()

Visit http://localhost:8888 in your browser (or whatever the ip address is that you are running the tornado instance on is)

2011/12/9 aliane abdelouahab <alabde...@gmail.com>

[aliane abdelouahab]

ahhh!! now it's clear :D
so tornado uses its own way to serve python files (the faster way)
thank you again; and thank you also for that video:
http://pycon.blip.tv/file/4880705
it really a jewel, hope there will be others :p

2011/12/9, Gavin M. Roy <g...@myyearbook.com>:

> When writing Tornado applications, you are writing a HTTP server (like
> Apache, Nginx, Cherokee, Lighttpd) with application logic, say on port 8080
> instead of port 80.
>
> To serve it, it is recommended that you put a HTTP server like Apache,
> Nginx, Cherokee, Lighttpd in front of it acting as a reverse proxy to
> filter out malformed or otherwise bad requests so that the Tornado
> application does not see said requests. This approach also allows you to
> load balance multiple instances of a Tornado application running on
> different ports.
>
> It is not a WSGI (this is a protocol that is used between web servers and
> applications) nor a CGI (likewise a protocol used between webservers and
> applications), it is a HTTP server.
>
> You should do the base hello world example from

> http://www.tornadoweb.org/it should clear things up considerably.

[Cliff Wells]

On Fri, 2011-12-09 at 17:37 +0100, aliane abdelouahab wrote:
> so tornado will serve python file as a "tornado way"?

Tornado doesn't serve "Python files", at least not in the sense that
something like CGI does. Tornado is an application framework. You use
it to write an application, and then it serves data generated by that
application via HTTP. It won't just run random .py/.cgi files from a
directory. It runs Python *functions* that you embed in the Tornado
framework.

The "Tornado way" is HTTP. It uses the same protocol as say, Apache
does. You are looking for something that simply isn't there.

Cliff

[aliane abdelouahab]

so that's why i asked the question, to run the python file, tornado
must oblige the file to have some criteria?! and those ones are called
a protocol, because i took the example of cherrypy, cherrypy also is a
framework, and also a webserver, and they can be used separatly, and i
think tornado is used also in the separate way (as modules), so i just
wanted to know if there was a name of that protocol that tornado uses
:D

2011/12/9, Cliff Wells <cl...@develix.com>:

[David Birdsong]

On Fri, Dec 9, 2011 at 9:10 AM, aliane abdelouahab
<alabde...@gmail.com> wrote:
> so that's why i asked the question, to run the python file, tornado
> must oblige the file to have some criteria?! and those ones are called
> a protocol, because i took the example of cherrypy, cherrypy also is a
> framework, and also a webserver, and they can be used separatly, and i
> think tornado is used also in the separate way (as modules), so i just
> wanted to know if there was a name of that protocol that tornado uses
> :D

iostream protocol. there you go.

[aliane abdelouahab]

thank you, because i'm preparing a thesis where i'll use tornado, and
before that, i'll make an introduction about how python is used in
internet and because i'll talk about cgi, wsgi, fastcgi, uwsgi, scgi,
i must classify tornado on them, it will be illogic to not do that :D

2011/12/9, David Birdsong <david.b...@gmail.com>:

[Cliff Wells]

On Fri, 2011-12-09 at 18:10 +0100, aliane abdelouahab wrote:
> so that's why i asked the question, to run the python file, tornado
> must oblige the file to have some criteria?! and those ones are called
> a protocol, because i took the example of cherrypy, cherrypy also is a
> framework, and also a webserver, and they can be used separatly, and i
> think tornado is used also in the separate way (as modules), so i just
> wanted to know if there was a name of that protocol that tornado uses
> :D

Here is the protocol Tornado uses to "run a python file", and complete
reference to it:

http://docs.python.org/release/2.6.7/reference/simple_stmts.html#the-import-statement

As far as CherryPy goes, it is exactly the same as Tornado in this
regard. You are badly confusing how CherryPy and Tornado *execute* code
with how they present it to the client (which is often another HTTP
server/proxy). Because they are designed to be able to be run behind an
HTTP server (such as Apache or Nginx), they need a protocol to speak to
that server. In the case of Tornado, that protocol is HTTP. In the
case of CherryPy, it's also usually HTTP, but you can choose WSGI
instead.

Cliff

[aliane abdelouahab]

nowi get the idea :D
another question, or another clarification of my question:
cgi for python is bad, because each time a request is made, there is a
new interpreter in the ram, really bad!
wsgi and fastcgi solved that, so how many time python interpreter is
launched when there are lot of requests, only one time? (like in
fastcgi there is a long process)?

2011/12/9, Cliff Wells <cl...@develix.com>:

[Cliff Wells]

On Fri, 2011-12-09 at 21:14 +0100, aliane abdelouahab wrote:
> nowi get the idea :D
> another question, or another clarification of my question:
> cgi for python is bad, because each time a request is made, there is a
> new interpreter in the ram, really bad!
> wsgi and fastcgi solved that, so how many time python interpreter is
> launched when there are lot of requests, only one time? (like in
> fastcgi there is a long process)?

Generally it's a process per request. This is why those types of
solutions don't scale well. One must choose between allowing unbounded
concurrent connections and processes (and have unbounded RAM to allow
it), having a pool of handlers and let requests wait for one to become
free, or simply dropping requests when there aren't any available
handlers.

I suspect that most people use the pool of handlers model, since that
would seem to be the most robust.

Cliff

[aliane abdelouahab]

heu.....but sorry, so if it's a process per request, then it's like
CGI, then it's bad?! so how it can be good for a server! how it can
handle the so 10k problem?

2011/12/10, Cliff Wells <cl...@develix.com>:

[Cliff Wells]

On Sat, 2011-12-10 at 21:01 +0100, aliane abdelouahab wrote:
> heu.....but sorry, so if it's a process per request, then it's like
> CGI, then it's bad?! so how it can be good for a server! how it can
> handle the so 10k problem?

The difference is that it's a long-running process per request vs
starting a new Python interpreter for every request.

Cliff

[aliane abdelouahab]

am sorry if i'm a little bit hard to understand, but isent something
like FastCGI?

[Cliff Wells]

On Sat, 2011-12-10 at 23:17 -0800, aliane abdelouahab wrote:
> am sorry if i'm a little bit hard to understand, but isent something
> like FastCGI?

Yes. FastCGI is more efficient than CGI since the interpreter doesn't
need to be loaded fresh for every request. Still, FastCGI applications
tend to utilize process-based concurrency models so scalability tends to
be limited (it's possible to write async apps using FCGI, but for some
reason it isn't popular, probably because HTTP is simpler).

WSGI was supposed to develop an async interface, but last I heard (a few
years ago), the idea was ditched due to requiring backwards-incompatible
changes to the API.

Cliff

[aliane abdelouahab]

now i see the idea in the clear side!
thank you for the help!
about WSGI, is it the WEB3 project? http://www.python.org/dev/peps/pep-0444/
or http://mail.python.org/pipermail/web-sig/2011-January/004871.html

[Joe Bowman]

In the standard install where you are using the httpserver module and such Tornadbo

 - binds to a tcp port configured by the application

 - accepts standard HTTP requests which are parsed by the httpserver python application

 - generates a response using python

 - pushes the response out via the tcp connection established with the browser

In a CGI set up

 - Another web server (ie: apache) binds and accepts connections

 - Due to the web server configuration it will pass the request to the tornado application via CGI

 - Tornado will process the request using python

 - Will generate the response using python

 - delivers the response to the intermediary web server which then sends it to the browser

When people are talking about using proxy servers they are speaking about using Tornado is the first example. 

One of the biggest advantages to Tornado is it's use of event loop to manage requests. This means it can concurrently support multiple requests at a time within the same process/thread.  With python applications being generally locked to a single process due to GIL an example of a deployment would be

Tornado app running on port 8080

Tornado app running on port 8081

Webserver like apache or nginx on port 80 that load balances requests to the two Tornado instances. Tornado would also be a little slower at serving static files, so you could configure that apache or nginx instance to handle static files like images and such. This isn't required however, you can serve static files easily with Tornado as well. 

Tornado does in a general application development framework, which is why it might be useful in CGI mode. However my opinion is it's best to take advantage of the httpserver module and just proxy it. The one place I can see needing the CGI implementation is Google's Appengine where you have to use CGI. The Tornado framework is very simple to work with and is better than Googles simple web framework. If you're hosting your own server instance, then I'd just use httpserver and nginx proxy as that's the more documented and discussed solution. Deploying it that way will make it easier for you to get help from the community, since you're just starting out.

They key statement you're making that might be confusing people is "serving python files". Think of it more this way. Tornado accepts an http request and responds with an http response. There is no python file being served, it's all dynamically generated html.

Hope this helps.

[aliane abdelouahab]

@Joe wooooooooooow!! thank you !!! it gives me valuables informations
that i'll put in the thesis! thank you again!