Notes |
(0003354)
shware_systems (reporter)
2016-08-22 16:45
|
I agree this functionality is useful, but as proposed there are difficulties. As a "works for me" decision it's fine, but isn't portable taking IETF requirements into account. As I read the standard, it glosses over as implementation-defined or protocol-defined the effects if an in_port_t is left in it's default initialization state. The UDP protocol specifies it as a "don't care" source, for one. TCP appears to consider it illegal so the bind should fail. It expects the application to set it to a valid nonzero assigned value before use for normal operation with a particular protocol.
Those systems are nominally in error, as a result. Port 0, and others, is reserved to IETF for all higher layer protocols of IPV4 or IPV6 so the suggested usage is precluded. For Experimentation this applies:
RFC 6335 Service Name and Port Number Procedures August 2011
6.1. Service Names and Port Numbers for Experimentation
Of the System Ports, two TCP and UDP port numbers (1021 and 1022),
together with their respective service names ("exp1" and "exp2"),
have been assigned for experimentation with new applications and
application-layer protocols that require a port number in the
assigned ports range [RFC4727].
Please refer to Sections 1 and 1.1 of "Assigning Experimental and
Testing Numbers Considered Useful" [RFC3692] for how these
experimental port numbers are to be used.
This document assigns the same two service names and port numbers for
experimentation with new application-layer protocols over SCTP and
DCCP in Section 10.2.
Unfortunately, it can be difficult to limit access to these ports.
Users SHOULD take measures to ensure that experimental ports are
connecting to the intended process. For example, users of these
experimental ports might include a 64-bit nonce, once on each segment
of a message-oriented channel (e.g., UDP), or once at the beginning
of a byte-stream (e.g., TCP), which is used to confirm that the port
is being used as intended. Such confirmation of intended use is
especially important when these ports are associated with privileged
(e.g., system or administrator) processes.
--------------------------------
IMO this should be expanded to include ports in the User and Dynamic ranges, guaranteed to not cause conflicts with other processes at runtime for an associated destination address. Whether the data structures associated with these would include guard nonces or similar would be a quality of implementation issue. Limiting the assignments to the 2 ports of the RFC may be inadequate for some development scenarios on multi-user server platforms as well.
I see this more as the province of setsockopt() before bind to be robust, whatever the address family, but isn't currently implemented. It would indicate an error if a family didn't use ports or no port in a desired range is available, and as input would specify which port assignment range should be used for the connection where the family does use them. This separates the functionality from any possible conflict using tag values in sockaddr_t initializations, and ensures the socket data can be setup to associate privately with the calling process. |
|
(0003561)
dannyniu (reporter)
2017-02-19 05:28
|
The biggest reason I propose to add it to the standard, is because it's been taught as standard practice.
Here quotes "UNIX Network Programming", by W. Richard Stevens et.al.
Section 4.4 bind Function.
..., but it is rare for a TCP server to let the kernel choose an ephemeral port, since servers are known by their well-known port.
Exception to this rule are Remote Procedure Call (RPC) servers.
...
If we specify a port number of 0, the kernel chooses an ephemeral port when bind is called.
... |
|
(0003562)
shware_systems (reporter)
2017-02-19 16:18
|
That teaching practice is faulty; in that any platform where it applies has overloaded the IETF reserved value, and subsequent protocol-specific usages, by arbitrarily assigning this specific function to it. It is therefore imho a platform-specific, not standard, practice. The place to propose this is more in an IETF RFC as explicit currently unused port values, with my suggested expansions. As some ports are already reserved for similar use it shouldn't be considered too controversial, I imagine, for STD/BCP status as an amendment of RFC 6335.
This way POSIX and all other platforms can defer to that, going forward, and stay compatible with each other. Existing systems and applications that might break due to the change at least can reuse most of their code; for some it may be as simple as a single line header patch and recompile.
Changing get/setsockopt() as suggested doesn't require an RFC, as it doesn't lock down any value assignments, but would be more complex for an application to make use of in a safe manner. It would also be limited to use across a known LAN setup of POSIX conforming systems, as across a WAN or the WWW it couldn't be guaranteed addressable platforms are compatible with all aspects of how the new functionality may be implemented. |
|