Add websocket subprovider

This would allow push updates, and compatibility with Web3 1.0.

Updated March 22, 2018 to help potential new contributors make sense of this issue:

Provider engine is a system for composing middleware objects (which we call subproviders) into a potentially complex system for managing the response to a given request object.

ProviderEngine itself is also an Ethereum Provider, as in web3.currentProvider, so once composed with middleware, it exposes the standard sendAsync() method for Ethereum developers to make requests of the JSON RPC API.

When calling providerEngine.sendAsync(yourOpts, callbackFunction), those options you pass in get passed from one middleware object to the next. You can see how here.

As you can see, each provider is passed the same options object, potentially mutating it, and with a pair of callback functions to either end the response immediately, or to pass the options on to the next provider.

To operate as a subprovider, an object only needs to expose a function handleRequest (options, next, end), as you can see here in the fetch subprovider.

In that function, the subprovider can mutate the options freely, and then either call the next() or end() functions.

next() is only used by true “middleware” subproviders, to pass the options to the next subprovider. That function will not be needed for this feature.

The end() function represents the result that will be returned to the ProviderEngine consumer, and should follow the JavaScript API specification, including its JSON-RPC style error format.

The Fetch Subprovider is how MetaMask currently talks to an Ethereum node. It uses the fetch API, which is pure HTTP, to make requests of whatever RPC it is pointed at.

This issue is to create a similar subprovider, but one that uses Websockets instead of HTTP, and uses the Geth Websocket API instead of the usual HTTP-based JSON RPC API. The request/response format should otherwise be basically identical.

Further Goals

There are other goals that are often associated with this one, which can make it seem more complicated, but are actually separate deliverables.

Websocket Block Tracker

Right now the way MetaMask keeps track of the current block is also via HTTP, via the eth-block-tracker module. We could definitely also improve performance by moving that over to websockets, or making a websocket version of it.

Websocket Based Subscriptions

While #207 adds a subprovider for providing the providerEngine.subscribe() API, it does this with polling under the hood. This API would be much more performant if its functionality were moved into the websocket subprovider.

[danfinlay]

@pablasso I don’t think so. While #207 adds a websocket-based block-subscription subprovider, it only uses websockets for block subscription.

This issue would be for a full websocket subprovider, fully replacing all of the roles currently performed by the fetch subprovider.

[ryan-rowland]

@matthewlilley I left comments on your commit. Open a PR next time please. 😄

@lazaridiscom Sorry I won’t be a position to test any time this week.