There were multiple things in your response, so i split them :) TL;DR: Your problem is related to windows, not http knowledge. It has become a longer reply than i intened. maybe it helps to clarify the HTTP stuff :)
Access Control Lists:
Ups. There is a typo, it should be ‘ACL’ not ‘SCL’.
Yes, allowing proccess in windows to listen to a network socket (considered insecure by windows, other than the local machine itself) is … let’s say ‘unconventional’ to set up . However, this is needed as soon as one wants to serve on interfaces other than ‘localhost’. It involves setting the type of traffic/packets, the interface (usually identified by the IP), the port and the user running the process.
It is possible to run some special netsh .... command (as Admin) to allow serving, e.g. http (https,) on a certain address schema.
It much easier using the tool, mentioned in the patch, to do this. This needs to done only once on the machine. When you run it, select the ACL tab and add the following schemes:
- ‘http://*:8080’
- ‘http://+:8080’ (this work most flawlessly, although the pattern is not conventional)
Go to the properties of each and make sure the user is allowed to listen and delegate. Optionally, add ‘Everyone’ or ‘Jeder’ as a user group with the same liberal rights. Interestingly one need not set an executable binary related to this.
Now you should be able to ‘listen’ to all (*, +) http traffic coming in on port 8080; with the HttpListener or the HttpReceiver node (or any other node or process, consider security ;). I really mean, consider the security. Depending on where the machine is located, this can be a risk; a moving laptop with an HTTP service running along… But we all are careful patchers anyways.
I found the project on Codeplex and it seems, by looking at the source, that this could alos be moved into the plugin, but is not straight forward.
When you want to listen on a different port, add more schemas and your done.
HTTP:
On the left side of the test patch, the HTTP ‘sending’ nodes are just for testing, you could also use a browser, but that way one doesn’t. Setting a proxy can be a requirement, when you have to use one; 8080 is confusing here, but it is a quasi standard port for proxies. Maybe there should be PR to make them hidden by default. AFAIK these are very old nodes…
The HTTP (well, 1.x at least) is a stateless protocol, transported over TCP. A good server manages the connections for you, so you just have to take care of the requests. It check if it is a valid HTTP quest, aggregates packets, etc. The HTTPListener is doing just that. It can be queried for incoming connections (a HttpListenerContext), which the plugin does, in a background thread. It pumps the contexts in a concurrent queue and puts them in a spread on every frame. So, there might be backlog, of your FPS drops…
However, these Contexts must be handled (read ‘.Close()`ed’), otherwise the remote party (the client, browser, etc) will have dangling open connections and at some point decides to close them due to timeout. At least a properly implemented client does. The server also manages things like ‘KeepAlive’, etc.
With the plugin you can do this with the Writer (HTTP), NotFound (HTTP) or Abort (HTTP). They ‘Close()’ the context, finally. So make sure a spread of contexts always ends up in one of these! The patch shows an example by responding to different paths (urls) differently, simulating a “Not Found, 404” for anything else than ‘/’ or ‘/test’.
The reason, why this is a separate node, is that one can now also use the Reader (HTTP) and examine/process the request data/object before computing a response. Also shown in the patch. With he old nodes, this was not possible (as you pointed out) or made a Framedelay unavoidable.
So one other benefit, besides accessing the request body (header, method, etc) is that each request, gathered between two frames, can be served maximum as fast as the next frame.
Maybe this can be done ‘properly’ with VL and async subpatches though.
