If I were creating a webserver then there would be one thread listening to port 8080 and every time there was a new HTTP request then it would trigger some logic in the server. I want to implement the same but instead of listening on port 8080 for HTTP requests, then it would listen for commands from the local operating system (OS) on a command-line interface. These commands can come from any terminal in the OS in the same way as HTTP requests can come from any sender that can access port 8080 on the OS.
I hope I am able to implement an OS-agnostic implementation of this idea in rust. I did try googling this idea without much luck; Likely because I am missing the terminology of this idea.
To clarify one use case:
In one terminal I start my "CLI server": Example: cli_server start
In another terminal I make a "CLI request" to the server and the server will handle the request and respond. The response should be pasted on std.out on the requesting terminal. Example: cli_server fetch_note id-22 or cli_server update_note data_in_file.json
The Server should keep alive until asked to shutdown. It is not known how many independent terminals will access the server at a time.
What I imagine I need is some code similar to the code that listens on port 8080.
It is fine to split the code in a cli_server and cli_client if that makes the answer more simple (or possible).
I do know that I could just implement a web server and use curl to hit port 8080. I am prepared for this as a workaround in case there is no answer to this question. I am interested in an answer to this question out of curiosity and also because that would be a neater solution in my case.
Thanks for reading and I hope my question is not too open ended.
Related
I'm trying to write a test in Node for the behavior of a networking client when it fails to make a TCP connection to a given server. Ideally, I'd like this to be as close as possible to the ECONNREFUSED case rather than some other error like DNS lookup failure, connection closed before receiving a response, etc.
A method I've tried is to make a server that listens binding port 0, then close the server, then connect to the port that was chosen when the server listened. This mostly works, but in CI when many tests are running in parallel sometimes some other test claims the port that was just bound and closed.
If this were C, I could just not set SO_REUSEADDR when binding the port, which should prevent the port from being quickly reused. But as far as I can tell, there's no way in Node to create a listening socket without SO_REUSEADDR.
Any thoughts about achieving this goal? Things I've thought about but not quite gotten to work include:
finding an npm package that lets me setsockopt to turn off SO_REUSEADDR (though I suspect that once the bind has happened it's too late?)
finding some other mechanism that isn't net.Server to bind to a port without SO_REUSEADDR
finding a different mechanism of tricking the client into thinking the connection was refused
(That said, some of the tests I'm writing involve "first the connection works and a later connection doesn't" so ideally something that lets me actually have a real server would be great --- ie my first idea somehow!)
I did everything as specified here:
https://expressjs.com/en/starter/hello-world.html
When I try to reach my domain, and append :3000 to the end, it just never loads (timeout).
If you did everything specified on https://expressjs.com/en/starter/hello-world.html and it didn't work then it must mean that the tutorial is incorrect.
If, on the other hand, you didn't do everything as specified in the tutorial (which we will never know since you didn't post what you actually did) then you should make sure to follow the tutorial more closely because it doesn't look incorrect.
The reasons why trying to reach a random domain on a random port times out can be:
wrong port
wrong domain
bad DNS record
misconfigured DNS resolver
firewall rules
server not listening
server listening on a different port
server listening on a different interface
Unfortunately you didn't provide enough information for a better answer, with that said the most likely issue is that you never actually executed the JavaScript file you created. You'll want to make sure Node is installed and run:
nodejs app.js
Keep in mind that in some distros node doesn't exist, but nodejs does, when installing node from a package manager or other installer.
EDIT
There are other potential issues you'd run into if you don't have port 3000 opened up if you're not running it on localhost.
I want to create a page that simulates a hung/frozen web page. For example, I could use a really long "sleep" in PHP. But if I wanted to make this a public tool, I could well imagine this might eat up server resource (sockets, memory, etc - I'm not that experienced at this level of abstraction) and eventually cause real problems for the server.
I don't want to simply close the socket with the client, because that would not provide the type of "waiting" behavior I want to simulate.
The solution doesn't have to be PHP related. That was just an example. It can be any language and/or web server. The only criteria is FOSS on Linux.
You can simply use netcat to listen on a port and return nothing.
nc -l localhost 8080
Or if you wanted it to continue listening when the client has closed the connection
while (TRUE); do nc -l localhost 8080; done
edit: some versions of nc have the -k option to force netcat to continue listening after the socket is closed. In those cases you don't need to loop.
In our project, the front end UI makes a lot of http request using httpclient to the backend REST service.
I noticed sometime a http request was never even made to the server (using tcpdump)
Is there some kind of limit in Linux that limits the total tcp socket connection one could have ?
I was playing with lsof, but can't seem to make much out of it...
Sorry for the poorly phrased question.
Firstly, I'm relatively new to network programming. I want to intercept and delay HTTP traffic before it gets to the server application. I've delved into libnetfilter_queue which gives me all the information I need to delay suitably, but at too low a level. I can delay traffic there, but unless I accept the IP datagrams almost immediately (so sending them up the stack when I want to delay them), they will get resent (when no ACK arrives), which isn't what I want.
I don't want or need to have to deal with TCP, just the payloads it delivers. So my question is how do I intercept traffic on a particular port before it reaches its destination, but after TCP has acknowledged and checked it?
Thanks
Edit: Hopefully it's obvious from the tag and libnetfilter_queue - this is for Linux
Hijack the connections through an HTTP proxy. Google up a good way to do this if you can't just set HTTP_PROXY on the client, or set up your filter running with the IP and port number of the current server, moving the real server to another IP.
So the actual TCP connections are between the client and you, then from you to the server. Then you don't have to deal with ACKs, because TCP always sees mission accomplished.
edit: I see the comments on the original already came up with this idea using iptables to redirect the traffic through your transparent proxy process on the same machine.
Well I've done what I suggested in my comment, and it works, even if it did feel a long-winded way of doing it.
The (or a) problem is that the web server now, understandably, thinks that every request comes from localhost. Really I would like this delay to be transparent to both client and server (except in time of course!). Is there anything I can do about this?
If not, what are the implications? Each HTTP session happens through a different port - is that enough for them to be separated completely as they should be? Presumably so considering it works when behind a NAT where the address for many sessions is the same.