I am designing websockets and trying to understand best practices.
The question is, should my server try to deliver events even if the connection is closed?
Pros of attempting to deliver the events when connection is closed:
I can receive the un delivered events as soon as my connection opens again
Cons:
The events will be backed up, causing the latest events to be delayed.
Can someone recommend me any services that allow 3rd party developers to use websockets and follow the best practices?
Here is my logic:
Open websocket connection
Continue to receive the events while the connection is open
Close the connection when you no longer want to receive the events
Related
I want to implement a notification to the post author as soon as there is a comment on the post. In other words, when a request to write a comment comes to the server, the server wants to send a notification to the author in real time. Of course, I also want to give the commenter a push notification when the author of the post has commented on a comment.
The server is implemented with Spring Boot, and I am considering websockets to send push notifications from server to client. However, before I try, I have a few concerns and ask a question.
As I understand it, websockets is a web protocol that enables two-way communication between a server and a client over a single TCP connection. In other words, in order to implement a push notification that a comment has been made to a mobile app, I think that a TCP connection must be maintained at all times. I am wondering if it is possible to send push notifications using websockets from server to client even when the client app is in background state or is off. My guess is that if the TCP connection goes down, The app won't get push notifications.
I think WebSocket is suitable for full-duplex two-way communication such as chatting, but wouldn't it be expensive to implement a websocket that occasionally sends push notifications from the server to the client?
The function I want to create is a function that notifies only the author of a specific post with a comment when a comment is posted. Is it appropriate for websocket to implement a function that notifies only a specific user?
I just know that websocket is one of the methods for sending data from server to client, and I tried to use websocket for push notification, but I don't know if it's the right way to go.
I am looking for best practices to handle server restarts. Specifically, I push stock prices to users using websockets for a day trading simulation web app. I have 10k concurrent users. To ensure a responsive ux, I reconnect to the websocket when the onclose event is fired. As our user base has grown we have had to scale our hardware. In addition to better hardware, we have implemented a random delay before reconnecting. The goal of this is to spread out the influx of handshakes when the server restarts ever night (Continuous Deployment). However some of our users have poor internet (isp and or wifi). Their connection constantly drops. For these users I would prefer they reconnect immediately. Is there a solution for this problem that doesn't have the aforementioned tradeoffs?
The question is calling for a subjective response, here is mine :)
Discriminating a client disconnection and a server shutdown:
This can be achieved by sending a shutdown message over the websocket so that active clients can prepare and reconnect with a random delay. Thus, a client that encounters an onclose event without a proper shutdown broadcast would be able to reconnect asap. This means that the client application needs to be modified to account for this special shutdown event.
Handle the handshake load: Some web servers can handle incoming connections as an asynchronous parallel event queue, thus at most X connections will be initialized at the same time (in parallel) and others will wait in a queue until their turn comes. This allows to safeguard the server performance and the websocket handshake will thus be automatically delayed based on the true processing capabilities of the server. Of course, this means a change of web server technology and depends on your use-case.
I am building browser application with real-time updates.
Application allows to read and edit spreadsheet together with other people online.
However, some people have poor Internet connection and disconnects may occur.
I want application to be able to update to the latest data after Internet reconnection.
Currently Pusher and application work so:
Pusher connects to server and receives events.
Other people make changes in spreadsheet.
Application receives these changes from Pusher and is able to reflect them on spreadsheet.
At some moment Internet disappears.
Pusher detects this and automatically tries to reconnect.
Other people make changes in spreadsheet.
Application can't receive these changes because there is not Internet connection.
After some time, for example 5 minutes, Internet connection seems to be ok.
Now Pusher successfully reconnects to server.
However, Pusher doesn't receives events from period when there was no Internet connection (list item #6).
Other people make changes.
Pusher receives events and application is able to handle them.
So my problem is: Pusher doesn't receive events after automatic reconnect which were triggered by other people during Internet disconnection.
I am using default Pusher configuration, private channel, latest stable version and don't do any magic.
Pusher does not currently provide this functionality. To implement this yourself you would have to send a numeric ID with each message that increases in value. You would also need to store a cache of all sent messages in a database. Clients can keep track of the last ID they received. After disconnecting and reconnecting, they can send a request to your server asking for all messages greater than the last message ID they received. Your server should respond with messages matching that query in your database.
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.
I have spring + SockJS application, that is using ActiveMQ as message broker.
Can I have two sockets on same JSP page, one with sending and receiving ,and the other one only for receiving stomp messages(with lot of traffic).Is it guaranteed taht all messages will be delivered and received from both of sockets?
Regards,
Marko
While connected, yes. If you lose the connection at any point, you will lose everything between disconnecting and reconnecting. A related discussion of this issue comes to this conclusion.
Keep in mind that SockJS may result in different connections types on different clients, such as websocket, xhr, xdr, etc. On any connection SockJS will still use TCP and will still guarantee in-order delivery. However, non-websocket connections can take longer to trigger the close event, so you'll have longer black-out periods at the client. Almost any service needs to worry about this, because SockJS will sometimes fail to connect a websocket and "downgrade" to xhr (in my experience under high instantaneous load).
A good pattern is to add a reconnect in the close event handler. The close even is fired even when a connection fails to be established, which means you'll want a back-off latency on the reconnect to prevent a self-inflicted DDoS on your server. Separately, I add sequential packet numbers, and treat any client that detects a missing packet as a late joiner. (See this related ZMQ discussion on late joiners.) Your application needs may vary.