Websockets transport and asyncio

mami-project / mplane-sdk

mPlane protocol software development kit

1 stars 0 forks source link

Websockets transport and asyncio #7

Open britram opened 8 years ago

britram commented 8 years ago

HTTP is a bad fit for message-exchange protocols like mPlane. Websockets is probably a better one, giving us framing, security, and get-through-web-only-firewallness, and will allow for browser-based native clients and components in the future more easily than HTTP does.

Design and implement new websockets client and component, which allows either the client or component to initiate connections. This will require us to use Tulip/asyncio as opposed to Tornado, since the maintained/tested websockets lib is asyncio-based.

Add a section describing Websockets transport in detail to the protocol specification. Consider deprecating HTTP if this works.

britram commented 8 years ago

We can use this an an excuse to build alternate client/component implementations for Python 3.5's asyncio (yay! shiny!)

async_component.py: an asyncio runloop-integrated component. This seems pretty straightforward.
async_client.py: an asyncio runloop-integrated client. Not sure how this integrates with e.g. mpcli.

As with HTTP, both component and client should be able to take listener (websockets server) and initiator (websockets client) roles. Unlike with HTTP:

initiators are responsible for maintaining an open connection to listeners when necessary, and to retry in case of failure.
when a listener cannot send a message it wants to an initiator, it must queue it and wait for the initiator to reconnect.

Callbacks go away in this world. Yay!

britram commented 8 years ago

Not clear how well asyncio plays with multithreading, which means we may need to reimplement Scheduler to be async, as well.

britram commented 8 years ago

May need to patch websockets to allow us to get access to the stream transport's underlying peer certificate for SSL.

britram commented 8 years ago

Since we're pulling Service into mplane.component (and changing it to be coroutine-based), as well as making Job just go away (should be replaced by mplane.component entry points for scheduling and descheduling tasks), do #13 at the same time.