The 3 different transport-modes with vaadin and push

vaadin introduced server-push-functionality with version 7.1 and it starts to be usable with the newer vaadin 7.2.x versions. vaadin uses the Atmosphere framework to support push. There are 3 different Transport-Modes which are totally different if you want to check the Request/Response-cycles. The Transports are not only used for server-push. If you activate push, the normal user-interactions are also handled with these transports. With this blog I want to show you the 3 different transport modes and their behavior including examples.

You can find the following examples on Github: https://github.com/ReuDa/vaadin-push-examples . If you want to try them out in Eclipse, just run mvn eclipse:eclipse and add it to a WTP server (tomcat 8 is working). To get the code working you have to use Java 7 or any higher version. There are 4 different UIs in this example:

1. NoPushUI – Not using Push – http://localhost:8080/vaadin-pushapp/nopush
2. LongpollingUI – Transport.LONG_POLLING – http://localhost:8080/vaadin-pushapp/longpolling
3. StreamingUI – Transport.STREAMING – http://localhost:8080/vaadin-pushapp/streaming
4. WebsocketUI – Transport.WEBSOCKET – http://localhost:8080/vaadin-pushapp/websocket

Initially I created these examples to re-check the solution for a vaadin-bug  that is fixed by now. That’s why there is a log for every Start- and End-Request. If you want to learn more about vaadin push, you can browse the Book of Vaadin .

Let’s have a look at the different transports. There are 2 Buttons in every UI-example. “Click me – Normal user interaction” starts a normal Request. “Click me – Server push in 2 seconds” stars a Thread which tries to modify the vaadin-UI and push it to the client after 2 seconds.

1. UI without Push

What you see is pretty simple:

• Click on first Button -> Browser starts Request, vaadin sends Respone, first “Hello World” is displayed
• Click on second Button -> Browser sends Request, vaadin fires ClickListener on Server and sends Response without any changes, because there is no Push in this example. The Thread manipulates the server-side UI model but it’s not pushed back to the client.
• After 2 seconds, click on the first Button -> same as first step, but the change from the background-thread is also transported to the client.

2. UI with Long Polling

• With Long Polling you always have one long-running GET-Request to the server. The server doesn’t write the Response, unless the server has to transport something to the client. If you look at the screenshot, the 3rd Request (POST) sends the information “button clicked” to the server. The Response is send immediately without any data. vaadin now calls the ClickListener and sends the answer to the client through the long-running GET-Request (2nd line, was open for 14,47 seconds). The client now displays the changes and creates a new GET-Request for the next changes.
• If you click on the second button, then the same thing as above is happening to transport the information “button clicked” to the server. Nevertheless, after 2 seconds the Background-Thread starts manipulating the server-side model and uses the open GET-Request to push these changes to the client. Again, the client is immediately starting a new GET-Request (line 6 and 7 in the screenshot)
• Even if you do nothing, you can still see that there is a new GET-Request every minute. The Atmosphere framework is creating a new “channel” to prevent network infrastructure or firewalls from killing the long requests.

3. UI with Streaming

• Streaming is quite similar to Long Polling, but it safes some Requests. The first POST-Request in the screenshot is a click on the first button. Processing is pretty easy. The client sends the “button clicked” information to the server and the server is writing to the response – BUT – it is using chunked-encoding and holds the response to reuse it later.
• If you click on the second button, the client creates a new POST-Request. The server closes the first response and uses the response from the second request from now on. After 2 seconds our Background-Thread starts to manipulate the UI and pushes the information to the client through the existing response with a new chunk of data. There can be even more than one push through this channel. The response is still not being closed, unless there is a new client request.

4. UI with Websockets

• After all these “workarounds”, Websockets are providing a real bidirectional solution. First the client sends a request to Upgrade:websocket. The Server responds with 101 Switching Protocols. From now on, we have a connection which will be used for all transports (client -> server and server -> client).
• Firebug is actually not showing Websocket-contents, but in Chromes Developer-Tools there is a tab “Frames” (see screenshot). Here you can see all the information, which are send through the websocket-connection.