Self Hosting Comparison: WCF vs. HttpListener

I was exploring the use of ASP.NET Web API and SignalR in a self-serving application, and I noticed that the self-serving ASP.NET Web API implementation uses WCF, and the SignalR implementation itself uses System.Net.HttpListener . This makes it difficult to develop a combined solution for self-hosting, but I wonder why different project teams will use different approaches.

What are the advantages and disadvantages of each approach? Is there any special reason why SignalR cannot use WCF hosting itself, or the web API cannot use HttpListener?

EDIT . I understand that self-service web API provides a more complete stack than SignalR, my question is why you chose the WCF implementation compared to System.Net.HttpListener when implementing your own self-hosting solutions.

+4
source share
3 answers

That is why we are on the same page. The WCF host itself, which uses the web API host, uses the HttpListener under covers. However, I think I might have found a significant flaw for WCF self-service.

I have not confirmed this yet, but it seems that when using the Web API web host, the base address you provide is not translated directly into the HttpListener prefix. WCF seems to translate the base address and host wildcards.

This means that the WCF host itself will respond to any host on the specified port. This means that you cannot start a stand-alone web API service next to IIS on the same port using a different host name.

This may be the reason that SignalR decided to abandon WCF self-service and use the HTTPListener directly.

+3
source

The Web API host itself provides the entire HTTP stack, so it is much richer than System.Net.HttpListener.

SignalR uses this to cleanly open the communication window for its own purposes. So yes, now you have to run them in parallel on different ports.

In the future, with OWIN, you will have everything under one roof.


EDIT: actually there was a problem similar to yours raised in SignalR github and the answer was pretty much what I just said - https://github.com/SignalR/SignalR/issues/277

+6
source

Although you can use the WCF stack to host the services themselves, you may need to consider the "IIS 7.0 Hostable Web Core". It has the advantage of running IIS in your user process. Using this approach, you can have multiple applications running on the same port, regardless of technology.

If you are interested, you can see:

All of this assumes you are using Vista or later ...

+2
source

Source: https://habr.com/ru/post/1432182/


All Articles