If you change a Rails application file (say a view), then you make a request on the server (i.e. API HTTP request) ActionCable drops any actioncable (websocket) connections.
The connection will be automatically re-established in about 7 seconds but if any messages are sent during this time they will be dropped.
Soooo the question is is there any way to get a notification on the server that the connection is being dropped? That way the server application can internally queue up messages until the connections are re-established.
Related
I'm writing a chat app using Twilio's Programmable Chat JS SDK. The app works fine, but I noticed after some long time (maybe 30+ minutes) where the browser tab is inactive, when I return to the browser tab the websocket connection is closed. These are the messages that appear in the console after switching to the inactive browser tab:
WebSocket connection to 'wss://tsock.us1.twilio.com/v3/wsconnect' failed: Error
in connection establishment: net::ERR_INTERNET_DISCONNECTED
twilio-chat.min.js:204 WebSocket connection to
'wss://tsock.us1.twilio.com/v3/wsconnect' failed: WebSocket is closed before
the connection is established.
1) Is this normal? Does it have to do with the fact that I'm still on the Twilio Free Plan?
2) How to manage socket connections in these cases? Also if the internet connection is lost then reestablished, how to ensure the web socket reconnects?
I tried to listen to the connectionStateChanged event as per the SDK docs here:
http://media.twiliocdn.com/sdk/js/chat/releases/3.2.0/docs/Client.html#event:connectionStateChanged
but when the user's device is sleeping (e.g. laptop in sleep mode) the event will not fire and therefore the socket will close.
Thanks
Was a known bug from Twilio. Solved by updating to the JS SDK 3.2.
I have a voip app for ios, based on webrtc. I also have a signaling server made with nodejs. I can connect to the server and make calls without a problem. But tracking presence (online/offline) accurately is a problem.
Just for the record, here is a list of everything I did to ensure a stable connection:
Set the background mode "Voice over IP"
Flag the inputstream as a voip stream with "[inputStream setProperty:NSStreamNetworkServiceTypeVoIP
forKey:NSStreamNetworkServiceType];"
Turned on persistent wifi by setting "UIRequiresPersistentWiFi" to YES in the plist file
I implemented "setKeepAliveTimeout:handler:" and I use it to send a ping to the server (unnecessary, but you never know...)
I created a small test app that does nothing more than connect to the server and respond to "ping" with the message "pong". This app sends "ping" to the server when the keep alive timeout handler fires and the server replies with "pong". I also created a simple test server that does nothing more than let clients connect, send "ping" to a client when I send "send_ping" to it via telnet and responds to "ping" with the message "pong".
Here is my client code
What I expect is the following:
Starting the app and signing in should create a persistent connection to the server (works)
Telnetting into the server and typing send_ping makes the server send "ping" to the client and the client should send "pong" back (works)
Putting the device in standby should have no effect on the above ping-pong mechanism (doesn't work)
Putting the device in standby and unlocking it after a few hours, then sending a ping to it should make the client send a pong back (works)
Turning off wifi on the client (without cellular enabled) should be detected on the server-side and kill the socket (doesn't work)
I log all messages from the server in a textview on the client with a timestamp, and sometimes when I put the device in standby the pings I send from the server just don't arrive at all. Sometimes it takes over a minute for the app to receive the ping message, sometimes it responds immediately. I don't understand why it is so random. Sometimes this undesired behaviour starts after mere minutes in standby mode, sometimes it goes alright for a while but breaks after 20+ minutes, sometimes all messages from the server arrive at once as soon as I unlock the device.
Push notifications and voip push notifications could be a solution, but they are also slightly unreliable. There should be a way to make this work 100% of the time.
I'm developing a messaging system in Delphi. I'm using idTcpServer in my Server Application and idTcpClient in my client application. the client application pings the server every 10 seconds to see if the connection is active and tell the server to set the status of the user to Online. and also the user may send messages to his contacts. all these requests are followed by a response from server which i get by socket.readln command right after i send the request. for example for pinging the server:
TcpClient.socket.writeln('i am online');
if TcpClient.socket.readln = 'ok' then
begin
{commands}
end;
I also check for new messages using Long Polling. I send 'check for new messages ' + timestamp from tcpClient and then on the server, I check the database for new messages newer than the timestamp i recieved in a While loop so when there is a new message the loop breaks and notification is sent to the client.
But this system doesn't work for me. Sometimes I get the responses intended to be for checking for new messages when the client application is pinging the server.
I have developed the same system in php without a problem. but here there must be a problem.
I think it is not asynchronous. what should I do?
Regarding the check for new messages request, the server should not be looping waiting for new messages to arrive. Either there are new messages available at the time of the request or there are not. Get the request, do the query, report the result, and move on. The client can send a new check for new messages request periodically. Alternatively, have the client tell the server one time that it wants new messages, and then the server can actively push new messages to the client in real-time as they arrive on the server, instead of polling for them (similar to IMAP's IDLE command).
I would suggest you redesign your communication protocol to run asynchronously. Most modern IM services are asynchronous. When the client sends a request, do not expect a reply right away. Just let the client move on to other things. Have it run a separate timer/thread that reads all inbound data. When a reply does arrive, the client can act on it. If needed, include an identifier in the request that gets echoed in the reply so the client can keep track of the requests it sends. This also allows the server to use asynchronous processing on its end, so if a request takes a long time to run, the server can push it off to another thread/process and continue processing other requests in the meantime. Send the final reply when it is ready.
When using Nginx there are times then HTTP 499 is recorded in the error log when the client has prematurely closed their connection (for example, the connection timed out, the user reloaded their browser or pressed Stop or otherwise).
I understand that Nginx is able to detect this because they are the end which will receive the SIGPIPE signal indicating the socket has been closed, however I am wondering if it is possible to get this notice back to Rails at all?
Shopify recently used a very novel approach to detect this in Unicorn before sending the request on to Rails to be processed, however I would like to be able to detect this within the Rails app, such as during a long-running transaction.
After Rails's dispatcher had already started processing the request - there is no connection to the http client anymore, only when the processing is done - the response is headed back to the client.
So basically, there is no way you can tell if the client (e.g: browser) had shutdown the connection while you are already processing it.
Hello everyone~
I have a problem to solve~
I have created a server that every one can connect to this server.
The function of The server is in order to transfer message from one client to another client.
I don't known when the other client send the message to the client.
I use Delphi-7 to develop the program.
I didn't find any TCPClient object to listen the message which the TCPServer send.
Please give me your point of views~thanks :)
Servers don't initiate conversations with clients. If your messaging clients don't already have open connections with the server, and the server needs to notify the client that it has a message, then the client program needs to have a server component so that it can listen for new connections from the message server.
One alternative is for the clients to keep persistent connections open with the server. When a message arrives, the server can send a notification to the appropriate client because it already has a connection open and the client is waiting for a response from the server.