17 ms·
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 wh
by HL33tibCe7 3y ago
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 ports?
Having ports be strings in the TCP header would make the header considerably longer - supposing your protocol had one fixed length 32 ASCII char string port, you'd be looking at something in the region of a 2x increase in header length.
- Wingy 3y agoCouldn't the port string be mapped to a temporary port number when the TCP connection is initiated? It'd still be necessary for UDP though. It'd still be a massive undertaking though.
- GauntletWizard 3y agoYes, and there's already mechanisms for doing just that - look up DNS SRV records: https://en.m.wikipedia.org/wiki/SRV_record https://en.m.wikipedia.org/wiki/SRV_record
- Dylan16807 3y ago> for similar reasons to why IPv4 -> IPv6 is such a pain Much less painful though because only the endpoints would need to know.
- deleted 3y ago[deleted]