I have an ASP.NET Owin Web Api which is load balanced, which means there are multiple instances of it which don´t know each other. The web api hosts a SignalR hub with an SQL Server Backplane (for synchronising between instances), so clients can exchange messages regardless of which instance of the web api they are connected to. Everything working so far.
Client session data is stored in the db. The web api needs this info for processing requests for the client. Because it would be too slow to read the session data from the db for every client request, the web api is reading it only once (on first request from the client session) and caching it in-memory. This also works across multiple instances of the web api as every instance is holding it´s own session data cache.
But now the clients should be allowed to change for example the language, which results in an updated language in the session data stored in the db. The web api instance which processes the "change-language"-request of course can react to the changed session data and clear the session from it´s cache, which will lead to a reread of the session data from the db on the next client request. But the other web api instances don´t know about the session data change, their caches now hold outdated session data.
The web api instance which processes the "change-language"-request would somehow need to notify the other instances to drop their cache for session xyz. Unfortunately the instances don´t know each other, but all instances host SignalR hubs which are synchronised through the SingalR SQL server backplane.
Unfortunately a SignalR hub cannot directly send and receive messages. A HubConnection (client) is needed to do that. So the idea is when every web api instance is connecting to it´s own SignalR hub, it would be able to send messages to itself, which are then spread out to the other instances via the SQL server backplane synchronisation. But a HubConnection can only be established with an URL (http://host:port/signalr) but the web api instance doesn´t know it´s own base url.
So finally my question is:
Is there any way to establish a HubConnection to a hub running in the same process without providing an URL (I have access to the hub object)?
If not, is there any way for a SignalR hub to spread out messages and listen to messages through the backplane without a client (hub-2-hub communication)?
If not what else could I do to notify other instances of my load balanced web api and advice them to drop their session data cache?
Solved through distributed caching (IDistributedCache), as mentioned by Panagiotis Kanavos in the comments.
Related
I'm looking for a way to support the following process:
Button is clicked in web application running on machine named PC1234.
Call is made to server (either the web server or an API on another server, it doesn't matter) to Do Something.
The server sends a notification to a Windows Forms client installed on PC1234 that the action is complete.
I've got the easy part working using SignalR. I can call a method on the web server and then send a notification with SignalR to ALL clients that the method has completed. The problem is notifying ONLY the client on the originating machine.
My initial plan was to include some unique identifying attribute of the machine with the call to the server which could then be used to direct the SignalR notification back to just that machine, but that doesn't seem to be possible.
An alternative idea was to have the call to the server include a unique reference and also update a file locally (i.e. a Cookie) with that reference, then have the client app poll the Cookie for new references and filter all SignalR messages received for that unique reference. This would be a bit clunky even if it worked, which it doesn't really, not least because I want this to work cross-browser, and different browsers store cookies in different places.
Ultimately this is to support printing locally and silently from a web application. The user selects a document in the web application, hits a print button, the request is sent to the server which retrieves the document from the database, saves it to a network share and sends a notification to a client app on the machine from which the print request was generated. The client app then prints the document from the network share and deletes it.
I never found a way to do exactly what I described in my question, but I came up with an alternative which worked well enough.
In both my web application and my Windows Forms client, the user was logged in with the same Windows credentials. I was therefore able to have the server respond to the button click in the web application by broadcasting a SignalR message to all SignalR clients where the same user was logged in, using
Clients.User(userId).send(message)
See this article for more detailed examples and instructions.
In my Windows Forms client, I included code to track how many instances of the client were connected to the SignalR Hub with the same user credentials and code to handle the receipt of a SignalR message from the server when multiple client instances were connected with the same user details (in my case, this meant displaying a message saying something like "You've requested a print from the web application but you're logged in at multiple workstations. Do you want the document to print here?").
What we have is an ASP.NET web app that also does some signalR notifications. Since SignalR cannot access ASP.NET session states we need some other way to validate they are a client logged in on the web app.
In most situations you would think a static dictionary would help. As long as one of the ASP.NET Controllers made sure to keep a cache of key client info (via IP/browser info, or some generated token the client send up to signalR later) -- as long as this was done, then SignalR could validate the client connection before adding it to its pool.
However we are working in a server-farm situation, with SessionState backed by SQL. What this means is that a given server instance, even if it had a static cache of all its clients, may not know about Client C. Of course if Client C made a normal web request, it would find out about Client C when it fetched the SessionState. So the question is, IF work is handed over to a second server instance (Machine B) at just the right/wrong time, where Machine B does not know about client C (except via a context-dependent SessionState fetch, inaccessible from SignalR), HOW could we validate the client on the SignalR side?
All it would require is for some static means of getting ALL clients, OR, simply a "static" context for SessionState (i.e. a server-Session State). Because either way, we could sift through the individual client SessionStates and validate "yes, this client had a session state on a previous machine".
Is there any other way than for the client to reload the page, so that ASP.NEt can "cache up" its info locally? That is the only way I see so far.
I think it's a perfect scenario for "SignalR Backplane", it's designed for a webfarm situation to Scaleout SignalR. Lots of articles available, please search.
Using SignalR, is it possible to update website clients from my WCF service if the service is not used by these clients directly?
I have a desktop application in .NET which has WCF service used internally using net.TCP protocol. This application changes one of the status fields in database table depending on certain user actions. I want to notify this change to end users who are accessing a different website hosted on the same web server.
I have tried one SignalR sample where notification works fine if it is sent from same website's host to its own client (stock ticker sample). But in my case, the message should go from WCF service to a website client.
IMO you should do an intermediate hop, for example having your website exposing an endpoint (you pick the technology) where you can post whenever you have a change to notify. Your WCF service would post there whenever there's a change, and the web app would process the post by broadcasting info to the target clients (can be all, or can be just some you filter with some logic behind the post). I use this pattern quite frequently, implementing it with HTTP POST. You would have no issues to implement the SignalR infrastructure in the web app, which is where your clients already connect to.
I have a WCF service hosted at IIS7 web application. It's created by a WebServiceHostFactory. The client connects to a service calls the Collect method, and data are stored to DB. All working fine.
Now I would like to refresh page every time the new data are "collected" (i.e. the service method Collect is called).
My question is: What is the best approach ?
I was considering the CallbackContract, but this would require a singleton pattern (service is now PerCall), or is it a wrong assumption ? Is this approach possible ?
My logic is:
ASP.NET page subscribes to WCF service
the service singleton is created from now on
when method is called the services calls subscribers (clients)
there should be therefore only one service instance in order to subscription to work (or is it ?)
the client page refreshes itself
regards,
Kate
You can't refresh the page in a user's browser from the sever. Browsers use HTTP, which is a request-response protocol, so if the browser hasn't issued a request, it won't be looking for a response from your server.
If you have a Silverlight application hosted in a browser, that's a different story, but you didn't mention Silverlight anywhere. You would also be able to do what you're asking using WebSockets in HTML5, but that's not fully standardized yet.
I have an ASP.NET application that calls other web services through SSL (outside the application). I simply added a web reference (https://url/some.asmx) and used the web services and it works well. However, my questions are, how is the connection (channel) managed? is the connection to web services dropped after each web services call? or do they use the same connection (channel) for the subsequent calls? if they do, how long is the trusted connection kept alive?
Classic ASMX web services maintain the connection for a single request - that's why the methods you call via the web service class must be static. A SOAP call is very similar to a plain vanilla HTTP Request:
Open connection to URL
Pass in request - get/post, etc
Server renders an XML (SOAP) response
Connection is closed
Client processes response.
The web service framework wraps most of this so that you can conveniently access the web service as if it were a local object, but there is no server-side object instance persistence any more than there is for an ASPX page.
WCF services, on the other hand, maintain the connection until the proxy object is closed. This gives you a LOT of power, but, of course, with great power comes great responsibility.
update: link regarding ssl caching:
http://social.msdn.microsoft.com/forums/en-US/asmxandxml/thread/f86066e0-a24b-4d5e-873c-ed427d1faef7/