继续看《AUTOSAR_EXP_VFB》，最近几天身体原因功课又落下了。
客户端-服务器的多样性
对于客户端-服务器通信，仅支持“n:1”通信（n 个客户端，n>=0，1 个服务器）。
这个设计要求其实跟前面的描述没有什么差异。
每个客户端 RPort 必须正好连接到一个连接器，该连接器将那个 RPort 链接到服务器的一个 PPort。 另一方面，服务器的 PPort 可以连接到任意数量的客户端 RPort，即没有一个或多个客户端可以从同一服务器调用操作。 客户端-服务器通信的实现必须确保将操作调用的结果分派到正确的客户端。
由于组件可以具有任意数量的端口，因此单个组件可以同时承担客户端和服务器的角色。
看起来，这个意思是说，实现多种处理服务端其实只有一个。通过组件来实现多种需求的中间继承？
客户端-服务器连接器中的排序和并发性
在同一 RPort中先前对同一操作的调用返回（来自服务器的有效响应或错误）之前，不允许客户端调用 RPort 上的特定操作。 如图所示（输入图号有时候真的很费劲，能够如图或者如下图的一概简化了，毕竟这是在写笔记而不是写文档）。
从这个描述看，其实，在对服务器进行服务请求的时候，如果有还在进行中的应该是要给出否定响应的。
然而，在第一个操作的调用返回之前，客户端可以在同一个 RPort 上调用不同的操作。 但是，在这种情况下，VFB 不对这些调用的顺序做出任何保证。
更具体地说，它不保证服务器看到操作调用的顺序与客户端进行这些调用的顺序相同。 同样，不能保证响应可用于以任何特定顺序发送给客户端（例如，按照客户端调用这些操作的顺序）。
尽管不能保证排序，但 VFB 的实现必须使客户端能够将来自服务器的响应（或来自基础架构，以防返回基础架构错误）与客户端进行的正确相应调用相关联。
不允许客户端在先前调用相同操作的调用返回之前调用 RPort 上的特定操作。换句话说，不能够一个请求交互没完成来第二个同样的请求。
客户端必须能够将响应与正确的相应调用相关联，这个由客户端来实现。
这个图表达的意思是：如果有多个请求，VFB无法保证请求响应的先后顺序。但是得保证请求的响应回答的是响应的请求者。
AUTOSAR 的主要目标之一是 AUTOSAR 软件组件的可转移性以及在不同系统中集成相同组件的可能性。
因此，基本的通信机制不能依赖于通信对象的身份。哪个组件通过哪个端口与另一个组件的哪个其他端口通信，由 VFB 视图中的连接器指定，并且对软件组件不可见。 如果软件组件确实需要知道特定通信场景的通信对象的身份，则必须由组件本身在应用程序级别使用通用 AUTOSAR 通信模式来完成识别。
相比之下，通信对象的明确标识，即组件及其端口/接口元素的实例，对于 RTE 的实施是必要的，也许对于基本软件也是必须的。
健康真的很重要，过去多年超时间工作导致的劳损，让我在这个天气多变的季节吃尽了苦头。连续三天状态崩溃了，昨天晚上又是粒米未进的减肥状态，今天早上总算是稍有恢复了。孔子曾经说过“行有余力，则以学文”。我觉得讲得也很实在，如果还有余力则不该虚度，但是没有余力的时候，还是先去休息恢复一下状态才好。今天的小节暂且到此，简单，但是看到了很多新的东西。如果有UDS的调试经历，理解这部分的确可以产生很多的联想。
