由于Offer报文引起的事件订阅失败

        今天在工作中碰到一个车机上someip事件订阅的问题，Android端订阅了S32G发布的定位相关的someip服务(0x0001)中的某个事件（卫星状态），然后这个事件是基于TCP通信的，设置了通信端口50001。

        然后Android端上层应用反馈说收到的GNSS数据有问题，缺少卫星状态，导致上层解析时认为数据非法。因为GNSS数据都是从S32G的someip服务发出来的，因此判断是不是S32G的someip服务和android的someip客户端进程建立了TCP连接以后，没有定时发event数据，通过tcpdump抓包发现S32G的someip服务发送卫星状态数据。

        同时在S32G上查看TCP链路的连接建立状态，使用netstat -anp|grep -i 50001发现S32G上的someip服务有建立socket监听50001端口，但是没有已经建立的TCP连接，说明Android的someip客户端没有订阅到这个事件，所以没有建立和S32G的TCP连接。

        回到Android侧，排查为什么没有订阅这个事件，首先看Android端发出去的订阅报文，发现的确没有订阅这个卫星状态的事件所属的事件组，然后查看订阅报文上面S32G发送的Offer报文，看到Offer报文中有问题，服务的选项中有地址列表，发现地址列表中50001端口只有一个UDP地址，没有TCP地址：

        而Android someip客户端使用的CommonAPI，其中该事件的订阅使用的是reliable配置，也就是希望通过TCP来完成卫星状态事件的数据通信。而S32G someip服务端的offer报文里面，该服务的options中只有(udp：198.18.2.252:50001），缺少了(tcp: 198.18.2.252:50001)的配置，因此Android someip客户端发现没法通过reliable的方式和S32G服务端建立连接，因此就放弃了事件的订阅。

        最后排查为什么S32G上someip服务端发出来的offer报文中缺少了tcp:198.18.2.252:50001的服务选项，发现之前在S32G上netstat看到占用了50001端口进行tcp监听的不是someip进程，而是另一个进程，由于vsomeip的endpoint中没有设置端口复用的属性，因此，如果服务依赖的端口无法绑定上去，对应的连接的地址就不会出现在Offer报文里面。