摘要

  • RFC 3421 允许 SLP 客户端要求服务器给匹配的服务 URL 排序并只返回若干项，但第一项只证明它在指定键和服务器所持属性中排在前面。
  • 协议刻意分开总匹配数 m、返回上限 n、NULL 与类型错误、键优先级和扩展处理顺序；任何一项变化都可能改变最终候选，却都不能证明服务可用。

“获胜者”在连接之前就产生了

用户要找最快的打印机、负载最低的服务器或最接近目标能力的设备。看起来，这是一项关于现实性能的选择；但服务发现名录通常比较注册记录。排序完成时，客户端可能还没有打开连接，更没有完成认证、请求和业务操作。

2002 年 11 月发布的实验性 RFC 3421 为 SLPv2 增加了两个扩展。Sort 按属性排列匹配 URL，Select 限制返回数量。这可以减少低带宽链路上的回包，也把“最佳”的计算方法暴露出来。

第一名的真正含义是：某台 DA 或 SA 使用它当时保存的属性，按请求声明的键、类型、方向与先后顺序处理后，这个 URL 位于返回列表首位。它不是刚完成的测速，也不是健康、身份或业务成功的回执。

m 不是已经交给客户端的清单

客户端发送 Select(n)，要求最多返回 n 个 URL。支持扩展的服务器在回复中给出 Select(m)，其中 m 是全部匹配数。如果 n < m，客户端只得到前 n 项；只有 n 足够大时才收到全部匹配项。

Select(0) 把边界写得最清楚：客户端可以只取得数量而不取得任何 URL。因此“发现了 m 个服务”需要说明是目录计数、返回清单、尝试候选还是成功服务。仅有 m 不能证明客户端检查过这 m 项，也不能证明目录曾实时探测它们。

反过来，回复中有三个 URL 也不能推出总共只有三个。可能只是请求者为节省带宽设了 n=3。若系统只保存回复数组而丢掉 m 与请求上限，后续审计就无法区分完整集合和截断窗口。

Sort 排的是声明模型，不是现场性能

Sort 携带按优先级排列的键。每个键指定属性名、字符串或整数比较、升序或降序，并可为整数提供参考值。参考值排序使用绝对距离：如果目标速度是 12，那么记录值 12 排在 10、15 和 8 之前。

这个结果在数学上可以完全正确，却没有执行新的速度测量。值是谁写的、何时写的、是否仍然有效，是另一条证据链。字符串按 SLP 规则做词法比较，整数使用规定的匹配规则；同一属性重复出现时，只有第一次有效。请求本身决定什么最重要，也决定大或小代表优势。

缺失和错误值仍然影响名次

真实名录不会每行都完整。RFC 3421 把缺少排序键的条目视为 NULL，NULL 排在所有有效值之后。如果一个属性按整数排序，却含有不一致的值，它也被当作 NULL。多值属性则取最小值参与排序。

这些规则避免各实现随意猜测，却没有消除偏差。没有负载字段的服务会落在任何有有效负载值的服务之后，不论它的真实负载如何。多个负载值只贡献最小值，不代表平均值、最大值或最新值。类型错误造成的低排名，也不能仅凭列表与真实高负载区分。

因此排名既反映候选，也反映数据质量。要解释结果，必须保留原始属性、类型判断和 NULL 原因，而不能只保存最后一名和第一名。

先截断还是先排序会改变答案

同一请求里出现多个 Select 与 Sort 时，RFC 3421 要求按出现顺序处理。先按速度降序排序，再选三个，再在这三个中按负载升序排序并选一个，得到的是“记录中的三个最快者里负载最低者”。

如果先选三个再排序，其他候选在速度比较前就已经消失。若直接按负载排完整集合再选一个，回答的又是另一个问题。扩展序列实际上是一份小型查询计划；每一次 Select 都改变后续 Sort 能看见的总体。

最终 URL 因而不能脱离操作顺序解释。只记录最后一个排序键，就像只记录数据库查询最后的 ORDER BY，却忘了之前已经执行过 LIMIT。

能力声明先于扩展使用

支持 Select 或 Sort 的 DA/SA 会在广告中给出 select-enabled 或 sort-enabled，UA 应在使用前检查。服务器不支持扩展，或无法完成请求的排序时，回复 OPTION_NOT_UNDERSTOOD。

能力关键字证明的是声明支持。零错误码证明请求被处理并完成排序。它们都不证明属性新鲜、属性作者可信、所有合格服务都完成注册，也不证明首位 URL 会响应。

文档还把排序称为 best effort。这个词不是取消规则，而是限制结论。请求、能力、错误码、键序列和返回顺序都可以核验；目录快照与目录之外的运行事实仍需单独取证。

强制实现扩展空间不等于普遍部署

IANA 将 0x4002 与 0x4003 分配在 SLP 的“mandatory to implement”扩展范围。这个位置描述的是扩展框架中的处理约定，不能把实验性 RFC 变成所有产品已经部署且正确运行的证明。

文档状态、号码分配、代理广告、成功处理、连接成功与业务完成分属不同层。把其中任意一项提升为全链结论，就会让可追溯的记录退化成传闻。

排名之后还要走第二段路

服务发现结束后，客户端仍要解析 URL、建立连接、协商应用协议、认证对端并执行操作。某一步失败，不会让之前的排序算术变成错误；它只说明排序与服务结果的证明范围不同。

这正是 RFC 3421 的历史价值。它不仅节省了回包，还把“最佳”背后的政策显形：谁提供属性、快照是什么时间、怎样比较、NULL 放在哪里、哪些键优先，以及候选在哪一步被截断。输入被保存以后，第一名可以有用，却不再假装全知。

来源与边界

主文献包括 RFC Editor HTML、纯文本、RFC Editor 信息页、Datatracker 文档页、历史记录、引用关系和 RFC Editor 勘误检索。

SLP 背景来自最初的 RFC 2165、SLPv2 RFC 2608、服务模板 RFC 2609、API RFC 2614、LDAP 排序模型 RFC 2891、属性列表扩展 RFC 3059、IPv6 用法 RFC 3111、厂商扩展 RFC 3224、网格增强 RFC 3528、远程发现 RFC 3832和 IANA Service Location 模板注册表。分析方法采用 Heng Lu 关于运行代码作为第一证据和最小初始规范的论述。

这些资料证明协议规则与文献沿革，不测量当前部署、注册完整性、属性新鲜度、实时延迟、现时负载或服务成功率。