I have a chat SignalR server, the chat support group chatting.
I also have a server which actually creates the groups and other group managment tools.
Whenever a user leaves a group (via http post ) to server, I want the chat service to trigger some methods, such as LeaveGroup and some other logictics.
I bound the connectionId to userId so I got the parsing request covered.
QUESTION IS: What is the best practice of communication between server/service and the signalr server.
Taking in mind, I dont want to compormise on scalability on each of my servers/services.
My idea is more or less host a web api server inside the SignalR server, but I can't seem to find any topics suggesting that could damage the performance.
Ideas?
Thanks alot.
p.s
I know that there is no code involved in here. but it seems irrelevant. I have self hosted web api in a window service I have, so the code is pretty much the same.
I would love to provide more data/information if thats neccesary
It seems like this documentation is most applicable to what you're trying to do: https://www.asp.net/signalr/overview/getting-started/tutorial-server-broadcast-with-signalr
It speaks specifically about how to communicate from your server/service application to the signalr clients. Communicating from the client to the server/service could be done either through the signalr hub, or with other web API.
From a best practice perspective, the documentation specifically states (https://www.asp.net/signalr/overview/guide-to-the-api/hubs-api-guide-server#callfromoutsidehub):
If you need to use the context multiple-times in a long-lived object,
get the reference once and save it rather than getting it again each
time. Getting the context once ensures that SignalR sends messages to
clients in the same sequence in which your Hub methods make client
method invocations. For a tutorial that shows how to use the SignalR
context for a Hub, see Server Broadcast with ASP.NET SignalR.
If you're really into scalability, you might want to look into integrating your signalr communications into some other message queueing system, but that's probably overkill for most circumstances.
Related
I have an older C# app that is being migrated to the cloud. It uses SignalR, but only direct client/server connections. No SignalR service is involved yet.
I am extracting some processes that are well suited for an Azure function, but one feature I would prefer to not have to redesign for this MVP is a SignalR message back to the user that tells them the percent complete for this job.
I am reading the MS documentation from here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-signalr-service-output?tabs=in-process&pivots=programming-language-csharp focusing on Isolated-Processes.
I can see how I can send messages to the Azure SignalR service, but I am unclear how I might be able to just send a message back to the caller.
I would really like to set up a simple Hub and send messages directly to the client as the function progresses.
I would suggest giving web pub sub a look? Microsoft has a good comparison article here. Summary, it is a bit more language agnostic, and if you're already using azure then it has less setup overhead than SignalR.
https://dev.to/albertbennett/how-to-azure-pubsub-service-2ccb
I was wondering if there was an established pattern for doing what I'm trying to achieve. It seems a fairly common scenario so I'd be surprised if there wasn't, however I'm unable to find anything. The main technologies I'm using:
ASP.NET MVC4
SignalR
Redis (using the ServiceStack API)
I would like to subscribe to messages from Redis and publish these to end-users using SignalR.
Rather than setting up a new Redis connection for each end-user, I would like to maintain one subscription per topic/channel. Each topic would then have its own SignalR hub, which the end-users would subsequently subscribe to. So essentially redis topic --> signalR hub --> many users.
My questions revolves around how to maintain these subscriptions. They are (by nature) blocking, which is a problem when dealing with web applications. Is it safe for me to simply create a separate thread to handle each topic's subscription, or is there a better way of doing this? Or have I misinterpreted the problem entirely?
I'm fairly new to web development, so any thoughts would be appreciated.
In a previous solution, I recall setting up code-behind-type hub connections for unit testing. I believe I used code from the previous SignalR Hubs C# Client GitHub wiki.
In the SignalR Hubs API guide there is an example of using a console-based client:
stockTickerHubProxyProxy.On("Notify", () => Console.WriteLine("Notified!"));
In an upcoming application there will be notifications to be pushed to several clients. Some of these clients will be UI-based (JS), and others, will be some back-end code that will perform some task.
I am familiar with the JS-based client connectivity. My question centers around attaching code-behind-type clients, and how their methods "notified".
I understand that with a UI-based client, the mechanism is to push the update to the client through dynamic invocations to client-side "methods". Since it's been a few months since I've touched SignalR, what is the best way to accomplish this where there is no UI involved?
To verify that I am understanding the documentation correctly , when valid transport method is used, a C#-based (non UI/JS) client is notified (push) through the SignalR framework - no client polling required?
The essential mechanism is the same for JS and C# clients. The solution is exactly what you mentioned in your question. The 'On' method will subscribe the client to any "notify event" triggered by the server. You can refer to the documentation to get a better understanding:
http://www.asp.net/signalr
I have a Windwos Application (Let's name it App) and a WebService Project (name it WS) and a SqlServer Database (DB), and the technologies are all from Microsoft and .net.
The roles are that whenever App needs to do an action, it calls WS and WS does the magic work with DB and then returns the result to App.
So far, so good, but I need something more than that. I need a third Application, let's call it a Robot, this Robot monster should have the ability to find all alive clients (App instances) and not kill, but call them on some specific times, then the App(s) will decide do an action on being called.
My information lacks here, and that is why I want you guys to help me find the best solution for this Server-Calls-Client-And-Client-Does-Something thing.
I have very short handed and pragmatic solution ideas:
Each client application invokes a method for instance YesIamAlive() of the webservice each x seconds/minutes. If the server gets this request it will be saved so you are be able so see which clients are alive. Each client which not sending an alive request for the last x seconds / minutes is not any longer alive. Another method which is also called on a routinely basis and it forces the client to do an action.
You could use SignalR for a websocket communication between your server and client. This example shows a chat server, which is not simular to your request but it shows the idea behind it:
http://braindrivendevelopment.com/2013/01/28/signalr-with-windows-azure-cloud-services/
I am quite sure that there are even more elegant solutions for your problem.
SignalR (GitHub) is an excellent framework for "pushing" to clients in near real-time. It works with both web and WinForms clients.
I'm about to start to develop and application in C# but I realized that I haven't the enough knowledge to develop it yet :S.
The thing's that I need to find out a way to let the Web server comunicate with my application, i.e., in short, is there a way to let the web server (not the Client which is the trivial case) send a messege to a Client application?
I know that I way to solve it's to make Client applications periodically send messages to the web server but that's not what I want 'cause polling generates overhead
Sorry about my english! I'm not a native speaker.
Thanks in advance!
Generally this type of interaction is achieved with Comet or WebSockets - I'm not sure how your app will be communicating with the server, but I would bet you can do what you're trying to do using one of those.
You could implement a WCF service in your client that could listen for a connection from the server (or anything else). The server can communicate with the client as easy as calling the API.
Getting started with WCF is really easy using the wizards in VS.
Here is a link that talks about using WCF with ASP, but it can be used outside of asp as well.
It seems like you meant "push" messaging, the challenge around this is for the server to keep track of the lost of clients and manage who should recieve which message.
If you want to get it done with minimal overhead you can check out the Amazon Simple Notification Service.
SNS is a cloud-based messaging and notification service hosted and managed for you, SNS is based on a topic/subscriber model and you set it up via a few simple API calls, it is metered but quite inexpensive for the most part.
edit: For C# Libraries and frameworks to do it yourself, I am not an expert in the C# world so I think other answerers will know it better.
Disclosure: I work at amazon so I am naturally inclined to like their product