We Keep Coding

Possible problems with Owin SignalR hosted in IIS 10 Express or IIS 10?

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.

Realtime updates between C# desktop app, mobile app and SQL server

Can anyone explain the best practice communication flow for a multi-app solution I am currently working on. I will have a MS SQL server database running. This database will be accessed and updated by one or more windows desktop applications and mobile devices(android, iOS and Windows). Whenever any changes are made to the database, the clients should be updated in real time to reflect. The desktop applications are most important and need to be updated with as little delay as possible. The mobile apps on the other hand can tolerate a delay of a minute or so.
My idea is connect the desktop application to the server using signalR, the database will then notify any connected clients of the update via SQLDependency. For the mobile side, I was planning for the server to send notifications to the mobile devices, where upon receipt of the notification, the mobile device would requery the SQL Server (via web service) to update itself.
I guess my question is, is this the best (standard) way to go about this or is there a better/quicker/more robust way to achieve this.
Any advice would be appreciated.

I would suggest you create an API in C# and host in on IIS. Your desktop app (be it web or native) will then use RESTful calls to the APIs.
The API's, hosted on IIS would communicate to SQL Server. For database operations, you would have CRUD (Create, Read, Update, Delete). You would expose a GUID (generated using NEWID() in sql server) to each CRUD method and supply serialized data. E.g. perhaps XML or JSON POSTed to the API.
In my view (and practice), this is the Best option. It is truly global, and the API's can "talk" to any client app capable of making HTTP requests.
So the system becomes:
SQL Server > API/IIS > Client (Android, iOS, JS, Java, Windows, Unix, Mac, etc)
Benefits here also are:
SSL out of the box
RESTful transactions - can use oAuth or write your own (proprietary is harder to hack!)
Highly scalable - IIS support 100's of transactions per second
Do not need to open port 1433 (SQL port) to web (which will open you to hacking). API uses port 443 (HTTPS)
If you write your API using C#, you have many serialze/deserialize functions out of the box.
Hope this answers your question.

.Net WebSockets in windows Services

I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth. Almost all the examples or information I have found are about using web sockets for Client/Server Side communication. I am having trouble figuring out how to set this up. I have considered using WebSocketHost as apart of Microsoft.ServiceModel.WebSockets, but then I am unsure how to bind it to a local port and not a URL.
Does any one have any suggestions
Thanks

I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth.
You can open sockets on both machines using WebSockets as you found. The examples mention clients and servers because this is the typical usage, however the API really doesn't care. As long as each side has a listener and a sender they can communicate.
However I would like to mention that this isn't as simple as it sounds because both machines aren't always available. Sometimes one or the other is busy or the network is blocked or something else is going on, or the listener is too busy to respond right away, so you're going to end up needing some sort of queuing on both sides.
If you're doing a process based operation where one side tells the other "I want X" and it's a big operation like producing a document, I've found it much more resilient to build a queue in a database and toss the request in there, then wait for the other side to update the record to say it's done.
If they're smaller, faster requests, MSMQ would be more appropriate if you have it available.
However back to your original question, if you want to use it, any of the client-server examples should work just fine. The API doesn't care.

You can use SignalR Self-Host you really don't want to create your own WebSockets framework since this this will take a long time.
Here is a link on how to start a OWIN server in Windows services.
Hosting WebAPI using OWIN in a windows service
And how to set signalR in self host
Tutorial: SignalR Self-Host

You can accomplish this with Memory Mapped Files.
Inter-Process Communication with Memory-Mapped Files

Instant Server-Client Communication, C#?

I have been doing research for a few months now on the possibility of client-server communication. I have experimented with many methods such as WebORB and FluorineFX, which are both servers designed to deal with client/server authentication.
WebORB only runs on Windows for their .NET version as far as I can tell, and I would much rather use an open source system. I have tried using FluorineFX, but I think their must be a simpler way for me to build my own simple system from the ground up.
I have been using Dropbox for a while now, and I like the way that the client-server communication is instant. As far as I can tell (from some Google searches) the client doesn't open a port of its own, and just communicates with the Dropbox server through port 80. An example of its instant communication is where you may delete a file on Dropbox on their website, and instantly the server communicates with the client telling it what has happened. I don't know how this instant communication is possible without opening a port.
I can create a system that uses fetching from the client, asking the server every 10 seconds or so to see if there are any updates, but I would like a method to be able to push the information from the server to the client.
My server runs Linux so I don't think I can use WCF, and ideally I am looking for a way to make PHP and C# communicate with each other.
I would love to hear any advice that anyone has and how they deal with the problem.
Cheers.

You CAN use WCF to communicate with any platform. Just make sure you're using an endpoint which your target machine support: http://msdn.microsoft.com/en-us/library/ms733107.aspx

Have you tried the good old .NET Remoting which runs perfectly with Mono?
You can choose between a TcpChannel (for performance) and a HttpChannel (to pass proxy/firewall easily).
For push notifications, you can open a connection to your server and wait for an answer indefinitely.

How are server side applications created, how is client - server communication done?

I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?

To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.

As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477

have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.

Another approach: use the Mod_AspDotNet module for Apache, as described here.

This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener