client
Click on the red underlined text to get to the source
...
In general, it is expected that SRV records will be used by clients
for applications where the relevant protocol specification indicates
...
... for applications where the relevant protocol specification indicates
that clients should use the SRV record. Such specification MUST
define the symbolic name to be used in the Service field ...
... The priority of this target host. A client MUST attempt to
contact the target host with the lowest-numbered priority ...
...
In the absence of a protocol whose specification calls for the
use of other weighting information, a client arranges the SRV
RRs ...
... target host specified in the
selected SRV RR is the next one to be contacted by the client.
Remove this SRV RR ...
...
Expecting everyone to update their client applications when the first
server publishes a SRV RR is futile (even if desirable). Therefore
...
... not useful (or meaningful) may choose to not use SRV's support
for secondary servers. Clients for such protocols may use or
ignore SRV RRs ...
...
The only way the authors can see of getting a "better" load figure is
asking a separate server when the client selects a server and
contacts it. For short-lived services an extra step in the
...
... service name to port number happens
at the client, often using a file such as /etc/services.
...
...
A SRV-cognizant client SHOULD use this procedure to locate a list of
servers and connect to the preferred one:
...
... address records
for all the SRV RR's and the client may want to connect to the
target host(s) involved, the client ...
... client may want to connect to the
target host(s) involved, the client MUST look up the address
record(s). (This happens quite often when the address ...
... router can filter packets. It becomes impossible
to block internal clients from accessing specific external
services, slightly harder to block internal users from running
...