For those interested in the history of alternatives to port numbers: Chaosnet[1] in LispM/ITS times used names for describing which service was being requested. On the TCP side, a spec for requesting services by name has existed since 1988: TCPMUX[2], using a short initial handshake after connecting to port 1. Just never caught on AFAIK.
Wild to vibe code something in a week then charge $50/month for it. I understand servers cost money but lol there’s no way the costs are that high. Also insane the amount of code generated here.
> Recently I wasted several hours wrangling my dev environment only to find out that the browser frontend was talking to the wrong version of the backend.
I have never faced this problem even though I hard-code the port. It's because I run the server program through VS Code's debugger. If there's already a session, it would warn me.
True! But, you wouldn't just need SRV support in browsers--you'd need it in every part of your dev environment / stack that touches the network. If your backend talks to a database, then your backend needs to support SRV. So you need SRV support in your standard library and your browser.
But at a larger level this tool just makes everything work so smoothly. If you have two services with the same name, it pops up a notification in the tray. If you start a new process with a different name, you don't have to configure SRV; the DNS just becomes available automatically. HTTPS is auto configured. That sort of thing.
I think somebody could one day make something like this that was based on SRV, but it would still need all those niceties to make it work well for developers.
I get the problem well. I have built a networking runtime and a Python networking library that extensively used servers as part of testing. If you bind to a specific port and reuse it, you can end up with false failures due to:
- old / zombie server processes
- sockets that weren't properly cleaned up
- TIME_WAITs
my solution wasn't anything as clever as OPs though. Basically, I ended up conceiving of 127/8 as a rotating ring. Where you can pass offsets and easily end up on an unused bind tup every time. 127/8 gives you a huge number of IPs to play with. You just make address handling part of your test launcher and it sets a new IP each time.
The issue is it doesn't really work for IPv6 (v6 localhost is only one address!) Though global-scope v6 interface blocks and manually assigned link-local scope, you could accomplish much the same thing.
For those interested in the history of alternatives to port numbers: Chaosnet[1] in LispM/ITS times used names for describing which service was being requested. On the TCP side, a spec for requesting services by name has existed since 1988: TCPMUX[2], using a short initial handshake after connecting to port 1. Just never caught on AFAIK.
[1] https://chaosnet.net/protocol#application_layer [2] https://datatracker.ietf.org/doc/html/rfc1078
Wild to vibe code something in a week then charge $50/month for it. I understand servers cost money but lol there’s no way the costs are that high. Also insane the amount of code generated here.
The part that is being charged for isn't the coding, but the operating. How little should someone charge to be on pagerduty 24/7?
Why not charge $50/month for it? So little effort has been put into the endeavor that it failing to attract a single user wouldn't be heartbreaking
> Recently I wasted several hours wrangling my dev environment only to find out that the browser frontend was talking to the wrong version of the backend.
I have never faced this problem even though I hard-code the port. It's because I run the server program through VS Code's debugger. If there's already a session, it would warn me.
Well, there's your problem! You're not getting the efficiency gains of multi-agent slop slinging loops working like that…
> why on earth are we still using simple numbers to describe which process to connect to? Why not use names instead.
Not super popular, but: https://en.wikipedia.org/wiki/SRV_record
Yep, my immediate reaction was "because browsers refuse to support SRV records" (although I think there was some new variant that kinda worked?)
True! But, you wouldn't just need SRV support in browsers--you'd need it in every part of your dev environment / stack that touches the network. If your backend talks to a database, then your backend needs to support SRV. So you need SRV support in your standard library and your browser.
But at a larger level this tool just makes everything work so smoothly. If you have two services with the same name, it pops up a notification in the tray. If you start a new process with a different name, you don't have to configure SRV; the DNS just becomes available automatically. HTTPS is auto configured. That sort of thing.
I think somebody could one day make something like this that was based on SRV, but it would still need all those niceties to make it work well for developers.
I get the problem well. I have built a networking runtime and a Python networking library that extensively used servers as part of testing. If you bind to a specific port and reuse it, you can end up with false failures due to:
- old / zombie server processes
- sockets that weren't properly cleaned up
- TIME_WAITs
my solution wasn't anything as clever as OPs though. Basically, I ended up conceiving of 127/8 as a rotating ring. Where you can pass offsets and easily end up on an unused bind tup every time. 127/8 gives you a huge number of IPs to play with. You just make address handling part of your test launcher and it sets a new IP each time.
The issue is it doesn't really work for IPv6 (v6 localhost is only one address!) Though global-scope v6 interface blocks and manually assigned link-local scope, you could accomplish much the same thing.
[flagged]