1

this is my first questions on SO. Normaly I just wander the internet reading stuff until I can make up a solution.

So up until now we use HTTP Request and Response Model to communicate with Clients. Using C# ASP.Net .Net Framework 4.0 hosted in IIS. This way we are not able to forward information in real time to them from the server. We would need to wait till the clients contact the server.

To solve this issue I think OWIN with SignalR V2 Middleware hosted in IIS would give us the ability to use Remote Procedure Calls, so whenever something happens that needs to be forwarded immediately to the Client, we can do so by calling that specific clients function or all clients. For this of course the target Framework of the application needs to be .Net Framework 4.5 at least.

Now the problem I have is that in the Microsoft Documentation it says to use the IIS Express version, in order to enable the server to have more than 10 connections. On the client side it would be no problem as ideally there would only be one connection at any given time. But the Server should be able to have a whole lot more than just 10. As the Websocketconnections would stay open. I am not an IIS expert, but why are there these limitations in the non Express version? I would expect that one should be able to set the number of maximum connections despite the IIS version? What are the gains of using IIS instead of self-hosting OWIN? I would guess that I would need to implement some security features myself?

On my development PC a client Windows Service with SignalR V2 is able to communicate with an OWIN SignalR V2 hosted in IIS application. At the moment I need to evaluate what needs to be considered to set this up on a server to ensure functionality.

I hope this all makes sense.

I am implementing Remote Procedure Calls in our Webservice, for real time communication with clients. I read documentations about RPC, SignalR V2, OWIN and Katana. At the moment I need to evaluate what needs to be considered to set this up on a server to ensure functionality.

Maddin
  • 11
  • 2
  • 1
    I really wonder what you have read so far, as your description above contains too much misinformation. 1) Staying on .NET Framework is unnecessary. SignalR on .NET 6 is what you should go. 2) The 10 connection limit is for Windows client OS, so to get rid of that you need to use Windows Server. That has nothing to do with IIS or IIS Express. 3) You keep talking about Remote Procedure Calls, but my experience is that people rarely use this term with SignalR. You should post some code to show what exactly you are talking about. – Lex Li Mar 24 '22 at 13:35
  • @Lex Li Thank you for your answer. About 1) Yes, it is true that migration to .NET 6 or higher will be necessary in the future, but as .Net Framework will still be supported until EOL Windows Server 2022, it is not imminent. About 2) Thank you that information helps alot. It was not descriped clearly here: [link](https://learn.microsoft.com/en-gb/aspnet/signalr/overview/getting-started/supported-platforms#supported-server-iis-versions) – Maddin Mar 24 '22 at 14:02
  • About 3) From my understanding SignalR V2 enables you to call functions on the client site, when they are implemented in the Proxy Hub. Mostly SignalR is used for Browser Application, but it is also possible to use it in a client side Windows Service. I am still planing this project so there is not code to show yet. The goal is to have the functionality on the Server to forward information to the clients in real time. For example a customer changes something in a management tool and this information needs to be sent to all managed clients. Waiting for client heartbeat takes to long. – Maddin Mar 24 '22 at 14:05
  • "Still supported" only gives you security patches if you read carefully the product lifecycle documentation from Microsoft. So staying on .NET Framework deprives yourself from all new features/performance improvements in .NET 6. Also the .NET Framework version of SignalR has well known issues if you dig further, but they won't be fixed there. I suggest you make your hands wet and try out SignalR with simple examples. That will give you more to think about than reading various materials. – Lex Li Mar 24 '22 at 23:32
  • I honestly don't understand why you are using these dated technologies. You can run SignalR Core on AspNetCore on either netframework, netcore or net5/6. Owin is completely deprecated, and replaced with AspNetCore. You could also try running gRPC (web over websocket). – Aron Mar 26 '22 at 03:31
  • @Aron Thank you for your answer. According to [this SO question](https://stackoverflow.com/questions/58269392/using-signalr-core-on-net-4-6-1). It seems to be adding more compexity to the project. As .Net Core dependencies will be necessary to be added to the project. It would be great if SignalR core could be used with .NetFramework for later migrations to newer versions, but not like this. – Maddin Mar 28 '22 at 07:33
  • I think, I need to explain, that we have a running version of our software in the field that runs on .Net Framework 3.5. I took this project over a year ago or so and with the ncessity of real time communication I got the permission for migration to .Net Framework 4.8 and soon 4.8.1. There are alot of projects in our pipeline to keep me buisy for the next 4 years. I personally would prefer it to upgrade to latest technology, but I can only do so much in the time I have. So I guess, the reason for staying with older technology are company politics. – Maddin Mar 28 '22 at 07:39
  • The limitations are in the windows client OS. It's been that way forever. Use windows server if you need more concurrent connections. – davidfowl Apr 11 '22 at 06:51

0 Answers0