Architecture question

[johnrscott]

We have developed a system, written in c#: There are physical electronic controllers that have ethernet adapters. They communicate to the socket server over UDP which is writtren in c# (.net 4.8) as a dll with a winforms application on the front. There is a web based front end written in CoreASP .net MVC.

I need to have real time information on the website from the socket server. The website users also need to issue commands and alter settings on the devices, and have instantaneous (or thereabouts) feedback.

Also when a notifiable event happens on a controller, it issues a signal to the socket server which has to be relayed to the website in real time to update a dashboard.

I initially configured a SignalR client on the socket server and used it to relay messages to the website but found it really unreliable and troublesome to manage.

The current setup has the socket server attached to the website as a DLL, but I am unsure if this is wise because I don't know exactly what IIS will do to the web application when there are no page requests or when it recycles the app pool.

EDIT*** I forgot to mention that both socket server and web server will exist on the same internal network, but not necessarily on the same machine. (Currently not possible to put it on separate machines) This will never be an internet facing solution.

Can anyone recommend a robust way to fit these pieces together?

 

[Skydiver]

Still trying to understand what you are trying to do, but a few random thoughts:

- IIS can be configured to keep the app pool running instead of it's default behavior of recycling every 29 hours, and stopping the app pool when there are no requests for 20 minutes.

- web based and realtime are kind of incompatible unless you are running on a closed network where you have full control of the network traffic and have set everything up for speed and reliability. Recall that with TCP/IP out on the general Internet packets can be sent halfway around the world even if the destination is just next door.

Edit after: I should have refreshed my browser. I see that you've addressed a major part of the networking concern I had.

 

[Skydiver]

As for that architecture, are you required to have that WinForms based app? Why can't it be a Windows Service running on the same IIS box?

 

[johnrscott]

Hi. Thanks for answering.

To cover your first question. Imagine a hospital or prison. Our controllers look after the water and electricity. We can remotely activate taps flushes and switches. We can remotely control lights and we measure usage and activations of taps and flushes and showers etc. We can also lock out any of the above and perform routine scheduled functions.

The person looking after the ward needs to see what's happening all the time and be able to react. The switches need near instant feedback. I have developed little toggle buttons that change state when the feedback comes in. The client is adamant that the state of the controls on the web form is a real reflection of the controller state.

The network will be closed with a VPN for remote access only.

I am aware that iis can be configured to stay alive but is it healthy for it? What are the long term effects? I would hate to roll out a 500 room network only to have the entire thing crash after a time because of iis.

The socket server winforms front end is really just a debugging tool. I do eventually plan to have it run as a service, however because it requires file access so I need to research the security aspect more before I do that. Right now it's attached as a DLL to the web app so I can't see the winforms portion anyway.

The essence of my question is what would be the best way to communicate between socket server and web app.

 

[Skydiver]

I am aware that iis can be configured to stay alive but is it healthy for it? What are the long term effects? I would hate to roll out a 500 room network only to have the entire thing crash after a time because of iis.

In my experience, IIS itself is stable. It's the apps running within IIS that are the problem. If they have a memory leak, or worse a Windows handle leak, then a long running app pool can be a major headache.

 

[Skydiver]

The socket server winforms front end is really just a debugging tool. I do eventually plan to have it run as a service, however because it requires file access so I need to research the security aspect more before I do that. Right now it's attached as a DLL to the web app so I can't see the winforms portion anyway.

I must have misread the first post. The impression I got was that devices sent data to a WinForms app that was hosting the socket server, and then the WinForms app relayed the data over to the web front end.

Now, it's a bit clearer that the socket server code actually lives in a DLL, and all you really need is some executable to host that DLL, be it an IIS app pool, a Windows Service, or a WinForms app.

 

[Skydiver]

Also cross-posted over at DreamInCode...

 

[johnrscott]

In my experience, IIS itself is stable. It's the apps running within IIS that are the problem. If they have a memory leak, or worse a Windows handle leak, then a long running app pool can be a major headache.

Thank you. I do have some decent profiling tools so I can monitor the app over a period and see how it behaves.

 

[Skydiver]

Speaking of the devil... Just found an app pool eating up 6.2GB out of 8GB and 70% of the CPU of an 8 proc machine. I sent the app owner a nasty gram. The nasty gram would have included a memory dump so that they can debug their app, but the machine was so sluggish, I could barely do anything on it.