我品出来一种味道：你先是质疑他的能力，然后在收集证据验证自己的猜测。你拿出的证据之一就是本帖。

Unix socket 本来设计出来就是干这个用的啊，tcp/ip 的那版只是一个衍生品

用 socket 不是挺常见的?
搞个 interface 换一个传输方式也就 100 行代码吧.

@blackstack #23
不要只把沟通停留在嘴上，留书面，给他发邮件讲清楚同时 cc 老板。凡事留个证据事后好甩锅。

看你俩一人负责一端的情况下，这么少沟通简直不可思议。他甚至还懒得给你解释技术方案，这种人一般要么是大佬脾气怪，要么就是菜逼只会抄。

如果他用的是 tcp socket 开放端口，那就是菜逼无疑，曾经用这个的大厂 app 爆出过无数个漏洞。unix socket 在 Android 高版本收紧权限后可以用作 IPC ，但是也要实现对。Android 推荐的 IPC 机制是 binder ，如果不是跨端代码库显然应该用 binder 。

还是 socket 好用，最近一年本打算用 flutter 和 go 之间用 pipe 通信，发现 2 个语言对 pipe 的封装都有些问题，各种功能残缺。最后还是用 http 了，没空在 ipc 上浪费时间

虽说想搞都能搞，但 np 还是要比 socket 安全一些的。毕竟不是什么扫个端口就能找到的东西。而且你想拦截消息也困难。

选择 socket 本身并没有大问题，问题是强压方案的做法，让人挺不爽的。

没有跨平台的需求，那就肯定选命名管道，甚至有跨平台需求给我来做也做管道，socket 那么通用为什么 chromium 做 ipc 的 mojo 在 windows 上不用？

楼上很多人就是 linux 后台做多了把后台的想法照搬到客户端上，完全没考虑到 windows 的复杂环境下用户很有可能直接 127 都连不上（比如用户选择联网的时候误选了防火墙选项）。更别说你们是安全软件。这样相当于把后门给别人留足了。

两个都不是最佳选项。Windows 上就用 com+，Android 上就用 binder ，这都是平台推荐的