Which web servers are compatible with gevent and how do the two relate?

Question

I'm looking to start a web project using Flask and its SocketIO plugin, which depends on gevent (something something greenlets), but I don't understand how gevent relates to the webserver. Does using gevent restrict my server choice at all? How does it relate to the different levels of web servers that we have in python (e.g. Nginx/Apache, Gunicorn)?

Thanks for the insight.

Answer 1

First, lets clarify what we are talking about:

• gevent is a library to allow the programming of event loops easily. It is a way to immediately return responses without "blocking" the requester.

• socket.io is a javascript library create clients that can maintain permanent connections to servers, which send events. Then, the library can react to these events.

• greenlet think of this a thread. A way to launch multiple workers that do some tasks.

A highly simplified overview of the entire process follows:

Imagine you are creating a chat client.

You need a way to notify the user's screens when anyone types a message. For this to happen, you need someway to tell all the users when a new message is there to be displayed. That's what socket.io does. You can think of it like a radio that is tuned to a particular frequency. Whenever someone transmits on this frequency, the code does something. In the case of the chat program, it adds the message to the chat box window.

Of course, if you have a radio tuned to a frequency (your client), then you need a radio station/dj to transmit on this frequency. Here is where your flask code comes in. It will create "rooms" and then transmit messages. The clients listen for these messages.

You can also write the server-side ("radio station") code in socket.io using node, but that is out of scope here.

The problem here is that traditionally - a web server works like this:

1. A user types an address into a browser, and hits enter (or go).
2. The browser reads the web address, and then using the DNS system, finds the IP address of the server.
3. It creates a connection to the server, and then sends a request.
4. The webserver accepts the request.
5. It does some work, or launches some process (depending on the type of request).
6. It prepares (or receives) a response from the process.
7. It sends the response to the client.
8. It closes the connection.

Between 3 and 8, the client (the browser) is waiting for a response - it is blocked from doing anything else. So if there is a problem somewhere, like say, some server side script is taking too long to process the request, the browser stays stuck on the white page with the loading icon spinning. It can't do anything until the entire process completes. This is just how the web was designed to work.

This kind of 'blocking' architecture works well for 1-to-1 communication. However, for multiple people to keep updated, this blocking doesn't work.

The event libraries (gevent) help with this because they accept and will not block the client; they immediately send a response and when the process is complete.

Your application, however, still needs to notify the client. However, as the connection is closed - you don't have a way to contact the client back.

In order to notify the client and to make sure the client doesn't need to "refresh", a permanent connection should be open - that's what socket.io does. It opens a permanent connection, and is always listening for messages.

1. So work request comes in from one end - is accepted.
2. The work is executed and a response is generated by something else (it could be a the same program or another program).
3. Then, a notification is sent "hey, I'm done with your request - here is the response".
4. The person from step 1, listens for this message and then does something.

Underneath is all is WebSocket a new full-duplex protocol that enables all this radio/dj functionality.

Things common between WebSockets and HTTP:

1. Work on the same port (80)
2. WebSocket requests start off as HTTP requests for the handshake (an upgrade header), but then shift over to the WebSocket protocol - at which point the connection is handed off to a websocket-compatible server.

All your traditional web server has to do is listen for this handshake request, acknowledge it, and then pass the request on to a websocket-compatible server - just like any other normal proxy request.

• For Apache, you can use mod_proxy_wstunnel
• For nginx versions 1.3+ have websocket support built-in