Support WebSocket as a transport for the RPC.

[MicahZoltu]

Geth and Parity both support WebSockets (to some extent) for the transport layer for the Ethereum RPC. It would be nice if TestRPC also supported WebSockets so one can test using it when writing an app that communicates via WebSockets.

[onbjerg]

Hey! I see you've opened up a PR for this - any blockers I could help with?

[MicahZoltu]

No idea, the PR was from 6 months ago and I ended up not using TestRPC for what I needed, so I haven't been following it at all.

[munawarb]

@onbjerg and @MicahZoltu Do you guys know of any alternatives to TestRPC? I'm also using a dapp that requires event subscriptions and TestRPC still doesn't support web socket connections (even though it's well-documented in the web3.js API.)

[MicahZoltu]

It depends on what exactly you need. You can use https://github.com/ethereumjs/ethereumjs-stub-rpc-server if you don't need an actual EVM/consensus system.

[munawarb]

@MicahZoltu Thanks for this information! I'm looking for something that does what testRPC does: create test accounts and let you run commands against your contracts using these accounts, without having to connect to a block chain. I'm looking at Parity now but it looks like you have to be connected to an actual block chain to do anything with it. Is this correct or am I misunderstanding something here? I guess my question is how do people test their contracts without running full nodes if testRPC isn't available? I'd rather not write a nodejs script like the link you gave suggested; I'm just looking for something simple like what testRPC is made for.

[MicahZoltu]

You can run Parity with a custom genesis block, no peers and insta-seal. It effectively is the same as TestRPC, though you will need to hit the Parity endpoint to create any test accounts you want and then transfer funds from the root account (which has all of the ETH in the system I think) into the test accounts as needed.

I have also used EthereumJ to unit test contracts before, setup was pretty simple and since I like static languages using Kotlin (or Java) was nice. EthereumJ runs a chain (including EVM) in the test process meaning you don't have to spin up a separate process to host the chain, and resetting is easy.

I believe TestRPC has the largest user base and so is easiest to get support with, but I'm not sure it is necessarily the best solution depending on what exactly you need.

[benjamincburns]

I'm cleaning up my workflow a bit, and getting organized using epics on ZenHub. This ticket is the epic for WebSockets and web3 1.0 support.

In my last status update I was a bit optimistic on timeline. Also to a scheduling issue, @perissology and I haven't connected since then.

My current line of work started from trufflesuite/ganache#14, but it's got quite a bit of refactoring into it by this point.

Here's where I am. Note that unless otherwise specified, all work on this issue to date is being done in trufflesuite/ganache-core.

• update to latest web3-provider-engine
• update dependency on web3 to 1.0
• pull assorted small fixes and test maintenance from my prior websockets branch into @perissology's PR
• find/fix blocking bug in web3
• submit PR to MetaMask/provider-engine for SubscriptionSubprovider (Add subscription subprovider to handle websocket pub/sub MetaMask/web3-provider-engine#207) (submitted, but still needs some tests added not yet accepted)
• Finish making all tests pass

Test maintenance:

• accounts.js
• bad_input.js
• block_tags.js
• custom_gas_limit.js
• custom_gas_price.js
• debug.js
• ethereum.js
• events.js
• forking.js - If there's any major undiscovered work left, it's here
• forkingasprovider.js
• gas.js
• interval_mining.js - passing, but spits out unhandled rejection errors
• mining.js
• persistence.js
• requests.js - most work is done for this, but some test is still failing in most recent run
• runtime_errors.js
• snapshotting.js
• stability.js
• swarm.js
• time_adjust.js
• transaction_ordering.js
• vm.js
• whisper.js

[benjamincburns]

I'm finally over the subscriptions hump! Now I just have forking to look forward to... 😂

I've pushed my WIP to the websockets-pr-redux branch of ganache-core. Ideally I'd be adding this in w/ trufflesuite/ganache#14 but last I tried I couldn't push to that repo.

[benjamincburns]

I pushed a bunch of work on the forking tests late in the day last week. The only remaining problem there is that the blocknumber oracle test is failing in a way that makes very little sense to me at present.

The upshot of this is that while I don't yet fully trust the forking feature on this branch, I think it'd be awesome if those following along were to pull this branch, get a local build of ganache-cli going, and report any issues they observe back here.

To do this, do the following (preferably after updating to latest nodejs, preferably using NVM):

cd $YOUR_PROJECTS_DIRECTORY_OF_CHOICE
git clone git@github.com:trufflesuite/ganache-core.git
git clone git@github.com:trufflesuite/ganache-cli.git
cd ganache-cli
npm install
npm run build
npm link
cd ../ganache-core
git checkout websockets-pr-redux
npm install
npm link
cd ../ganache-cli
npm link ganche-core
npm run build

EDIT: grumble grumble - I just realized that npm link does an implicit npm install which clears your linked modules. I've updated the instructions above, and comment below to reflect that. Note that we don't rerun npm link at the last step because the necessary symlinks are already in place.

Note that the first npm link will replace the ganache-cli build you've previously installed globally with your local build. To undo this, just do npm install -g ganache-cli

If you don't want to install your local build globally, just run everything but the first npm link command, and run ganache-cli with node $YOUR_PROJECTS_DIRECTORY_OF_CHOICE/build/cli.node.js $ARGS_GO_HERE.

[benjamincburns]

Good news, everyone! I've got everything done with the exception of code review and whatever work the MetaMask team will require from me to complete MetaMask/web3-provider-engine#207.

What my list is looking like now

• update to latest web3-provider-engine
• update dependency on web3 to 1.0
• pull assorted small fixes and test maintenance from my prior websockets branch into @perissology's PR
• find/fix blocking bug in web3
• submit PR to MetaMask/provider-engine for SubscriptionSubprovider (Add subscription subprovider to handle websocket pub/sub MetaMask/web3-provider-engine#207) (submitted, but still needs some tests added not yet accepted)
• Finish making all tests pass
• Code review

Test maintenance:

• accounts.js
• bad_input.js
• block_tags.js
• custom_gas_limit.js
• custom_gas_price.js
• debug.js
• ethereum.js
• events.js
• forking.js
• forkingasprovider.js
• gas.js
• interval_mining.js
• mining.js
• persistence.js
• requests.js
• runtime_errors.js
• snapshotting.js
• stability.js
• swarm.js
• time_adjust.js
• transaction_ordering.js
• vm.js
• whisper.js

[benjamincburns]

You all might've noticed that trufflesuite/ganache#49 is now merged to develop. Good news - there's a beta release of ganache-cli out now with these changes integrated. To use it, just npm install -g ganache-cli@beta. Please report any issues specific to websockets either here or in a separate issue!

[v4nz666]

So far so good! Thanks a lot @benjamincburns

[ewingrj]

@benjamincburns how do you enable websockets? the cli doesn't appear to have an option to do it

[ewingrj]

ah, I see. it's enabled by default on the same port as the http server 8545

[onbjerg]

@benjamincburns Just for reference, if what @perissology says is true, then I think you should change the port to 8546, since that is the de facto standard for WebSocket RPC right now

[MicahZoltu]

It is the defacto standard within Ethereum (because Geth) but it is not proper WS behavior for the rest of the world. WebSockets are designed to serve over the same port as HTTP via WS upgrade. I think gnache is doing the right thing here, and I hope (dare to dream) that one day geth and parity follow suite.

[onbjerg]

@MicahZoltu Yeah, I know, was just pointing out the de facto standard, but I agree this way is better, with the exception that Web3 1.0 defaults to 8546 for WebSockets 😊

[benjamincburns]

This one should've been closed quite a long time ago.