I just discovered, quite by accident, that a WCF service hosted in a Windows Service ill work with a HTTP binding. It seems to implement its own web server, but I have never seen this capability mentioned anywhere, and can't find any documentation on what the capabilities of the HTTP listener are (in terms of worker threads, etc.) Anyone have a pointer?
Thanks
if you google for self-hosting and WCF, you will come up with a wealth of information. The full power of WCF is available in this manner. The service can have accept multiple calls, and WCF can do the multithreading for you. You can also check out the WCF REST starter kit for more information.
Well, if it is going to support anything using the HTTP protocol, it would be definition have to be a web server.
The capabilities are that of the service host. Whatever you set for the throttles are going to be the capabilities of the server.
However, if you are going to have large loads on the service, you might want to consider hosting in IIS, as it offers more in the way of app recycling, fault tolerance, etc, etc.
Is System.ServiceModel.ServiceHost what you mean? The wcf configuration and ServiceBehavior allow you to set up concurrency settings, etc.
Related
What is the reason for two separate but similar servers?
What are the differences?
Can I run both in docker?
Do both support same things, like all authentication types?
Kestrel vs HTTP.sys - I've highlighted the fundamental differences below.
(The words are Microsoft's and I've only edited it for brevity and clarity. See the sources linked at the bottom).
Update:
Kestrel previously always required the use of a reverse proxy with edge deployments (exposed to traffic from the Internet) for security reasons. With Kestrel in ASP.Net Core 2.x this is no longer the case. Take a look at the documentation for more information. Kestrel Web Server Documentation
Weblistener was renamed HTTP.sys in ASP.NET Core 2.0
Sources:
Docs.Microsoft.com Web server implementations in ASP.NET Core
Docs.Microsoft.com HTTP.sys web server implementation in ASP.NET Core
HTTP.sys is windows-only HTTP / Web Server for ASP.NET Core that allows you to expose the server directly to the Internet without needing to use IIS. HTTP.sys is built on top of Http.Sys ( the same mature technology that also powers IIS' HTTP Listener) as is as such very feature rich and provides protection against various attacks.
Kestrel on the other hand, is a cross-platform web server for ASP.NET Core that is designed to be run behind a proxy (for example IIS or Nginx) and should not be deployed directly facing the Internet. Kestrel is relatively new and does not have a full complement of defenses against attacks. It's also not as feature rich as HTTP.sys and comes with timeout limits, size limits and concurrent user limits.
In essence, the choice comes down to your web application's Deployment scenario.
HTTP.sys Use Cases :
Kestrel Use Cases :
Following comparison will help you to choose which one is better
The ASP.NET 5 documentation (created by Microsoft on August 25, 2015) found here lists the chart found in the other answer (see page 107 of the bottom right book pages, but page 111 of the PDF): https://media.readthedocs.org/pdf/aspnet/theming/aspnet.pdf
Kestrel in general has better performance, if you used for one of the following below:
Great option if used in conjunction with a reverse proxy for apps exposed to Internet
Internal apps connecting with other internal apps on a private virtual network (not exposed to Internet)
WebListener is more secure, slower, and has more features. It is used in these cases:
Expose app to the Internet but can't use IIS
Require higher security and exposing server directly to Internet.
Additional features: List item, Windows Authentication, Port sharing, HTTPS with SNI, HTTP/2 over TLS (Windows 10), Direct file transmission, Response caching
We have binary WCF service (netTcpBinding) in a web-role and an asp.net website (to take advantage of SignalR over azure's backplane). Due to the extremely low budget, we want to host them both in a web-role (as website doesn't allow non-standard-HTTP(S) ports).
So is it feasible to host them both in a web-role, to keep the SignalR/web-interface capabilities but also use the binary WCF/netTcpBinding pattern?
Edit:
Maybe I should've asked in the first place "How to host both asp.net (for SignalR) and WCF (for netTcpBinding) in single web-role and wire them up to the hosting IIS?"
As long as socket binding does not conflict - I cannot see why that should not be possible.
See here:
What default port does WCF use for nettcp when hosted by IIS?
https://msdn.microsoft.com/en-us/library/ms731810(v=vs.110).aspx
I'm sure that was a confusing enough title.
I have a long running Windows service dealing with things happening in the world. This service is my canonical source of truth for the rest of my system. Now I want to slap a web interface onto this so the clients can see what is actually going on. At first this would simply be a MVC5 application with some Web API stuff. Then I plan to use SignalR 2.0 and Ember.js to make this application more interactive and "realtime".
The client communicates with the Windows Service over named pipes using WCF. A client (such as a web app) could request an instance of for example IEventService, would be given a WCF proxy client, and could read about events through this interface. Simple enough.
However, a web application basically just exists in the sense that it responds to requests from the user. The way I understand it, this is not the optimal environment for a long lived WCF client proxy to raise events in, and thus I wonder how to host my SignalR stuff. Keep in mind that a user would log in to the MVC5 site, but through the magic of SignalR, they will keep interacting with the service without necessarily making further requests to the website.
The way I see it, there are two options:
1) Host SignalR stuff as part of the web app. Find a way to keep it "long-running" while it has active clients, so that it can react to events on the WCF client proxy by passing information out to the connected web users.
2) Host SignalR stuff as part of my Windows service. This is already long-running, but I know nada about OWIN and what this would mean for my project. Also the SignalR client will have to connect to a different port than where the web app was served from, I assume.
Any advice on which is the right direction to go in? Keep in mind that in extreme cases, a web user would log in when they get to work in the morning, and only have signalr traffic going back and forth (i.e. no web requests) for a full work day, before logging out. I need them to keep up with realtime events all that time.
Any takers? :)
The benefit of self-hosting as part of your Windows service is that you can integrate the calls to clients directly with your existing code and events. If you host the SignalR server separately, you'd have another layer of communication between your service and the SignalR server.
If you've already decided on using WCF named pipes for that, then it probably won't make a difference whether you self-host or host in IIS (as long as it's on the same machine). The SignalR server itself is always "long-running" in the sense that as long as a client is connected, it will receive updates. It doesn't require manual requests from the user.
In any case, you'll probably need a web server to serve the HTML, scripts and images.
Having clients connected for a day shouldn't be a problem either way, as far as I can see.
I am trying to host a WCF service on a windows service.Basically WCF service reads the data from the back end database on the same machine.Now from the ASP.NET server on the same machine,I want to read the data that WCF service has read from Database.Can anyone suggest me the right approach to do this?? And also the binding that has to be used for the same.
It appears from your comments that your goal is to have different UI served by same WCF back-end. Here are few info with regard to binding:
For accessing WCF service on the same machine, the best binding would be named pipe binding. However, named pipe binding will not be accessible from other machines.
In case, you have to access the service from other machines, you should go for TCP Binding. Note that both named pipe and TCP bindings would be consumed from .NET client only (which should not be an issue for you).
Lastly, if you have to expose services over internet and/or they need to be interoperable, BasicHttpBinding or WSHttpBinding can be your choices. However, I would have different service interfaces for internal/private consumption and external/public consumption.
Finally, you can easily change the bindings via configuration, so you can select name pipe to start with and may change it to tcp binding in future. Further, its possible to have same service exposed on different end-points with different bindings.
Now, as far hosting WCF goes, you can host it in windows service or IIS. Advantage with IIS is that you have tested, scalable host that offer a quite few management options with UI. On flip side, with IIS (as web server), you cannot use named pipe or tcp binding. With newer windows server, you can even eliminate that dis-advantage with the help of WAS (Windows Activation Services).
Finally, have you considered using common in-process layer instead of out-of-process layer such as WCF? For example, you can have a common library (or set of libraries) that can provide business logic/data access with clear API. The same library can be used in different UI such as ASP.NET and window forms - the UI must use the interface and factories (or DI framework) for accessing the layer. Advantage is that you get performance gain due to in-process call. On flip side, the desktop client using in-process layer cannot be scaled easily or cannot be used over internet. WCF based application server solves these issue. I prefer creating in-process layer that will be used by server based UI such as ASP.NET while client based UI using WCF facade over the same in-process layer.
Using a WCF just to keep the code separate in case you wish or need to go for another UI is not very logical. What you could do is actually writing all the logic in a separate assembly. This you will eventually do when you implement it in WCF. WCF is just a hosting framework and will host the underlying assembly in an out-process host. If you have a single consumer of the service, and you wish to host it in the same machine (as in the post), it could have been used in-process. Your code-behind code can refer to the data access classes in the separate assembly. The same thing you do when you access the WCF service through the proxy.
From what I understand what you're trying to do would be something like this:
ASP.Net App --> WCF Service --> DB
The app calls a method on the WCF Service, which reads some data from DB and creates a report and send it back to the app. If this is the intent and both app and service are on the same machine then you can use named pipe binding which is pretty fast and is the preferred way of communication for systems on the same machine. You can also use the http binding which is more scalable. But the great advantage of WCF framework is that you can easily change bindings without affecting the functionality. So, I'd suggest you go with named pipes (net.pipe://) and later switch to Http, if required.
I have a nettcp service which I have to host. I have three options -
IIS 7
Windows Service
A console application
I would be grateful if anybody could give some valuable thoughts on which option is better vis-a-vis other one.
Here are some of my observations:
IIS 7:
Pros:
Ready made hosting environment inside IIS
Will work with pretty much any hosting environment
Cons:
HTTP Only
Configuration slightly more complex
WAS:
Pros:
Ready made and familiar process model to that of IIS
No dependency on IIS
All protocols supported
Cons:
Not all shared hosting environments will support non-http protocol bindings or unusual port numbers.
Configuration slightly more complex
Windows Service:
Pros:
Starts when windows starts
You can start/stop the service via the service control manager
All protocols supported
Cons:
Some extra steps to deploy/re-deploy (installutil)
You need some extra boilerplate code to support the service implementation
Not ideal if you can't have access to the server to install (e.g. shared hosting)
Console Application:
Pros:
Fast and simple to deploy for testing purposes
All protocols supported
Cons:
You need to be logged on to start the process
Loss of session or machine shutdown will kill the service
Console/RDP access required