How to reduce the time it takes a FCM to reach user's phone, which is not influenced by any restrictions like doze or task killers.
it can be particularly bad for signaling voip calls which firebase doesn't support natively (unlike apple's Pushkit).
I see some voip apps tend to maintain a socket for that, but i've seen that sockets usually don't last with some vendor's task killers
I want to create a web app using React as the front end technology. A requirement for the app is that the server will be able to update all the clients with information about changes (not have to be an exact real time, but should update after no more than 10 seconds).
Solutions like clients requesting updates from the server every several seconds are out of the question.
Requirements:
1) The server's should be implemented with either .NET or with Node.js.
2) The connection MUST be secured via port 443 of the IIS.
I read a bit about Micorsoft's SignalR and about Pusher Channels which seems to provide exactly the kind of service I require.
Could you please elaborate about what exactly are the differences between them? When should I choose each? Which of them got more community support? Which is easier to implement? Stuff like that...
Both SignalR and Pusher Channels ultimately both use websockets to deliver messages to clients, so both should meet your requirements to deliver messages to clients in realtime.
1) Both offerings also meet your requirements for both library support:
SignalR supports .NET:
https://dotnet.microsoft.com/apps/aspnet/signalr
Pusher Channels has server support for both nodejs and .NET:
https://github.com/pusher/pusher-http-node
https://github.com/pusher/pusher-http-dotnet
2) Both offerings also meet your requirements for sending messages over TLS/WSS:
SignalR:
https://kimsereyblog.blogspot.com/2018/07/signalr-with-asp-net-core.html
Pusher Channels:
Securing Pusher's messages
In terms of the differences between them this depends on your implementation, if you just run SignalR on your own ISS server then it will be down to you to manage all of the websocket connections and all of the scaling challenges that come with this.
However similar to how Channels works, SignalR also has a managed websocket service, so you do not need to manage the connections or scaling. You just make an API request with the message you want to send to either Channels or SignalR and this message is then broadcast to the interested clients connected by websockets. In this scenario you do not manage the websocket connections yourself.
However in terms of pricing Channels appears to be far more competitive (especially the free offering), so if you are looking at the managed offering Channels looks to be a better value proposition:
https://azure.microsoft.com/en-gb/pricing/details/signalr-service/
https://pusher.com/channels/pricing
Both offerings look fairly similar in terms of implementation (assuming you are using the managed service). The complexity would increase if you implement SignalR on ISS:
https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-2.2
In terms of support Pusher has a free application support offering:
https://support.pusher.com/hc/en-us
Hope this helps!
This presentation has some answers A 10 Minute Guide to Choosing a Realtime Framework
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
The Problem
My application works as follows:
Multiple (< 20) device clients (Android) are running at a single location.
Thousands of locations exist (therefore tens or hundreds of thousands of device clients exist).
A web portal client also exists that works in sync with each location's data and its device clients.
New data generated on a device is posted to the server (cloud) via a REST API (ASP.net WebAPI).
So far this application is a pretty standard application with a mobile device client and web portal client.
However, due to requirements on each device client that is out of my control (device clients need to function in offline mode, reduce network latency, etc), each device client does not use the server database as its immediate source of record. Each device client has its own local database (SQLite) that stays in sync with all data for its location. For example: when I make a data change on device client A, that change needs to be propagated to device client B and to web portal client C.
The web portal client reads directly from the server database since it does not need offline functionality.
As you can see, the problem here is that we now need a way to keep all device client databases in sync with each other in real time. Brief delays in data being in sync between two device clients is expected and considered okay.
Proposed Solution
My proposed solution is as follows:
When a new client device comes online initially, it receives a data dump for what it has missed since the last time it was online from the server via REST API.
Each new data item posted/updated/deleted from client devices via REST API is propagated through to the server database. The server database houses all data for all locations and should be considered as the permanent source of record.
The web portal works directly with the server database since it has no offline type requirements.
A connection from each client device is established to a data sync stream service via SignalR.
A worker service is "tailing" the server database for new Create/Update/Delete operations. When a CUD operation is detected, a message is dispatched to an Azure Service Bus queue/subscription (via fan-out topic) for each data sync service instance. This allows for horizontal scaling of the SignalR data sync service (with an Azure Service Bus backplane) since thousands of device client connections will exist.
The data sync service reads from its message queue/subscription and pushes a sync message (containing all needed data for the sync) to all connected client devices (for the location related to the data) via SignalR.
The following diagram illustrates this solution:
Large blocks depict servers (gray squares are HTTP web servers that can be horizontally scaled)
Arrows depict the direction of data flowing through the application.
Questions
Is SignalR the right technology for this problem/solution? Originally my solution involved each client device establishing it's own Azure Service Bus queue/subscription that collected messages from the database-tailing worker (sync river). The problem with that solution is that I would be pushing lots of wasted messages to offline device clients that may not come back online for a very long time, if ever. By dumping back the delta data when a device client comes online initially and streaming data via SignalR thereafter I can solve this.
I have not used SignalR extensively in a production environment before, so I am a bit new with it. What problems/challenges can I expect to experience with it for this solution?
The following article states that "There are some scenarios where a backplane can become a bottleneck. Here are some typical SignalR scenarios: High-frequency realtime (e.g., real-time games): A backplane is not recommended for this scenario.". Would this solution fall into this category? What problems could the backplane of Azure Service Bus messaging introduce? How else would I scale this solution if not in this way?
Your general opinions and recommendations for this solutions are also welcome and appreciated.
You have a requirement on real-time communication to devices when they are online. One of the most promising ways to do this is by using web sockets.
Using web socket itself is not practical and so there are popular
libraries for it such as SignalR, socket.io. These libraries absorb
many difficulties faced in production and also in development. These
libraries even support scaling.
Since your stack is .net based SignalR is choice here.
SignalR will work well in most of the cases. Here you don't have to
worry on backplane becoming a bottleneck as given in a real -time
games.
But maintaining a self-hosted real-time solution such as SignalR comes with a cost. The success rate of communication will be not high reliable in stock SignalR and you will have to implement various monitoring mechanisms and failover processes. Geo-distribution also not supported. So the next choice for a high reliable real-time system which addresses all mention issues is a hosted service such as pub-nub.
is there a way for a server to push some data to a client, wirelessly and seamlessly, which may be Windows(Phone), iPhone, Mac, or Android device, without any OS integration?
If so, what's the best design pattern to do this, and what are the best technologies to go about this?
Push technology is simply a methodology of the server initiating the transfer of data, rather than the client asking the server for it.
Apple makes push technology relatively easy to use by providing such functionality built-in on the OS. As well as Android through the Google Cloud Messaging for Android. Windows, however, does not.
Apple push notifications and Google's messaging for Android is seemingly magical and/or functionality that the OS needs to handle; however, this isn't necessarily the case. The advantage of having it "integrated" in the OS, is the same as having a framework handle the functionality for you.
Speaking in technical terms, push technology is a long-lived connection from the client to the server that accepts messages. These messages would be considered pushed messages, since the client did not make an individual request for them.
The main thing to keep in mind when implementing push technology yourself, is that the client is in charge of keeping that long-lived connection alive as much as possible. Because client IP addresses can change between disconnects, servers are not guaranteed that a client's address will be persistent across disconnects. Moreover, clients can be connected from behind a firewall, making it impossible for a server to reach the client.
For comparison, pull technology is the more traditional process of a client connecting to a server and requesting data.
Your best bet for Apple iOS will be using their push notification service.
For Android devices you should use the Google Cloud Messaging for Android. Alternatively, you can create your own background service to handle the messaging; here's a guide.
For Windows (desktop at least), you will have to create your own service to perform such duty. Here's an MSDN guide explaining how to create a Windows Service using Visual Studio (VB and C#). There might be frameworks already built that handle such messaging on Windows, however, I don't know of any.
Use WebSocket (with or without socket.io).
In the future, you could use WebRTC.
With Websockets, the setup is really simple. The client (a user agent, like a browser or a WebView) connects to the Websocket server, over http(s) (less problems with firewalls) and that's it. There's a bidirectional socket with an event-based API.
If by "OS integration" you mean "write special code for each platform" then the answer is no.
As you mentioned, you would like file system access, and background processing. That combination is not available in a cross-platform way at this moment.
If by "OS integration" you meant "without having to wait for apple/google/ms to provide the ability" then the answer is yes/maybe.
All the popular platforms have Push notifications and background processing support, as long as you code it the way each particular platform expects it.
But file system access will be limited to what restrictions the platform places on you. For instance in ios and win8(phone) there is no wy to write or read a file outside of your own apps private file structure. For security reasons, you cannot access the file system of other apps.
UPDATE:
The general pattern here is to release an app for every platform you want to support.
The app will register itself with its respective platform's push notification service.
You will write generic server side code to accept the data you want to push to all your client devices. Then you will invoke the respective push API's for each platform you support, causing the client devices to wake up and trigger the app that you provided to respond.
When the app opens, you get the app to contact your server and download the full data "the push notification being just the wakeup call for your app"
This way you can easily tell how which of your devices have received the data.
Each platform specific app must save the data to its own local storage and provide a way for the data to be shared via the methods supported by its respective platform.
On IOS it can be as simple as supporting the "Open In.." paradigm.
On W8Phone, you'll have to publish the data via one of the available "sharing contracts"
And so forth for every platform you want to support.
This is the general pattern at the moment. There are some caveats. On IOS, the app will nt automatically start when a push notification is received. This means your app will only download the whole of the data when the app is opened by the user.
A mobile app also cannot generally run indefinitely in the background. This means that once the app is started, you have a limited window for push notifications to be automatically processed by your app. After the allowed "background time". The app will close and any push notifications beep on the device, but wont open the app until the user taps on one of the notifications or opens the app directly.
Technically you could use XMPP Libraries, it is meant for implementing chat system (msn, gtalk, facebook chat, etc...) but this could work well as a push message system because it is opensource and well built to handle all the cases you never thought of. Also you could host your own server and send push message that way...
Why not use a webservice? In my previous project I used webservice to deliver data from mysql database. The webservice I used was nusoap. On the client side I used kSoap library for Android. Hope this helps.
if you want to receive and send real time communication between a server and client (irrespective of the device or OS), i would highly recommend you use XMPP technology because it is designed for the sort of things you're asking for.
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. The core features of XMPP defined in [XMPP‑CORE] provide the building blocks for many types of near-real-time applications, which can be layered on top of the core by sending application-specific data qualified by particular XML namespaces.
http://xmpp.org/rfcs/rfc6121.html#intro - that is the latest RFC which will give you a good starting point.
I do an application design for a soft real-time software application now.
The application will probably need to notify its mobile users about some events in the system. An event can happen during a 15-minute time frame which starts after the user's first interaction with the system. The event notification should be done in soft real-time: if a user notified later than 15-20 seconds he was supposed to be notified, then it is critical. Basically, I need to notify a mobile user about an event no later than 15-20 seconds after that event happens during a 15-minutes time frame.
I plan to do that with some kind of PUSH technology (XMPP/Jabber, native app with Comet connection or maybe PUSH email).
Unfortunately, the most obvious solution which is to have mobile web-site (example: http://www.lightstreamer.com/) with real-time push notifications is not suitable, because in that case the user will have to stare at the screen during all the 15-minute time frame. Notifying a user with a sound or a vibration would be a much more pleasant user experience (connect to the system via smartphone -> start interaction with the system -> put the smartphone back into the pocket or a bag -> get notified).
I have done a simple experiment by sending Jabber chat messages between my laptop (WiFi/100Mbit) and my Android smartphone (GPRS/3G). The thing is that some of the messages sent to the smartphone are late (it takes about 1 minute until they arrive at the smartphone) or just lost (they never arrive at the smartphone). Moreover, I have noticed that the Jabber client at the smartphone goes offline regularly for a few seconds. I do not know if it is because I have a very cheap Android smartphone or because the 3G connection is not very good, but this behaviour is not acceptable for the software application that I design.
Thus, I am interested in the following:
is there any technology standard that can guarantee pushed message delivery to mobile (GPRS/3G) consumers in soft real-time? I.e. a technology standard which guarantees that a mobile client will be notified no later than N seconds from now;
do you know any examples of mobile apps which have soft real-time push notifications?
what are the ways to address the issue of delivering/pushing soft real-time messages to mobile devices in soft real-time? (e.g. keep sending the same message until the mobile device confirms the receipt of the message)
P.S. The intended use of the software application is with any smartphone, be it iPhone, Android, WP or any other internet-connected smartphone.
Note: This question is similar to one of my previous questions, but this one is about on a completely different use-case with strong focus on soft real-time requirements.
I know that this question is 3 years old but it doesn't have any answer.
A PUSH notification is always Best Effort. It means that the server will do it's best to deliver it but can not guarantee that it will be done on time or if it will be delivered at all.
Never rely on PUSH notifications to achieve a critical job.