最近工作中对接了一个国企老油条《程序员》，滴水不漏，分享一下

我们是客户端，他们是服务端。设备上电后他们会 tcp 向我们发数据启动读卡，读卡数据我们会加工成 json 字符串给服务端，设备有心跳包，30 秒一包发给服务端，有本地日志。

服务端做的是收到 epc 数据与他们服务端做匹配，显示对应的物品。就这么简单的对接一年了还没稳定，动不动就让我们查本地 log ，服务端收不到数据，但是每次我们从日志中都能看到服务没断。

上周我算正式介入这个项目，跟鞋服务端的国企老油条有了如下对话：

我：为什么每次远程看到的都是客户端有数据，而你服务端那边没显示？
它：之前我发现心跳正常没传送数据，再发送一次握手数据就过来了

我：你们服务端链接客户端做什么，配置参数吗？(周末又有问题，没吊它)
它：XXX 可说昨天可能断电了，我们后面再观察，看看日志分析问题

我：周六说又停电了，重新上点后服务段是不是要重新配置设备的参数？
它：服务端与客户端是数据传输协议

终端客户：一个早上一个标签都没识别到
它： 目前五个链接一切正常

我： 是不是突然断电或者段往后服务端没有向客户端发读卡指令？
它： 网络连接正常的，心跳也正常
我： 你没回答我的问题
它：150 有没数据了，我看看

现在是我司，甲方，他同事一块在屌他 催他没用，国企老油条主打的就是一个风平浪静。
Yes or No ？ or ！
BYD 的，敲

@coderluan 他们是同一个大集团。终端和服务端那个不是一个部门的。现在终端部门急的找我们准备绕过自己公司的软件部门单独搞了

@fffq 现在在改了。直接传

"向客户端发读卡指令" 这个设计有必要吗，没有必要的话就没必要用 tcp ，直接 http 上报数据就完事了

@chairuosen 可能从一方面叫老油条，但是另一方面叫语言的艺术， 不被你牵着鼻子走而已，从自身考虑这能力挺重要的

“现在是我司，甲方，他同事一块在屌他 催他没用” 那不是自然的吗，你把他领导拉群里啊

感觉你们这个交互方式设计的有点奇怪. 看起来像是服务端主动向客户端发起连接命令,然后和客户端主动往服务端推送数据. 从服务端的实现功能看起来就是一个下发命令然后等待读的简单逻辑. 所以他不停强调连接正常心跳正常下发正常.

做一个中间表 你往上传 和根据表里的去修改 定时轮询 留痕 避免扯皮

这种业务,居然设计出 TCP,直连,判断心跳. 哈好弄个 随便一个 mq,sockt,grpc,srocket,不香吗?

“它”