The isListening() method returns whether a node is listening for peers, this uses the method, net_listening which is supported by our HTTPS endpoint if you need that information.
Can you try connecting using a different method to test your WSS connection?
Is it not possible to add some kind of a heartbeat so we dont have to reconnect unnecessarily after an hour, which we will just end up doing? It kind of defeats the purpose of disconnecting users after an hour (due to idle sessions), as we will just reconnect.
In general, we don’t encourage having idle connections. It takes up resources that are not being used for anything. The idle connection also can be seen as a indication of something going wrong. The backend ethereum clients have stability issues related to subscription and filters where the node is ‘healthy’ but subscriptions and filters stop responding. The only thing you can do at that point, is to reconnect. We realize this is a problem for our users and are in the process of upgrading our subscriptions to be less client dependent. The ‘newHeads’ subscription has been upgraded so you shouldn’t see a timeout issue with newHeads, and are also in the process of upgrading our log subscription.
Its not idle connections per se, more really a connection that is subscribing to all events on a smart contract. Thats it really. As for the ‘newHeads’ subscription, how is this activated/used? Sorry, never came across this before.
it’s part of the the ‘eth_subscribe’ method. For more info:
https://infura.io/docs/ethereum/wss/eth_subscribe
also:
We realize this is a problem for our users and are in the process of upgrading our subscriptions to be less client dependent.
There’s a massive difference between a frontend client just listening for confirmations and likely having page refreshes, and a backend client managing a contract which will have peaks and lulls depending on the time of day.
Is there an accepted solution for web3? This is game breaking. It is currently too annoying to do with geth. The ridiculous blockchain size and high expense of maintaining this on a remote host discourage most people from even bothering. There’s almost no current Ethereum projects even worth this expense imo.
Edit: newHeads only seems to be for subscriptions, but most people will be using getPastEvents as their subscription method for a backend manager.
Edit 2: After testing, the only way to make a script that listens is to bombard infura with 10,000x the requests as a connection that doesn’t drop would do. Something need to be rethought here. I’m just reconnnecting and rerequesting past events every three seconds instead of just waiting for the events. Sure, I don’t want things to hang so iterating based on a block number getter in the contract, but after it discconects the first time, the only way for things to work is to hammer the node with requests, so better just to do that from the start. I don’t even see the point of a WebSocket connection.
Are you using web3.js to generate your subscription, or a different library?
Web3 1.0 beta 55. All of my tests have been failures. It’s annoying to test because I have to wait about one hour for it to drop each iteration.
Could you explain what data your app is querying? Is it account balances, contract event logs, or just new block information. If I knew a bit more about what youre trying to accomplish I can try to suggest how to optimize.
It is listening for approval events (subscriptions) on a token contract and then updating a billing contract based on those events. It has to work all of the time, else people will approve tokens for a subscription, but not get confirmation of billing on the frontend. Missing an event = death.
The list of events can grow very large quickly potentially too, which is a challenge to parse. There’s a lot to engineer redundancy-wise, but getting stuck on the most rudimentary part of it is probably why Ethereum has languished with more bullshit than viable products. :-/
Infura is an invaluable fallback to a local node, which has its own problems with Web3. Hammering every three seconds the same getPastEvents query is not viable.
Thanks. That background was helpful. Out of curiosity, would a webhook event delivery be something that would be compatible with your architecture or are you looking for another type of resilient interface for events.
I’m totally agnostic to solutions. I just want something to works, but preferably with an established pattern that I know works. Willing to pay as well for priority.
I think a lot of people are in the same place. Ethereum is pretty much dead in the water until PoS takes hold as well. Ignoring error handling, there’s way too much friction on transactions on the frontend for end users currently from confirmation time and gas price selection. All of these annoyances add up!
Hi guys, I am having the same problem as many in here. I am subscribing to get logs on a couple of contracts and having long-term connection issues. I wrote a simple disconnect/reconnect function to help, but I am still finding it dropping unexpectedly. I see in the FAQ it recommends to ‘ping.’ Has anyone here found a good way to solve this issue?
One additional suggestion from the ping technique is to have a newHeads subscription type in your connection as well. Since the newHeads will come in multiple times per minute your connection will be kept alive via that subscription.
I am wondering the same thing: what is the best way to setup pinging for newBlockHeaders subscriptions?
I saw someone above posted the following code:
this.web3.currentProvider.on('end', () => {
console.log(`websocket session ended. attempting to restart.`);
this.setup();
});
Is there another way?
Can you elaborate on how this would be done?
Most languages have a default ping function for websocket connections. Assume socket is your wss connection, for JS it is socket.send("ping")
Use eventeum and rabbitmq to guarantee delivery of events.
What is the response you are expecting for this method? I am still having issues with Infura dropping wss for just simple operations that aren’t needed all of the time on another project.
connection not open on send()
I am using socket.io to connect to a frontend with the object socket. Not sure how that affects things.
var web3 = new Web3(
new Web3.providers.WebsocketProvider(
"wss://ropsten.infura.io/ws/v3/xxx"
)
)
If I poll with web3.send(“ping”), will that work?
Edit: After some research, Infura breaks things when the connection times out. I need some method to instantiate infura again, because polling and pinging is not going to be a solution. I just need to open a new connection each go, but this time the solution can’t be restarting the script.
It looks like Infura was fixed from last time I tried, however it’s not ideal as there is plenty of lag reconnecting.
20200122T070244.115599: *** WebSocket Ended ***
20200122T070244.784172: *** WebSocket Connected ***
Enough to introduce errors with traffic, but I suppose you wouldn’t be using Infura if this becomes likely. It would be nice to guarantee a connection however. I suppose Web3 is infinitely more likely to throw you a curveball than to get stuck in the gap here, or some other nodejs bug.
Here’s what I did:
const Web3 = require("web3")
//Infura Websockets connection.
var getProvider = () => {
const provider = new Web3.providers.WebsocketProvider(
"wss://ropsten.infura.io/ws/v3/xxx"
)
provider.on("connect", () => {
console.log("*** WebSocket Connected ***")
})
provider.on("error", (e) => {
console.log("*** WebSocket Error ***")
getProvider()
})
provider.on("end", (e) => {
console.log("*** WebSocket Ended ***")
getProvider()
})
provider.on("close", (e) => {
console.log("*** WebSocket Closed ***")
getProvider()
})
provider.on("timeout", (e) => {
console.log("*** WebSocket Timeout ***")
getProvider()
})
provider.on("exit", (e) => {
console.log("*** WebSocket Exit ***")
getProvider()
})
provider.on("ready", (e) => {
//console.log('*** WebSocket Ready ***')
})
return provider
}
var web3 = new Web3(getProvider())