heroku socket connection limitation - heroku

One of my app need socket connection.
I tested on nitrous.io, but their free account always close the socket connection if there is no signal between server and client more than 1 minute.
Just wonder if there is similar socket connection limitation on heroku?
Your comment welcome

Heroku has support for WebSockets, with the usual 30s timeout limitation. This can be easily worked-around by sending heartbeat packets.
https://devcenter.heroku.com/articles/heroku-labs-websockets

Related

How long can a RSocket connection last?

I understand that RSocket connection is bidirectional.
How long can a client be connected to a server via RSocket before the connection is terminated?
And if the connection actually does terminate, how does it get reconnected if the server wants to send something to the client?
Minutes, Days or Weeks?
It's dependent on your use. Server to Server with lifetime of those servers. Or Mobile connecting to a backend with sticky routing and resumption.
However while the connection is bi-directional, the client must always initiate the (re-)connection.
https://github.com/rsocket/rsocket-java/blob/d903e9635a159285b6943ea93156c31aa406ba5d/rsocket-examples/src/main/java/io/rsocket/examples/transport/tcp/resume/ResumeFileTransfer.java

How to prevent websocket opening handshake timeout?

I am trying to make a connection to a socket.io session. The connection is easily established, however, if I am idle for a short duration I get this error in my console:
websocket.js:116 WebSocket connection to 'ws://localhost:3000/socket.io/?EIO=3&transport=websocket&sid=PwzuR5tNmPmZfj0UAAAB' failed: WebSocket opening handshake timed out
I tried fixing the issue by setting pingTimeout and pingInterval but to no avail. I am not sure how to fix this or what is causing this.
On a side note, I am trying to read and understand the socket.io docs and am still not clear about what ping and pong packets exactly are. Does the client have to manually interact with the socketio server in order for it to receive pong packets or will it still receive pongs if say the client interacts with an http server on the same host ?

QPID JMS Heartbeat / Keepalive

is it possible to set a heartbeat or keep-alive for a JMS consumer using QPID JMS? I've found some configuration of QPID which can bet set at the URL like an idleTimeout but I've not found an option to send empty frames for a limited time period.
Regards
The Qpid JMS client allows you to configure how long the idle timeout is which controls when the client will consider the remote to have failed should there be no traffic coming from the remote either in the form of messages or possibly as empty frames in order to keep the connection from idling out. The client will itself respond the the remote peer's requested idle timeout interval by sending as needed an empty frame to ensure that the remote doesn't drop the connection due to inactivity.
If you are seeing drops in connections due to idle timeout on a server then it is likely you have not configured the server to provide an Idle timeout value in the Open performative that it sends to the client.
Reading the specification section on Idle Timeout of a Connection can shed some light on how this works.

How to drop inactive/disconnected peers in ZMQ

I have a client/server setup in which clients send a single request message to the server and gets a bunch of data messages back.
The server is implemented using a ROUTER socket and the clients using a DEALER. The communication is asynchronous.
The clients are typically iPads/iPhones and they connect over wifi so the connection is not 100% reliable.
The issue I’m concern about is if the client connects to the server and sends a request for data but before the response messages are delivered back the communication goes down (e.g. out of wifi coverage).
In this case the messages will be queued up on the server side waiting for the client to reconnect. That is fine for a short time but eventually I would like to drop the messages and the connection to release resources.
By checking activity/timeouts it would be possible in the server and the client applications to identify that the connection is gone. The client can shutdown the socket and in this way free resources but how can it be done in the server?
Per the ZMQ FAQ:
How can I flush all messages that are in the ZeroMQ socket queue?
There is no explicit command for flushing a specific message or all messages from the message queue. You may set ZMQ_LINGER to 0 and close the socket to discard any unsent messages.
Per this mailing list discussion from 2013:
There is no option to drop old messages [from an outgoing message queue].
Your best bet is to implement heartbeating and, when one client stops responding without explicitly disconnecting, restart your ROUTER socket. Messy, I know, this is really something that should have a companion option to HWM. Pieter Hintjens is clearly on board (he created ZMQ) - but that was from 2011, so it looks like nothing ever came of it.
This is a bit late but setting tcp keepalive to a reasonable value will cause dead sockets to close after the timeouts have expired.
Heartbeating is necessary for either side to determine the other side is still responding.
The only thing I'm not sure about is how to go about heartbeating many thousands of clients without spending all available cpu just on dealing with the heartbeats.

How long can a XMPP Session last?

Without timeout? Or is there even a timeout?
There is no limit on the lifetime of a connected jid. For command line bots, it is a good practice to send periodic ping packets to the server, just to make sure opened socket doesn't drop after some period of inactivity.
In case your client is connected from browser and suppose the user refreshes the browser without disconnecting from the jabber server. User can still use saved (via cookie/session) jid,sid,rid combination to reconnect with previously opened session. However, bosh connection manager will drop the connection after "X" seconds of inactivity.
XMPP does not say anything about having or not a timeout. So, in theory, you XMPP Session could last as long as the TCP connection is established.
You are free to implement a timeout in your client or server though...

Resources