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.
Related
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
As per the KAA references, I understand that once should only use the Notification feature, When it required to send data from server (External apps) to endpoints and Events are only used when there is a need for endpoint to endpoint communication (kind of device binding requirement)
So, To achieve request/response functionality using KAA. I need to implement any hybrid solutions like as below.
1) In my server, I can run one KAA SDK instance and use the event feature for request to the endpoint and response from the endpoint.
OR
2) From my server, I use the notification REST API for request and get the response back through the data logger feature using any in-build appender by configuring "LogUploadStrategy" as to uploads every log record as soon as it is created.
Notes For Point 1
As per Andrew, Solutions Architect of Kaa IoT platform
"You can always embed an SDK to a standalone application and host in
on the same server where kaa-node is present. This application may
receive REST API calls and forward them to particular endpoints via
Kaa events feature. However, this is useful for test purposes. I
would not recommend this solution in production because it is hard to
scale and has potential security issues"
Notes For Point 2
It satisfies the KAA reference document as well as Andrew's suggestion for request only but how can i achieve the response.
Questions For Point 1
1) What causes to scale the application and what type of security issues it faces even through it uses RSA 2048 encryption for communication?
2) Can we embed more then one SDK in standalone application and host in on the same server where kaa-node is present.
Questions For Point 2
3) if device sends the notification response along with the telemetry data, can it increase the latency and any other performance issue.
Common Questions
4) Which one is the better approach to achieve request/response functionality?
Any help or suggestion is really appreciated.
1) What causes to scale the application and what type of security issues it faces even though it uses RSA 2048 encryption for communication?
It makes the EP on the server side as a single point of failure and does not allow load balancing.
About security issues, Andrew meant: This application may receive REST API calls and this forces one to provide additional security for this REST API calls and better use your first hybrid solutions using solely event feature.
2) Can we embed more then one SDK in standalone application and host in on the same server where kaa-node is present.
No, you can't use more than one SDK in one application, but you can run a couple of instance on one machine in different directories
in order to prevent collisions of autogenerated security keys and other files.
3) if device sends the notification response along with the telemetry data, can it increase the latency and any other performance issue.
Of course, you will face some delays if start sending very frequently and big portions of data on both sides. If you have a lot of devices that sends in total a big amount of telemetry data, you can increase performance on the server side by start-up KAA in the cluster mode or add new nodes for processing requests.
4) Which one is the better approach to achieve request/response functionality?
The second hybrid solution – data collection and notification features. This doesn't cause any problem with scale and you can easily launch Kaa server in cluster mode.
I was assigned with the re-architecture of a legacy (medical) product which is controlling several external devices. In the current architecture, we have several such stations in each customer's network, where each station is processing its own data, and they all share some of that data via a central server (that talks to the DB and BLOB storage).
I'm planning the new architecture such that it will allow more scenarios, such as monitoring the stations through a web interface, and allowing data processing to be scalable by adding additional servers.
This led me to choose NServicebus as the messaging and communication infrastructure. And I pretty much have a clear view of the new architecture.
However, another factor was recently added to the equation by my manager. He requires that the machine that communicates with the devices (hardware), will not be under the IT policies of the customer. The reason behind this, as I understand, is that we don't want the customer's IT to control OS updates, security, permissions and other settings, because we want full control over that machine in order to work properly with our hardware.
My manager thus added a requirement that this machine will be disconnected from the customer's LAN.
If I still want to deploy NServiceBus on that separated machine (because I want to pub/sub async messages to other machines - some are on the customer's LAN and some aren't), Will it require some special deployment? Will it require an NServiceBus gateway?
EDIT: I removed the other (1st) question, as it wasn't relevant to the scope of StackOverflow.
Regarding question 2, yes it would require the use of a "Gateway", however the current NServiceBus Gateway implementation does not support pub/sub so you would have to look at alternatives.
I have an existing application (WPF) that monitors OPC Servers and alarms. There is a requirement for this to be accessible via a browser so that users can view the status of alarms etc remotely. I'm feeling out of my depth (I'm not a Web developer) and I just need some advice on the best technology to accomplish this.
I've written several WCF Services, but all these have done is, via a function call, crunch some data sending back a result.
This 'service' will have to be persistent and able to be interrogated by x number of clients. For example, a client will need to be able to connect, stay connected and be informed of events as an when they happen. This has been a major problem in the past when I've developed WCF services (channel faults etc) and I've learnt to only keep a connection open for as long as it's needed. Is a WCF Service the best option in this case (as opposed to a normal Window's Service)
I need to be able to 'push' information from the service to clients. So, someone navigates to a webpage, the page shows in realtime, what is happening in the service. Do I need to use timers since this could be big problem if session state cannot be maintained.
I've read about Observer Design Pattern, but can this be implemented in ASP.net and how would ASP connect (and remain connected) to a remote windows service? Again, do I have to resort to timers?
I apologise it this appears vague, but the situation boils down to the following:
A process that's continually running (somewhere), receiving connections from remote clients (desktop/web), and then keeping the clients informed as events (alarms going off etc) occur.
Consider a web application such as Google Chat, where the servers serve hundreds of millions of clients simultaneously. In such application, the servers have to push notifications to clients at near real time (in the chat example - incoming messages, presence notification etc.).
How do they implement it? Significant part of the clients are browser based. I suppose polling would overload even Google's servers. So, are they using something like Comet? If so - do they need to allocate a server for every 65536 clients (maximum TCP connections per machine)? I understand that there is a way to circumstance this limitation but I don't know how it's implemented.
Chat is not handled by single application / hardware / instance.
They definitely using many instances with load balancing that allows to scale chat system horizontally. It might be dedicated for regions or just single clustered system (I believe it is dedicated within regions but still clustered within region).
As well you can have as many connections as hardware and network will handle but not 64k.
Because 64k (actually less then that) is regarding Binding sockets (server sockets, but not client ones).
In case with google and based on supported browsers, they definitely use mixed technologies to communicate selecting the most powerful based on browser support. That can be long-polling, sockets and even oldest one: simple ajax.
As well for example facebook chat is based on erlang. And using erlang there is many examples having more then million connections.
I don't know how Google handle this, ans they probably won't tell us. But, today you can deal with http streaming, websockets or long polling to build such application. To give you an example Atmosphere framework
is a tool to build "real-time", efficient and scalable web application.