c# event/time driven long polling

[¨TrisT¨]

Hey.

So the idea is to listen to http requests on 2 ports. The 1st one receives from the main server, in which submitting a form or an ajax request makes it so it sends a request to the c# server with x client and z info, which makes something tell whatever is dealing with the requests of x client "however many polles you've got going on for that x's devices, send them all back with z info". The second one is, rather obviously, the one that is receiving requests, which leads to the polling of said requests.

After some time of inactivity, the polling will end with a "call me", and the client will request again, repeating the whole process or if not the server will know that device is offline.

Client side is simple enough: long timeout, request every time it's poll ends.

The whole idea here is to have the c# server manage the "requests" the main server needs to send to the clients, to keep everything real time. The point is to have a completely standalone app, fully configured through the web interface, instantly updating. A "refresh button" isn't enough for me ;D

Now I've read a bit on this and about asynchronous requests, along with threading, etc.

What I'm looking for here is logic regarding the c# server. I don't really know what dynamic to go for regarding threading/async requests, I have complete no idea on how to tell a specific request to be sent back with z info(or even to have multiple running), and even more no-idea on how I could "group" those with each client.

Sorry for any bad spelling.

Thank you for your time ;D

[Toxicable]

Ok so I am very confused on what you're trying to accomplish with this. From what I can tell you have little experience working with asp.net, I would advise working with some simple asp.net MVC applications to start off with or maybe Web Api depending on what you like. After you understand some more on how to work with asp.net web servers then I'd advise looking into HttpClient for making requests in C#, that's under the System.Net.Http namespace, aswell as the Signal R NuGet package to deal with real time communication, which is actual real time not polling. Which brings me to my next point, polling is not real time, generally polling is a rather bad way to handling communication events are much better way of doing  things.

[DevBlox]

Option 1: With this logic your devices are actually acting as servers and you will send http requests to them with your app, the response will contain z data that contains their current status etc, anything else is over-engineering and not necessary. That's simple enough to achieve, your devices will have to listen on a port and handle these requests, this part will be operational indefinitely no matter is the app is there or not, think of it as in stand by mode. The app will then make http requests to these endpoints and retrieve z data, it could just act on a time delay and you will achieve what you want. The downside of this is that you will need to have your devices written down in the app's config, it will have to change every time a new device is added or an old one is gone, this means more things to change if anything like that happens, minor thing if there won't be more than 10-20 of them. Your explained idea will suffer from this as well as will be terribly over-complicated.

 

Option 2: If you will have lots and lots of these devices, you could have a master server, to which every device will "call home" to, these requests could be POST's and contain z data, or they could just ask the master for commands. Note that your app will not be able to be a master, because the master always has to be reachable and available, meaning a static ip or at least a domain that will stay constant, your app will be a client of the master and will request it for data. The master will have all the logic in the world that you will want, this means the logic you have to code for the master will be the most complicated thing in the system, it will have to listen on a port and handle these requests while providing data to the app via another port and everything in between, the devices just periodically request the master for things or just push their data to it. The upside is that every new device have a single ip or dns to call home to on deployment, meaning deploying new ones is a piece of cake, it's a more scalable system overall, but the master has to handle their disappearances and similar things in it's logic, it should not have the config with all of them listed, it's counter productive to this architecture.

 

That's two ways how I would do it, the multithreading part will all be in the master code, it will be challenge to create i reckon

[¨TrisT¨]

2 hours ago, DevBlox said:

Option 1: With this logic your devices are actually acting as servers and you will send http requests to them with your app, the response will contain z data that contains their current status etc, anything else is over-engineering and not necessary. That's simple enough to achieve, your devices will have to listen on a port and handle these requests, this part will be operational indefinitely no matter is the app is there or not, think of it as in stand by mode. The app will then make http requests to these endpoints and retrieve z data, it could just act on a time delay and you will achieve what you want. The downside of this is that you will need to have your devices written down in the app's config, it will have to change every time a new device is added or an old one is gone, this means more things to change if anything like that happens, minor thing if there won't be more than 10-20 of them. Your explained idea will suffer from this as well as will be terribly over-complicated.

 

Option 2: If you will have lots and lots of these devices, you could have a master server, to which every device will "call home" to, these requests could be POST's and contain z data, or they could just ask the master for commands. Note that your app will not be able to be a master, because the master always has to be reachable and available, meaning a static ip or at least a domain that will stay constant, your app will be a client of the master and will request it for data. The master will have all the logic in the world that you will want, this means the logic you have to code for the master will be the most complicated thing in the system, it will have to listen on a port and handle these requests while providing data to the app via another port and everything in between, the devices just periodically request the master for things or just push their data to it. The upside is that every new device have a single ip or dns to call home to on deployment, meaning deploying new ones is a piece of cake, it's a more scalable system overall, but the master has to handle their disappearances and similar things in it's logic, it should not have the config with all of them listed, it's counter productive to this architecture.

 

That's two ways how I would do it, the multithreading part will all be in the master code, it will be challenge to create i reckon

Thanks!

Though the problem I find with the first option is that the app will still have to tell a main server it's ip in order to be communicated to, given it is listening. Also, and this is a noobish question, since I never really understood this, how can you communicate with that app in some port if it's not port forwarded? And how would it work if more than one device was in a network? You'd need more than one port, and then it would be a whole other pain in the butt to know which port to communicate to.

 

The second option's disadvantage is pretty much the load on the master, because if I want to keep it at least looking instantaneous, I'd have to be pulling a lot of requests all the time. And since the info regarding the app's configs is written to a json file, I don't really see that being optimal.

 

I chose the long poll in the first place because it's really easy to keep a hanging, and therefore empty connection active, with barely any costs if putting both async logic and multi-threading on the task, you will always know the IP on the app, everything will be instantaneous, and the app will never even have to listen to anything what so ever.

 

Though I am rather curious about the "app listening to requests thing" as it was pretty much my 1st idea, I just seem to be missing how listening and port stuff actually fully works, as I've always thought you needed port forwarding to be able to listen to anything. It would also be a problem because it would require an installer, as windows doesn't allow c# to listen to anything besides localhost without admin and firewall permission.

 

Once again thank you for your reply

[¨TrisT¨]

3 hours ago, Toxicable said:

Ok so I am very confused on what you're trying to accomplish with this. From what I can tell you have little experience working with asp.net, I would advise working with some simple asp.net MVC applications to start off with or maybe Web Api depending on what you like. After you understand some more on how to work with asp.net web servers then I'd advise looking into HttpClient for making requests in C#, that's under the System.Net.Http namespace, aswell as the Signal R NuGet package to deal with real time communication, which is actual real time not polling. Which brings me to my next point, polling is not real time, generally polling is a rather bad way to handling communication events are much better way of doing  things.

: O

I've worked with httpclient, I actually have the whole thing setup already, but I have to click a button to refresh info(that comes json formatted, so json.decode is the only thing I've used from MVC so far) and I don't really want to have a from-time-to-time auto refresh, though I've in fact never really heard of Web Api or SignalR. And never really got into MVC except when research pointed to it (which is amazing given it was probably exactly what I actually needed). It does seem really nice from the little I've read so far though : )

 

Thanks a whole lot man!! :D. 

 

Also, and this is just me being a stubborn duckhead, but how can polling not be real real time? You do get something back when something else triggers it :P.

[DevBlox]

Oh dang, I see what are you trying to do now. Don't make your clients have port forwarding, not only this is a potential security hole and weakness, this is bad design of the system. For every new user, ALL of your devices will experience a load increase, every one of them. Eventually you will have nowhere to scale out, and you will have to either upgrade all of your devices or kill the project completely, not nice. You need to reduce impact here. Whatever you do, you need a server, like I described in option 2, whether you choose if the devices should report the data themselves or listen does not matter at this point, it's whatever you decide, I'll describe that situation later. You need to have the server to handle all of the users, that is, listening on their requests, not the other way around. Even more so, because you can't force users update their configs every time you add a device, or have your devices update their configs every time a new user pops up, that's just plain dumb design (don't take it personally, we've all done bad design :D). Users have to have a single domain name(!) only, that's the master server that will service them.

 

Use domain names at this point, if your servers should change location or something and you cannot use the same ip, don't force the user to update anything. You get the idea I hope. The code the user runs must be as immovable as possible.

33 minutes ago, ¨TrisT¨ said:

Also, and this is a noobish question, since I never really understood this, how can you communicate with that app in some port if it's not port forwarded? And how would it work if more than one device was in a network? You'd need more than one port, and then it would be a whole other pain in the butt to know which port to communicate to.

Okay, so I see you know how networking works to some extent. So I will just clarify for you and explain for you or anyone else who might read. You understand already that port forwarding needs to happen someplace if your servers or devices are behind routers. You only need to port forward the services and programs that are acting as servers, that are actually listening on ports. Forget about the client needing a port, at least in the HTTP protocol case. That is because the client, that connects to the server, is sending the request, and it needs to know where it should land. In the case of your home, if a request lands from the outside (the WAN wire), it hits your router, which acts like a firewall for everything in your local network, so everything there is invisible from the outside basically. You do port forwarding on your routers port to a port on a specific computer or server inside the network, so that when a request from the outside hits the router on that port, it gets put through to the server behind it, so it can respond to it. This does not need to happen for the end that makes the request. Imagine needing to port forward in every new network you enter with your laptop just to browse the internet. Ew!

 

That's why option 1 has a terrible limitation if any of your devices will not be in your local network, You need to port forward everything, and even that in some cases is not guaranteed to work, that's a real pain in the ass. Option 2, on the other hand, only requires the server to be port forwarded if needed, so the devices can be anywhere where there is internet connection and they will happily send requests t your server and receive it's responses.

 

Don't even worry about being on the same network with a bunch of devices and servers, everything has a local ip address, even your phone when you connect to WiFi. Also since everything is there, you just connect to the local ip address that you want to. That's why hosting, let's say, Minecraft for a lan party is a piece of cake, you just connect to the host's local ip. So your devices being in the same network as the main server can just send requests to it's local ip.

 

About the deciding which port is which, you just about need to listen on and know about one. The one that is on your main server. All the devices will communicate with that one. If you really need to differentiate, get a second one. Then it's one port for the devices, and the other one for the app. If your concerns are that you need a port for a single device, i have an example. Imagine Facebook handling all of those requests from all of those people. A computer only has 65536 ports, but millions of people are connecting to just one, that's port 80 (imagine Facebook has only one server for this example's sake).

 

If you don't get what am I saying, you really need to set up and experiment with how networking works, and read some wikipedia articles, whole books are a bit overkill for the short term.

 

1 hour ago, ¨TrisT¨ said:

The second option's disadvantage is pretty much the load on the master, because if I want to keep it at least looking instantaneous, I'd have to be pulling a lot of requests all the time. And since the info regarding the app's configs is written to a json file, I don't really see that being optimal.

 

Your main server (or app) will still bear all the load with option 1, it will do all the work with data reported anyway and it will keep a whole bunch of connections open, this is more of a decision to be made according to other limitations and the concept itself of who is the server and who is the client :).

 

Don't even worry about the load going with option 2, a well written server program on a simple laptop can carry many many thousands of requests per second, in a few milliseconds even. I once written one that handled 7k and it did multiple lookups in a few data structures. I got to test my own Java server application on Raspberry Pi Model B some time ago, turns out it can handle a few hundred a second, on a freaking ARMv6 chip! take

 

Of course, you did not mention about what data amounts we're talking about and what the devices will be reporting, so I imagine not a whole lot of data is involved, if the reporting frequency is this high. 10's of kilobytes for a single frequent request is not even that much. if the devices have to report them even 10 times a second (even though in most cases that's a bit useless, 1 second is gold for real time reporting), you'll be fine.

 

The app could query the server once a second too, so the worst worst case delay for such a system is 2 seconds, not a whole lot, I bet you will never reach that big of a delay. Keep in mind that requests last mere milliseconds. I bet you could still achieve this 2 second worst case with devices and the main server being on different continents!

 

----------------

So there we go, my take on the current situation. Draw some flowchats and graphs while making birth to this thing :). As for what to use, I achieved my numbers with HttpListener, but I have heard SignalR is great, you will have to make your own investigation :).

[¨TrisT¨]

58 minutes ago, DevBlox said:

Oh dang, I see what are you trying to do now. Don't make your clients have port forwarding, not only this is a potential security hole and weakness, this is bad design of the system. For every new user, ALL of your devices will experience a load increase, every one of them. Eventually you will have nowhere to scale out, and you will have to either upgrade all of your devices or kill the project completely, not nice. You need to reduce impact here. Whatever you do, you need a server, like I described in option 2, whether you choose if the devices should report the data themselves or listen does not matter at this point, it's whatever you decide, I'll describe that situation later. You need to have the server to handle all of the users, that is, listening on their requests, not the other way around. Even more so, because you can't force users update their configs every time you add a device, or have your devices update their configs every time a new user pops up, that's just plain dumb design (don't take it personally, we've all done bad design :D). Users have to have a single domain name(!) only, that's the master server that will service them.

 

Use domain names at this point, if your servers should change location or something and you cannot use the same ip, don't force the user to update anything. You get the idea I hope. The code the user runs must be as immovable as possible.

Okay, so I see you know how networking works to some extent. So I will just clarify for you and explain for you or anyone else who might read. You understand already that port forwarding needs to happen someplace if your servers or devices are behind routers. You only need to port forward the services and programs that are acting as servers, that are actually listening on ports. Forget about the client needing a port, at least in the HTTP protocol case. That is because the client, that connects to the server, is sending the request, and it needs to know where it should land. In the case of your home, if a request lands from the outside (the WAN wire), it hits your router, which acts like a firewall for everything in your local network, so everything there is invisible from the outside basically. You do port forwarding on your routers port to a port on a specific computer or server inside the network, so that when a request from the outside hits the router on that port, it gets put through to the server behind it, so it can respond to it. This does not need to happen for the end that makes the request. Imagine needing to port forward in every new network you enter with your laptop just to browse the internet. Ew!

 

That's why option 1 has a terrible limitation if any of your devices will not be in your local network, You need to port forward everything, and even that in some cases is not guaranteed to work, that's a real pain in the ass. Option 2, on the other hand, only requires the server to be port forwarded if needed, so the devices can be anywhere where there is internet connection and they will happily send requests t your server and receive it's responses.

 

Don't even worry about being on the same network with a bunch of devices and servers, everything has a local ip address, even your phone when you connect to WiFi. Also since everything is there, you just connect to the local ip address that you want to. That's why hosting, let's say, Minecraft for a lan party is a piece of cake, you just connect to the host's local ip. So your devices being in the same network as the main server can just send requests to it's local ip.

 

About the deciding which port is which, you just about need to listen on and know about one. The one that is on your main server. All the devices will communicate with that one. If you really need to differentiate, get a second one. Then it's one port for the devices, and the other one for the app. If your concerns are that you need a port for a single device, i have an example. Imagine Facebook handling all of those requests from all of those people. A computer only has 65536 ports, but millions of people are connecting to just one, that's port 80 (imagine Facebook has only one server for this example's sake).

 

If you don't get what am I saying, you really need to set up and experiment with how networking works, and read some wikipedia articles, whole books are a bit overkill for the short term.

 

 

Your main server (or app) will still bear all the load with option 1, it will do all the work with data reported anyway and it will keep a whole bunch of connections open, this is more of a decision to be made according to other limitations and the concept itself of who is the server and who is the client :).

 

Don't even worry about the load going with option 2, a well written server program on a simple laptop can carry many many thousands of requests per second, in a few milliseconds even. I once written one that handled 7k and it did multiple lookups in a few data structures. I got to test my own Java server application on Raspberry Pi Model B some time ago, turns out it can handle a few hundred a second, on a freaking ARMv6 chip! take

 

Of course, you did not mention about what data amounts we're talking about and what the devices will be reporting, so I imagine not a whole lot of data is involved, if the reporting frequency is this high. 10's of kilobytes for a single frequent request is not even that much. if the devices have to report them even 10 times a second (even though in most cases that's a bit useless, 1 second is gold for real time reporting), you'll be fine.

 

The app could query the server once a second too, so the worst worst case delay for such a system is 2 seconds, not a whole lot, I bet you will never reach that big of a delay. Keep in mind that requests last mere milliseconds. I bet you could still achieve this 2 second worst case with devices and the main server being on different continents!

 

----------------

So there we go, my take on the current situation. Draw some flowchats and graphs while making birth to this thing :). As for what to use, I achieved my numbers with HttpListener, but I have heard SignalR is great, you will have to make your own investigation :).

:D. You see, I understand all the concepts you talked about very well.

Though I want to eliminate all bottlenecks possible. And my internet speed in this case is quite the bottleneck. That's why a whole lot of requests coming in is really not ideal. As we both said, port forwarding client side is unbearable.

Long polling is a technique that keeps a request "waiting", so for example. You set the timeout on the httpclient for say 90 seconds, and send a request to the server. The server will not respond, but will have the ability to (with some sort of context object for each connection saved in a thread or something that is waiting,  ), it just awaits until an event is fired. That makes it so an empty connection that takes no resources to keep up.

Now say a user goes on the web interface and submits a form, therefore choosing a different color for a button on the app. The page the form was sent to sends a request to localhost (with the info about the changes), on the port the c# server is listening to for server info(that is not forwarded, so people can't pretend to be the server ever). The c# server then has a request on hold, that is coming from a certain device of that user. That request is finally responded to, and there goes the info regarding changes made, something really small, like "Button001Changed". The client's app, that was waiting for it's request to come back, then gets it and "wonders": "well, server just told me "Button001Changed", better check out what that was about": And then proceeds to querying the server, the actual server, not the c# one about said button. The server returns the button style, and the app sets button001's style to the one queried from the server, this all happens like a perfectly normal request. The app is now idle because it completed a task based on what the server effectively told it from the request it had been waiting for, if I'm being clear enough. At this point, as the app can't listen, it can never be directly told something happened. So, and then again, it sends a request to the c# server effectively asking if anything happened. Two things can happen: The user submits another form and the c# is told again by the main server to send back the request with the info that was changed and everything happens again; Or: 60 idle seconds for that connection, which means nothing happened on the server regarding that user, pass on the c# server, and in order for the connection not to exceed the 90 seconds timeout the app has set, it sends back the response to the app's request saying "request me back, nothing happened, this is boring". The app then requests back and waits another 60 secs(or less if something happens on the main server) for a response.

The c# server does not have the ability to know if that connection was broken, but will know the device is offline if when those 60 seconds end, it responds to the app and it doesn't get another request from the it.

 

Now toxicable has told me this is a bad way to go about it, and that there are actual ways of making real real time connections. I wouldn't be surprised given streaming and other "technologies" are out there. I'll have to take a good look into that. But I've made quite some drawings and this is the way with the least "wires" and the smallest circles I could find myself.

 

Once again thank you, I'm pretty sure the whole networking explanation wasn't too helpful for me but it might just be for people who need it. Maybe make a blog with it, could turn out very well for you :D. 

[DevBlox]

3 hours ago, ¨TrisT¨ said:

:D. You see, I understand all the concepts you talked about very well.

Though I want to eliminate all bottlenecks possible. And my internet speed in this case is quite the bottleneck. That's why a whole lot of requests coming in is really not ideal. As we both said, port forwarding client side is unbearable.

Long polling is a technique that keeps a request "waiting", so for example. You set the timeout on the httpclient for say 90 seconds, and send a request to the server. The server will not respond, but will have the ability to (with some sort of context object for each connection saved in a thread or something that is waiting,  ), it just awaits until an event is fired. That makes it so an empty connection that takes no resources to keep up.

Now say a user goes on the web interface and submits a form, therefore choosing a different color for a button on the app. The page the form was sent to sends a request to localhost (with the info about the changes), on the port the c# server is listening to for server info(that is not forwarded, so people can't pretend to be the server ever). The c# server then has a request on hold, that is coming from a certain device of that user. That request is finally responded to, and there goes the info regarding changes made, something really small, like "Button001Changed". The client's app, that was waiting for it's request to come back, then gets it and "wonders": "well, server just told me "Button001Changed", better check out what that was about": And then proceeds to querying the server, the actual server, not the c# one about said button. The server returns the button style, and the app sets button001's style to the one queried from the server, this all happens like a perfectly normal request. The app is now idle because it completed a task based on what the server effectively told it from the request it had been waiting for, if I'm being clear enough. At this point, as the app can't listen, it can never be directly told something happened. So, and then again, it sends a request to the c# server effectively asking if anything happened. Two things can happen: The user submits another form and the c# is told again by the main server to send back the request with the info that was changed and everything happens again; Or: 60 idle seconds for that connection, which means nothing happened on the server regarding that user, pass on the c# server, and in order for the connection not to exceed the 90 seconds timeout the app has set, it sends back the response to the app's request saying "request me back, nothing happened, this is boring". The app then requests back and waits another 60 secs(or less if something happens on the main server) for a response.

The c# server does not have the ability to know if that connection was broken, but will know the device is offline if when those 60 seconds end, it responds to the app and it doesn't get another request from the it.

 

Now toxicable has told me this is a bad way to go about it, and that there are actual ways of making real real time connections. I wouldn't be surprised given streaming and other "technologies" are out there. I'll have to take a good look into that. But I've made quite some drawings and this is the way with the least "wires" and the smallest circles I could find myself.

 

Once again thank you, I'm pretty sure the whole networking explanation wasn't too helpful for me but it might just be for people who need it. Maybe make a blog with it, could turn out very well for you :D. 

Oh I see, I imagined your system to do quite a different kind of role, wasn't quite on the same page, so I questioned this design. I imagined it to be more like a decentralized monitoring system that you are trying to achieve, but this is more like an event system. This also started looking like how Android or IOS achieve their real time push notifications, if that's something what you're looking for, looking up how it's implemented might actually answer some questions for you .

 

Thanks for the kind words, I might actually write a blog sometime, need to get a habit of documenting anything new I try . Good luck with the system, seems really interesting how it will turn out!

[Toxicable]

14 hours ago, ¨TrisT¨ said:

: O

I've worked with httpclient, I actually have the whole thing setup already, but I have to click a button to refresh info(that comes json formatted, so json.decode is the only thing I've used from MVC so far) and I don't really want to have a from-time-to-time auto refresh, though I've in fact never really heard of Web Api or SignalR. And never really got into MVC except when research pointed to it (which is amazing given it was probably exactly what I actually needed). It does seem really nice from the little I've read so far though : )

 

Thanks a whole lot man!! :D. 

 

Also, and this is just me being a stubborn duckhead, but how can polling not be real real time? You do get something back when something else triggers it :P.

No fair enough man, I dont think I explained myself very well. While some people consider polling real time, I believe this is incorrect. To explain what I mean about the differences here I'll give you an example that im actually working on right now.

I have my client side (website) which the user can invoke a long running operation on the server, how I have it configured is that when they invoke this action it gets put into a queue since it is very CPU intensive aswell. So the flow from the client side goes: User clicks START -> request to server -> Server places request to process in queue (database) -> response back to client telling them success.
So as you can see that's a nice an simple process, the issue is that even though the process is long running it provides a result that the user will want to see at some point. How is this solved? With real time connections!

Now to solve this with polling we could just poll the server every second or so to check if it's done, but this operation takes about 5 minutes so that's 300 (60*5) requests to the web server and then 300 from the server to the db, this is where polling is bad.
Or the other way we can solve this is with EventHandlers, in this example I am using SqlDependancy: User clicks START -> request to server -> Server places request to process in queue (database) Aswell as placing a OnChangeEventHandler on the table which will fire when it changes next -> response back to client telling them success. Then when the OnChangeEventHandler fires it sends a request back to signal r which then grabs the new data from the DB then sends it to the client.

 

It's probably still not the best of explanations but might get my point across, I'd give you a link to the website to show you it in action but it's not quite done yet

[¨TrisT¨]

On 4/25/2016 at 4:39 AM, Toxicable said:

No fair enough man, I dont think I explained myself very well. While some people consider polling real time, I believe this is incorrect. To explain what I mean about the differences here I'll give you an example that im actually working on right now.

I have my client side (website) which the user can invoke a long running operation on the server, how I have it configured is that when they invoke this action it gets put into a queue since it is very CPU intensive aswell. So the flow from the client side goes: User clicks START -> request to server -> Server places request to process in queue (database) -> response back to client telling them success.
So as you can see that's a nice an simple process, the issue is that even though the process is long running it provides a result that the user will want to see at some point. How is this solved? With real time connections!

Now to solve this with polling we could just poll the server every second or so to check if it's done, but this operation takes about 5 minutes so that's 300 (60*5) requests to the web server and then 300 from the server to the db, this is where polling is bad.
Or the other way we can solve this is with EventHandlers, in this example I am using SqlDependancy: User clicks START -> request to server -> Server places request to process in queue (database) Aswell as placing a OnChangeEventHandler on the table which will fire when it changes next -> response back to client telling them success. Then when the OnChangeEventHandler fires it sends a request back to signal r which then grabs the new data from the DB then sends it to the client.

 

It's probably still not the best of explanations but might get my point across, I'd give you a link to the website to show you it in action but it's not quite done yet

I don't think you understand what I mean with long polling. It's basically exactly what you are doing. Long Polling is just holding requests until an even fires (as described in the link). The deal is I'm trying to achieve this through a c# (I have now gone over to c++ because I need linux compatibility) server. Where the event is a request from the actual web server on a different port telling which holding client connection to respond to with what information

Then the client queries the API area of the actual web server, getting a json string as a response.

 

So:

Client => Request sent to c# server on port 1 -> waiting for response -> Request responded to with z info -> process z info -> query the API on the actual web server with z info -> Apply results from query;

Actual web server => User completed form on  actual web server -> page that processes the form -> request to c# server on port 2 with x user and z info;

Query received -> respond with Y json object depending on z info;

C# server => Request received from x user on port 1 -> waiting for event -> request received from actual web server on port 2 for user x -> event fired on user x -> request sent back with z info for every device on user x;