Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support WebSocket as a transport for the RPC. #257

Closed
MicahZoltu opened this issue Feb 13, 2017 · 18 comments
Closed

Support WebSocket as a transport for the RPC. #257

MicahZoltu opened this issue Feb 13, 2017 · 18 comments
Assignees

Comments

@MicahZoltu
Copy link
Contributor

@MicahZoltu MicahZoltu commented Feb 13, 2017

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

This comment has been minimized.

Copy link

@onbjerg onbjerg commented Aug 3, 2017

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

@MicahZoltu

This comment has been minimized.

Copy link
Contributor Author

@MicahZoltu MicahZoltu commented Aug 3, 2017

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

This comment has been minimized.

Copy link

@munawarb munawarb commented Aug 9, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

@MicahZoltu MicahZoltu commented Aug 9, 2017

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

This comment has been minimized.

Copy link

@munawarb munawarb commented Aug 10, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

@MicahZoltu MicahZoltu commented Aug 12, 2017

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

This comment has been minimized.

Copy link
Contributor

@benjamincburns benjamincburns commented Jan 4, 2018

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-core#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 (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

This comment has been minimized.

Copy link
Contributor

@benjamincburns benjamincburns commented Jan 5, 2018

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-core#14 but last I tried I couldn't push to that repo.

@benjamincburns benjamincburns mentioned this issue Jan 7, 2018
0 of 1 task complete
@benjamincburns

This comment has been minimized.

Copy link
Contributor

@benjamincburns benjamincburns commented Jan 8, 2018

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

This comment has been minimized.

Copy link
Contributor

@benjamincburns benjamincburns commented Jan 8, 2018

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 (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

This comment has been minimized.

Copy link
Contributor

@benjamincburns benjamincburns commented Jan 16, 2018

You all might've noticed that trufflesuite/ganache-core#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

This comment has been minimized.

Copy link

@v4nz666 v4nz666 commented Jan 17, 2018

So far so good! Thanks a lot @benjamincburns

@ewingrj

This comment has been minimized.

Copy link

@ewingrj ewingrj commented Jan 22, 2018

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

@ewingrj

This comment has been minimized.

Copy link

@ewingrj ewingrj commented Jan 22, 2018

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

@onbjerg

This comment has been minimized.

Copy link

@onbjerg onbjerg commented Jan 24, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

@MicahZoltu MicahZoltu commented Jan 24, 2018

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

This comment has been minimized.

Copy link

@onbjerg onbjerg commented Jan 31, 2018

@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 comment has been minimized.

Copy link
Contributor

@benjamincburns benjamincburns commented Aug 13, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.