I have a web application composed of a gateway and several back-end services.
The gateway is a self-hosted OWIN application, and covers concerns like authentication, authorization, and routing of api calls to the backend.
I'm interested in using SignalR in one of my backend services to push data to the client. E.g. the user starts a long running query, and data is fed back to the client as it becomes available.
I managed to use the backplane from the scale-out article as a messaging mechanism (though it seems it wasn't designed for such messaging)
SignalR scaleout explanation
"Gateway" Hub code: (The logic is only for testing purposes)
public override async Task OnConnected()
{
HttpClient client = new HttpClient()
{
BaseAddress = new Uri("http://localhost:8888/other/")
};
var result = await client.PostAsJsonAsync("signin", Context.ConnectionId);
await base.OnConnected();
}
Backend controller code
[HttpPost]
[Route("signin")]
public void PostSignin([FromBody]string id)
{
StartPing(id);
}
public async Task StartPing(string id)
{
var context = GlobalHost.ConnectionManager.GetHubContext<FrontendHub>();
int i = 0;
while (true)
{
i++;
context.Clients.Client(id).showMessage("num " + i);
await Task.Delay(1000);
}
}
However, this is a big enterprise application, and I don't want the gateway to have any dependency on the actual code of the backend services. But the example only works if a hub with the same name is defined in both the gateway and the backend service.
On one hand, I'm trying to avoid the need to place such specialized code in the gateway, on the other hand, I'd like to leverage the ability to use actual function names and parameters. I don't want a "master hub" with a single function.
Is there a way to do it?
Didn't end up doing it all, but the solution discovered later was to indeed use a "Master hub", but it doesn't actually need to have any functions at all.
The contract is between the backend service and the client application. Since everything in SignalR is loosely typed, it's enough that the client define some function on the hub, and the backend service invoke the same function on the hub. The hub doesn't actually need this function in its own code.
Related
This article shows a well-known problem with HttpClient that can lead to socket exhaustion.
I have an ASP.NET Core 3.1 web application. In a .NET Standard 2.0 class library I've added a WCF web service reference in Visual Studio 2019 following this instructions.
In a service I'm using the WCF client the way it's described in the documentation. Creating an instance of the WCF client and then closing the client for every request.
public class TestService
{
public async Task<int> Add(int a, int b)
{
CalculatorSoapClient client = new CalculatorSoapClient();
var resultat = await client.AddAsync(a, b);
//this is a bad way to close the client I should also check
//if I need to call Abort()
await client.CloseAsync();
return resultat;
}
}
I know it's bad practice to close the client without any checks but for the purpose of this example it does not matter.
When I start the application and make five requests to an action method that uses the WCF client and then take a look at the result from netstat I discover open connections with status TIME_WAIT, much like the problems in the article above about HttpClient.
It looks to me like using the WCF client out-of-the-box like this can lead to socket exhaustion or am I missing something?
The WCF client inherits from ClientBase<TChannel>. Reading this article it looks to me like the WCF client uses HttpClient. If that is the case then I probably shouldn't create a new client for every request, right?
I've found several articles (this and this) talking about using a singleton or reusing the WCF client in some way. Is this the way to go?
###UPDATE
Debugging the appropriate parts of the WCF source code I discovered that a new HttpClient and HttpClientHandler were created each time I created a new WCF client which I do for every request.
You can inspect the code here
internal virtual HttpClientHandler GetHttpClientHandler(EndpointAddress to, SecurityTokenContainer clientCertificateToken)
{
return new HttpClientHandler();
}
This handler is used in to create a new HttpClient in the GetHttpClientAsync method:
httpClient = new HttpClient(handler);
This explains why the WCF client in my case behaves just like a HttpClient that is created and disposed for every request.
Matt Connew writes in an issue in the WCF repo that he has made it possible to inject your own HttpMessage factory into the WCF client.
He writes:
I implemented the ability to provide a Func<HttpClientHandler,
HttpMessageHandler> to enable modifying or replacing the
HttpMessageHandler. You provide a method which takes an
HttpClientHandler and returns an HttpMessageHandler.
Using this information I injected my own factory to be able to control the generation of HttpClientHandlers in HttpClient.
I created my own implementation of IEndpointBehavior that injects IHttpMessageHandlerFactory to get a pooled HttpMessageHandler.
public class MyEndpoint : IEndpointBehavior
{
private readonly IHttpMessageHandlerFactory messageHandlerFactory;
public MyEndpoint(IHttpMessageHandlerFactory messageHandlerFactory)
{
this.messageHandlerFactory = messageHandlerFactory;
}
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{
Func<HttpClientHandler, HttpMessageHandler> myHandlerFactory = (HttpClientHandler clientHandler) =>
{
return messageHandlerFactory.CreateHandler();
};
bindingParameters.Add(myHandlerFactory);
}
<other empty methods needed for implementation of IEndpointBehavior>
}
As you can see in AddBindingParameters I add a very simple factory that returns a pooled HttpMessageHandler.
I add this behavior to my WCF client like this.
public class TestService
{
private readonly MyEndpoint endpoint;
public TestService(MyEndpoint endpoint)
{
this.endpoint = endpoint;
}
public async Task<int> Add(int a, int b)
{
CalculatorSoapClient client = new CalculatorSoapClient();
client.Endpoint.EndpointBehaviors.Add(endpoint);
var resultat = await client.AddAsync(a, b);
//this is a bad way to close the client I should also check
//if I need to call Abort()
await client.CloseAsync();
return resultat;
}
}
Be sure to update any package references to System.ServiceModel.* to at least version 4.5.0 for this to work. If you're using Visual Studio's 'Add service reference' feature, VS will pull in the 4.4.4 versions of these packages (tested with Visual Studio 16.8.4).
When I run the applications with these changes I no longer have an open connection for every request I make.
You should consider disposing your CalculatorSoapClient. Be aware that a simple Dispose() is usually not enough, becaue of the implementation of the ClientBase.
Have a look at https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/use-close-abort-release-wcf-client-resources?redirectedfrom=MSDN, there the problem is explained.
Also consider that the underlying code is managing your connections, sometimes it will keep them alive for later use. Try calling the server a lot of times to see, if there is a new connection for each call, or if the connections are being reused.
The meaning TIME_WAIT is also discussed here:
https://superuser.com/questions/173535/what-are-close-wait-and-time-wait-states
https://serverfault.com/questions/450055/lot-of-fin-wait2-close-wait-last-ack-and-time-wait-in-haproxy
It looks like your client has done everything required to close the connection and is just waiting for the confirmation of the server.
You should not have to use a singleton since the framework is (usually) taking good care of the connections.
I created an issue in the WCF repository in Github and got some great answers.
According to Matt Connew and Stephen Bonikowsky who are authorities in this area the best solution is to reuse the client or the ChannelFactory.
Bonikowsky writes:
Create a single client and re-use it.
var client = new ImportSoapClient();
And Connew adds:
Another possibility is you could create a channel proxy instance from
the underlying channelfactory. You would do this with code similar to
this:
public void Init()
{
_client?.Close();
_factory?.Close();
_client = new ImportSoapClient();
_factory = client.ChannelFactory;
}
public void DoWork()
{
var proxy = _factory.CreateChannel();
proxy.MyOperation();
((IClientChannel)proxy).Close();
}
According to Connew there is no problem reusing the client in my ASP.NET Core web application with potentially concurrent requests.
Concurrent requests all using the same client is not a problem as long
as you explicitly open the channel before any requests are made. If
using a channel created from the channel factory, you can do this with
((IClientChannel)proxy).Open();. I believe the generated client also
adds an OpenAsync method that you can use.
UPDATE
Since reusing the WCF Client also means reusing the HttpClient instance and that could lead to the known DNS problem I decided to go with my original solution using my own implementation of IEndpointBehavior as described in the question.
For SignalR 2.1, how do I maintain a list of Client methods the Server's Hub can call?
According to Differences between SignalR and ASP.NET Core SignalR - Hub Proxies, "Hub proxies are no longer automatically generated."
Is there an existing solution to maintain a list of Client methods the Server's Hub can call?
Looking for a solution that defines Client methods to be called by Server Hub before we decide to roll our own with Code Generation.
Looks like Hub and IHubContext take T type parameter for the type of client that you can make an interface for. Can't find any documentation specific to dotnet core other than the source code and comments but look like this is a carry over from .net
https://blog.scottlogic.com/2014/08/08/signalr-typed.html -> "Calling client hubs - New and Improved"
public interface IMyHubClient
{
void Ping();
}
public class MyHub : Hub<IMyHubClient>
{
...
}
I have multiple restful API components implemented using ASP.NET Core. I am not using Event Driven Design or any messaging broker service.
I want to keep it simple, so
Let's say I have 3 restful independent components (with independent ASP.NET Core Projects) that are published to the same IIS in addition to the Identity server provider:
Navigation: that retrieve menus from its own database
Authorization: that deals with the permissions and security
Notifications
Identity Server: provides Jwt access tokens for authenticated users to authorize him access the apis.
Apart from the external communication from the client to the Apis where an API Gateway should handle all client requests. There are some sort of communication that is done internally. A good example is getting menus for the user:
The user gets an access token after successful log in
Then he requests the menus he can view, so a request is forwarded to Navigation API
Navigation API issues an internal request to Authorization API in order to check what permissions the user has to limit his access to certain menus.
Right Now, I am managing the communication by a common library called Service Proxies, which has all the api urls hard coded in cs file (which is just for trying the concept)
public static class Config
{
public static class ServiceURLs
{
public const string AuthorizationAPI ="http://localhost:port/api/Authorization/" ;
}
}
public class AuthorizationServiceProxy : IAuthorizationServiceProxy
{
//ServiceProxy is a custom class that issue http requests in order to get responses
private ServiceProxy _serviceProxy;
public AuthorizationServiceProxy(string accessToken)
{
_serviceProxy = new ServiceProxy(Config.ServiceURLs.AuthorizationAPI, accessToken);
}
public async Task<List<Permission>> GetUserPermissions()
{
var route = "GetUserPermissions";
var result = await
_serviceProxy.GetHttpResponseContentAsType<List<Permission>>(route);
return result;
}
AuthorizationProxy and all proxies will be just to issue a request from an API to another one.
How would an interprocess communication would be handled in my case?
I have a web application which has few charts on dashboard. The data for charts is fetched on document.ready function at client side invoking a WCF service method.
What i want is now to use SignalR in my application. I am really new to SignalR. How can i call WCF methods from SignalR Hub or what you can say is that instead of pulling data from server i want the WCF service to push data to client every one minute.
Is there a way of communication between signalR and WCF service.
Also another approach can be to force client to ask for data from WCF Service every minute.
Any help will be really appreciated.
I have done following as of yet.
Client Side Function on my Dashboard page
<script src="Scripts/jquery.signalR-2.0.3.min.js"></script>
<!--Reference the autogenerated SignalR hub script. -->
<script src="/signalr/hubs"></script>
<a id="refresh">Refresh</a>
$(function() {
var dashboardHubProxy = $.connection.dashboardHub;
$.connection.hub.start().done(function() {
// dashboardHubProxy.server.refreshClient(parameters);
$("#refresh").click(function() {
dashboardHubProxy.server.refreshClient(parameters);
});
});
dashboardHubProxy.client.refreshChart = function (chartData) {
debugger;
DrawChart(chartData, 'Hourly Call Count For Last ' + Duration + ' Days', '#chartHourly', 'StackedAreaChart');
};
});
and my Dashboard Hub class is as follows
public class DashboardHub : Hub
{
private readonly ReportService ReportService = new ReportService();
public void RefreshClient(string parameters)
{
var chartData = ReportService.GenerateHourlyCallsTrendGraphicalReport(parameters);
Clients.All.refreshChart(chartData);
}
}
My SignalR startup class is as follows
[assembly: OwinStartup(typeof(CallsPortalWeb.Startup), "Configuration")]
namespace CallsPortalWeb
{
public static class Startup
{
public static void Configuration(IAppBuilder app)
{
ConfigureSignalR(app);
}
public static void ConfigureSignalR(IAppBuilder app)
{
app.MapSignalR();
}
}
}
When i click on refresh button and a debugger on RefreshClient method on hub the debugger doesn't get to the method which means i am unable to call server side method of SignalR.
Is there anything needs to be done in web.config?
I agree with AD.Net's comment. To elaborate slightly more though, the SignalR hubs can be hosted directly in your web project kinda the same way controllers are used. There is also a package out there so you can host the SignalR library on its own so it can act as a service all on its own. Either way you will need to hit the SignalR hub first as that is how it communicates then you would call your WCF service methods from within the hubs.
Brief explanation
Your HUB will have methods used by both your USER Client and your WCF Client. You may use something like UserConnected() for the user to call in and setup your logging of the connection. Then the WCF service may call your HUB with an UpdateUserStats(Guid connnectionId, UserStats stats) which would in turn call the USER client directly and provide the stats passed in like so Clients.Client(connectionId).updateStats(stats) which in turn would have a method on the USERS client named updateStats() that would handle the received information.
Initial page landing
What AD.Net provided is basic code that will be called when the user lands on the page. At this point you would want to log the ConnectionId related to that user so you can directly contact them back.
First contact with your hub touching WCF
From your Hub, you could call your WCF service as you normally would inside any normal C# code to fetch your data or perform action and return it to your user.
Method of updating the user periodically
SignalR removes the need for your client code to have to continually poll the server for updates. It is meant to allow you to push data out to the client with out them asking for it directly. This is where the persistence of the connections come into play.
You will probably want to create a wrapper to easily send messages to the hub from your application, since you are using WCF I would assume you have your business logic behind this layer so you will want the WCF service reaching out to your Hub whenever action X happens. You can do that by utilizing the Client side C# code as in this case your client is actually the user and the WCF service. With a chat application the other user is basically doing what you want your WCF service to do, which is send a message to the other client.
Usage example
You are running an online store. The dashboard displays how many orders there have been for the day. So you would wire up a call to the hub to send a message out to update the products ordered when a user places a new order. You can do this by sending it to the admin group you have configured and any admins on the dashboard would get the message. Though if these stats are very user specific, you will more then likely instead reach into the database, find the ConnectionId that the user has connected with and send the update message directly to that connectionid.
WCF Client Code Example
Just incase you want some code, this is directly from MS site on connecting with a .net client. You would use this in your WCF service, or wherever in your code you plan on connecting and then sending an update to your user.
var hubConnection = new HubConnection("http://www.contoso.com/");
IHubProxy stockTickerHubProxy = hubConnection.CreateHubProxy("StockTickerHub");
stockTickerHubProxy.On<Stock>("UpdateStockPrice", stock => Console.WriteLine("Stock update for {0} new price {1}", stock.Symbol, stock.Price));
await hubConnection.Start();
Here is a link directly to the .Net Client section: http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-net-client
I am sure you have seen this link but it really holds all the good information you need to get started. http://www.asp.net/signalr
Here is a more direct link that goes into usages with code for you. http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-server
ADDED: Here is a blog specific to Dashboards with SignalR and their polling.
http://solomon-t.blogspot.com/2012/12/signalr-and-interval-polling-for.html
ADDED: Here is a page on managing users signalR connections.
http://www.asp.net/signalr/overview/signalr-20/hubs-api/mapping-users-to-connections
Update for your code update
The .Net Client library (in NuGet) gives your .net code access to the hub. Since you are a client you will need to connect to the hub just like the User who is also a client. Your hub would act as the server for this. So with the .Net Client I am assuming you would setup a windows service that would internally poll, or something event based that would call the .Net Client code portion of it which would reach out to your hub. Your hub would take the information provided, more than likely a ConnectionId or GroupId and broad cast the User (which is perhaps on a website so it would be the JS client) a method that would update the front end for the user client. Basically what I mention under "Brief Explanation".
Now, to directly respond to the code you posted. That is Javascript, I would expect a connect like you have done. Updating the chart on initial connection is fine as well. If this is all the code signalR wise though you are missing a client side method to handle the refresh. Technically, instead of calling Clients.Caller.RefreshChart() you could just return that data and use it, which is what your javascript is doing right now. You are returning void but it is expecting a your date.
Now, I would actually say correct your javascript instead of correcting the hub code. Why? Because having a method in JS on your client that is called "refreshChart()" can be reused for when you are having your server reach out and update the client.
So I would recommend, dropping anything that is related to updating the dashboard in your JS done statement. If you want to do a notification or something to the user that is fine but dont update the grid.
Now create a JS client function called "refreshChart", note the lower case R, you can call it with a big R in c# but the js library will lowercase it so when you make the function have it will receive your dashboard information.
Now, on the server polling, or executing on some action, your WCF would call a method on the hub that would be say "UpdateDashboar(connectionId,dashInfo)" and that method would then inside of it call the "refreshChart" just like you are doing in your RefreshClient method, accept instead of doing Clients.Caller you would use Clients.Client(connectionId).refreshChart(chartInfo).
Directly the reason your code is not working is because you need to turn that Void into the type you expect to be returned. If the rest is coded right you will have it update once. You will need to implement the other logic I mentioned if you want it constantly updating. Which is again why I asked about how you are persisting your connections. I added a link to help you with that if you are not sure what I am talking about.
You should use the SignalR Hub to push data to the client. Your hub can consume a WCF service (the same way your client can) to get the data.
from client:
hub.VisitingDashBoard();
on the hub in the VisitingDashBoard method:
var data = wcfClient.GetDashboardData()//may be pass the user id from the context
Clients.Caller.UpdateDashboard(data)
Of course your client will have a handler for UpdateDashboard call
I have a WPF app which is going to be deployed to multiple users on a LAN. The users of this app will be factory workers in a manufacturing company, who will be using the app to update their progress on each order.
The customer also has an ASP.NET webforms app which is used for entering orders among other things. What I want to build in this ASP.NET app is a screen that will give live updates of the progress of the factory workers. I've been looking at SignalR for this, but I'm unsure about whether it'll let me send updates from a separate application (I.e WPF to the WebForms app). Is this possible? If so are there any examples of cross application SignalR use online?
Thanks!
There is a SignalR client which is part of the standard set of SignalR bits that lets you build signalr support straight into .net desktop apps.
See http://www.asp.net/signalr/overview/signalr-20/hubs-api/hubs-api-guide-net-client
You can use this in combination with JavaScript web-page clients without problem.
If both the WPF and WebForms apps connect to the same server then this is simple to implement.
Setup a SignalR Hub:
public class ProgressHub : Hub {
}
When loading the WebForms app load/show the current progress in an ordinary manner. Setup SignalR to get live updates to the progress:
var appHubProxy = $.connection.appHub;
appHubProxy.client.progress = function (orderId, percent) {
console.log(orderId + ': ' + percent);
};
$.connection.hub.start()
The WPF app calls the server to update the progress (using e.g WebAPI), in this handler call the signalr clients progress method:
public class ProgressController : ApiController {
public void Post(string orderId, int percent) {
// <Save progress to DB, etc>
// Get instance of the SignalR ProgressHub context
var hubContext = GlobalHost.ConnectionManager.GetHubContext<ProgressHub>();
// Invoke the progress method on all connected clients.
// You probably want to use Groups to only send customers
// events for its own orders
hubContext.Clients.All.progress(orderId, percent);
}
}
Or you could have WPF use the .NET SignalR API to call a method in the Hub instead:
public class ProgressHub : Hub {
public void Progress(string orderId, int percent) {
// <Save progress to DB, etc>
// Invoke the progress method on all connected clients.
// You probably want to use Groups to only send customers
// events for its own orders
Clients.All.progress(orderId, percent);
}
}