melissaml cba0a9cf8e Rename review.openstack.org to review.opendev.org

There are many references to review.openstack.org, and while the
redirect should work, we can also go ahead and fix them.

Change-Id: I397b58c562079444553d393387d7c6323b06fba4

2019-05-13 20:17:59 +08:00

4.2 KiB

Raw Permalink Blame History

Persistent transport

Persistent connections allow a single TCP connection to send and receive multiple requests/responses instead of opening a new TCP connection for each pair. When an application opens fewer TCP connections and keeps them open for a longer period, it causes less network traffic, use less time establishing new connections, and allows the TCP protocol to work more efficiently.

Currently Zaqar has support for a non-persistent transport, leaving aside some use cases that would be covered in a more efficient and reliable way with a persistent transport solution.

Some use cases that will be positively impacted by this change are:

Communication with browsers: Websockets will enhance the communication between browsers and Zaqar, a key factor in the integration of Zaqar with the OpenStack Dashboard (Horizon).
Notifications: this type of transport will constitute a better protocol for notifications, a feature planned for Kilo as well.

https://blueprints.launchpad.net/zaqar/+spec/persistent-transport

Problem description

Currently there is no way to establish persistent connections in Zaqar. This spec proposes adding this feature through a websockets implementation.

Proposed change

The proposed change, as stated in previous sections, is to add a persistent transport alternative to Zaqar. This can be done by using websockets.

Websockets provide a full-duplex communication channel operating over a single socket that will remove overhead and significantly reduce complexity.

Currently the tranport layer in Zaqar is tightly bound to the WSGI transport, making this addition a complex task.

Fallback

In case WebSockets are not available, the client will fallback to short-polling the REST API.

Some of the reasons of WebSockets not being available are:

Firewalls could be configured to kill HTTP connections after a certain amount of time.
Concerns from a security standpoint will lead to killing any traffic over port 80 or 443 that doesn't look like HTTP.

Messages serialization

A serialization technology is needed in order to transport data. There are several alternatives, including MsgPack, Protobuf, Apache Avro and Cap'n Proto.

Given that a high priority is being given to browsers compatibility, MsgPack is the best choice between those. Remaining alternatives doesn't have out-of-the-box Javascript support, making it harder to ensure compatibility with most web applications.

Alternatives

Establish persistent connections enabling WSGI keep-alive
Long polling

Implementation

Assignee(s)

Primary assignee: vkmc

Secondary assignee: cpallares

Milestones

Target Milestone for completion: < K-1

Work Items

Implement the common API layer
Define the wire protocol for persistent transports
Implement the driver
Implement queues and messages controller
Implement claims controller
Implement pools, flavors and stats controllers

WebSocket Libraries

After discussing several alternatives, including SockJS, SocketIO, Autobahn, ws4py and Tornado, it has been decided that ws4py is going to be used to implement this feature. More details on this decision will be available in the WebSockets wiki.

Dependencies

Note

This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode

4.2 KiB Raw Permalink Blame History