openstack/zaqar-specs
Code Issues Proposed changes
96358f7814
zaqar-specs/specs/kilo/persistent-transport.rst
wangxiyuan d2714f739e Fix py27 CI failure 
the py27 CI failed due to tox 2.5.0 release. The command
in tox.ini is required now[1].

This patch refactored the code tree to make CI work.

[1]:
1e888ce9b8/CHANGELOG (L40)

Change-Id: Icd90598367e3b529e64d184e78b144e4d075b9a3
2016-11-24 16:28:03 +13:00

4.2 KiB
Raw 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