RPC 和 COM 的版本控制理论

只有两种完全万无一失的方法支持新功能，而不会出现线路兼容性问题的风险：

• 根据规则更改接口版本;这会阻止新客户端与旧服务器通信，并且可能会或可能不会阻止旧客户端与新服务器通信。 本节稍后将对此进行说明。
• 引入处理新功能的不同接口。

标准 RPC 接口由 GUID 和版本号组合标识;COM 接口由其 GUID 标识。 版本由主要和次要部分组成。 对于具有相同 GUID 和不同版本号的标准接口，仅当主版本相同且客户端不高于服务器的次要版本时，才能进行连接。

因此，更改 RPC 接口 GUID 会破坏线路兼容性，而更改接口名称则不会。

在标准 RPC 中，升级和扩展的路径定义良好，基本上要求仅在接口末尾添加新方法，而新类型仅在新方法中使用。 如果需要添加此类内容，则必须增加次要版本。 任何其他更改都需要更改主版本，因为客户端和服务器软件在网络上不兼容。 遵守这些规则可确保每当新客户端与旧服务器之间存在连接时（反之亦然），双方是完全兼容的。

对于 COM 接口，不能使用 version 属性。 创建新接口并从旧接口继承相当于在 RPC 中操作版本。 通常，COM 中的最佳方法是为扩展的功能创建新接口。 次要版本的等效项是从旧接口继承的新接口。 更改旧方法或旧数据类型需要全新的 COM 接口-一个不继承自旧方法的接口。

对于 COM， QueryInterface 函数是检查服务器是否支持接口的既定方法;因此，可以轻松解决客户端可以与旧版或新版本的接口通信的情况。