61–70 of 87 posts
python3 -c "import socket, sys; host, port = sys.argv[1], 80; s = socket.socket(socket.AF_INET, socket.SOCK_STREAM); s.settimeout(10); result = s.connect((host, port)); s.close(); exit(result == 0)" unknownlxlaxkck.com 2>/dev/null && echo connected || echo fail
I’m surprised there is no mention of netcat (nc).
nc -vz host port
> Another beneficial difference of this over the old telnet approach is that with that, a successful connection would show a blank screen if the connection, awaiting commands. You'd have to know telnet keystrokes and commands to break out of that Not when it says "Escape Character is 'CTRL+]'" every time you run it. Or does that depend on how you run it with the windows version?
$ nc -vzw1 host portEarlier quoted context omitted.
Yeah, but it's still port numbers under the hood. The big downside of this is that you can get clashes. For example, VNC uses 5901 and up on my system. What if I have some other service that uses ports in the same range? A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. And it would work even if you don't ha…
> A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. More sane, but absolutely slow. Every gateway, NAT, firewall, router and switch between two devices would need 15x more RAM, and even with that RAM would need to parse strings, deal with unicode, etc. All of those are slow operations. Using 16-bit numbers m…
Earlier quoted context omitted.
> A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. More sane, but absolutely slow. Every gateway, NAT, firewall, router and switch between two devices would need 15x more RAM, and even with that RAM would need to parse strings, deal with unicode, etc. All of those are slow operations. Using 16-bit numbers m…
It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them.
Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number.
Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a lookup service for the name. AIUI, you proposed to replace the number with a name, no?
In which case, absolutely no one is proposing to replace inode numbers with names, so inode numbers/filenames as an example does not validate or lend support to your proposal for replacing port numbers with names.
[1] I'm on a personal quest to stop misunderstanding people in a way that reduces the strength of their argument. It's not going as well as I though it would, and I still do it sometimes.
Earlier quoted context omitted.
It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them.
> It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them. Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number. Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a…
Earlier quoted context omitted.
> It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them. Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number. Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a…
Well, frankly I don't care how the ports are implemented, by numbers would be fine. As long as it means that from the user's point of view they are names. A config file like /etc/services is too simple because I create ports all the time, even from scripts, and I don't want to always become root to change the config; and other systems that want to connect to ports on my machine can't read /etc/services on my machine.
However it only works on your machine.
If you want to have it work on your local machine, DNS SRV records on your local network would work.
The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP.
Earlier quoted context omitted.
The reason this hasn't been done is that it would require changes to the headers of TCP and UDP, which would be a massive undertaking (for similar reasons to why IPv4 -> IPv6 is such a pain). Would both the source and destination ports both be strings? Normally, for a client->server packet, the source port is meaningless, so what string would you use? Or would your new protocol support both string ports and integer p…
> for similar reasons to why IPv4 -> IPv6 is such a pain Much less painful though because only the endpoints would need to know.