使用 socket 做进程间通信的架构师属于什么水平

难道你没用过 pf_unix ，我是觉得你菜点。另外，Android 上因为 sepolicy 关系，所有 IPC 在不存在父子关系的进程间几乎不可用。所以规范做法就是用 binder/aidl ，至于 Windows 就随便

IPC 用 Socket 的很多

问问他的理由

服务器上用 socket 没话说，但涉及到客户端的，如果还用 socket 的，可能就不太合适了。

之前项目没时间自己写 rpc 框架，用的 thrift ，遇到了一些问题，比如：
端口被占用情况；
端口假可用性的情况；

后面自己花时间写了个基于共享内存的 rpc 框架，总算解决了那些问题。

OP 可以看看 https://github.com/winsoft666/veigar

用 socket 不是很常见

用 Socket 还是 FIFO 或者 UNIX socket 或者 loopback 或者 shared memory 在很多情况下区别不大，这时候主要是看习惯和可维护性

移植方便，是不是有系统迁移的需求？

用 Socket 更方便跨平台.. 编程也更简单.. 现在 win 也支持 AF_unix

用套接字就是繁琐点，累一点

pf_unix 本机 localhost 通讯也是走内核，而且数据不需要经过网络协议栈，不需要打包拆包、计算校验和、维护序号和应答。支持 stream 和 datagram 两种方式，使用 stream 方式也能保证 reliablity ，数据完整性和收发次序和 TCP 一样能保证。
缺点是数据还是要经历从一个应用拷贝到另一个应用的开销。

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

@iceheart 没有迁移的需求，都是原生开发

@bloceanc 没有理由，他写的就是标准和规范。

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

@GeekGao 并不是，最初这个项目只有我一个人在开发，后面他参与进来，就必须用他的标准来做。

我用 Named Pipe 在前，他定义规范在后，然后要求我按他的规范重新改。

并且改的理由就是遵守规范，规范是他定的。

这种事情不是一次两次，比如后端接口有个参数，他不需要，出于节约流量的目的，就让后端删了，从来没和我沟通过这参数我是不是在用，只能我去适配他的修改。

@pagxir Android 开发不太了解，他也是第一次写，Binder 也不是 Socket 吧？

@ecloud 了解了，感谢。

@blackstack 哈哈， 那你可以多问问他 why ,请教他不这么改会发生什么、改后会产生什么新的问题

@GeekGao
没啥用，问一下就说不想这么改就去找领导说。
领导不太懂技术，我提了我的看法，结果就是一句按标准做，详细的先不谈了，我详细说了我的担忧，结果不回消息了。

socket 我最担忧的没有添加验证手段，验证请求的合法性。
如果是恶意程序发送的 socket 请求也无法区分。

我们做的是安全产品，如果连自身安全都确保不了，怎么卖给客户？

@blackstack 那你可以说出你的担忧啊，难道不给任何解释？ 倘若真的不给解释就听领导的，留下变更文档/邮件，出事儿不要接锅就行了啊

@GeekGao 有道理，明天上班谈一下，如果听不进去，写封邮件说清楚不是我要这么做的。

@GeekGao 不过其实也没什么用，最终出现问题还是要让我来改。

之前就有个设计，我提出这个设计是不合理的，架构师又怼我说不要老想改需求。

我不得已按他们的设计方式实现了，结果到甲方那里演示人家也觉得这样不合理，得改回我原来的实现方式。

结果还是我来改，他们只要动嘴就好了。

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

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

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

@bagel 就是 TCP Socket ，然后限制只能 127.0.0.1 的请求，至于有没有限制我还没仔细看他源代码不清楚

@povsister 明天还要讨论另外一个需求，会上再提一次，不行就是发邮件加抄送，发钉钉消息。

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

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

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

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

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

用 scoket 写 ipc ，你写到倒是简单啊，有没有考虑过后续处理用户反馈的痛苦？

在我们这里的一个核心组件，为了照顾 android 要常驻后台，必须进程间通讯，并且为了跨平台，硬是把组件的调用方式改成了 socket （甚至 windows 都不是多进程的），天天都有用户反馈为什么这个有问题，那个有问题，一大半都是这个 socket 通信的问题

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

绝逼是只会 scoket ，像我一样

我觉得如果争用 socket 工具、还是 namedpipe 、unix domain socket 等工具，那是一点意思都没有。
这些工具无非是提供了流式传输的能力，他们本身都可以为你的应用程序流式传输数据。
理论上传输层从 tcp 变成 namedpipe ，或者从 namedpipe 变成 quic ，或者在既有的传输层套一层 TLS ，对你的应用层几乎没有影响才对，如果有影响，说明你们造的不是应用，而是想造传输工具（显然你们也不想造也造不出来吧）。

标题的重点是 “架构师”，楼主的言外之意就是这水平也是架构师？那我也胜任架构师，领导没有眼光找的人什么水平，连我都不如。

讨论具体技术脱离了问问题的人的心理。

本地使用 domain socket 也算是比较常见的处理方式了 管道一班不是父子进程用的比较多吗

他官比你大，做决定不问你，你不服气。
这在职场很常见， 也许他擅长吹嘘，也许是他真有本事，但是不管怎么样，你不喜欢他。
我的建议是，别对公司投入太多感情， 你写代码就是为了挣钱过上好生活，公司的代码公司决定， 大不了你干不下去换个公司。以前你可能有个错觉，这块代码是你的一亩三分地，现在你应该明白了，这是公司的代码，不是你的。

无论怎么说, 先撇清自己的责任, 别到时候背黑锅.
提安全意见抄送给领导, 让领导决定.
从技术上讲, socket 挺常见的, 而且也多平台通用, 安全防护 ssl 自己封装一下也可以啊, 做好限制我觉得没什么问题, 功能实现就行了。至于更改问题，我也觉得是另一个人不会用， 只会用 socket ， 哈哈哈

考虑通用性还是选 Socket 吧

@jorneyr 主要是窒息的操作太多了，比如说 get 请求不安全，要求客户端下载更新包的时候只能用 post 请求…

然后不知道灰度发布是什么，设置的更新接口不能区分渠道，后面会有几万个设备同时运行，他选择让几万个设备一起更新到最新版。

接口也没有任何向下兼容的设计，万一部分设备没有更新到最新版，就等着让它们挂掉…

@dajj 感谢，你说的很有道理，随他吧。

@lonelyparasol 现在他的方案就是 socket 裸奔，没有任何身份认证。

我这边简单做了一下请求进程的认证，现在他要我改成跟他一样裸奔的方式，实现上没什么难度，就是非常难受。

@raviscioniemeche 我也不是专业搞 windows 客户端的开发，实际上做的是.net 后端，管道通信一般不用在不同软件之间的进程通信吗？

你们的产品发布之前不过安全检测么？找个红队干他一下。

我认识个家伙，做加固的，新来的阿里领导看他不顺眼要搞他，但是这个领导不懂安全，就找了个阿里安全的搞了他一把，但是没搞动。。。后来就不找他麻烦了，这事儿比较搞笑。

你这个呢，方案的确认和实施，要有邮件往来留存的，至少要抄送到相关干系人。邮件的语气不要客气，正式，每次的技术讨论要有会议纪要，各方抄送。

目的不是甩锅，而是防止背锅。很多事儿，跟技术没关系。

类似于 6 楼说的 一般熟悉网络技术栈的开发者会优先使用 socket 似于网络通信的 api 方便在 unix domain socket 和 tcp/udp 互相移植 这个和 windows 或者 unix-like 等平台无关 属于是习惯或者熟悉之类的。这种非业务层面的技术沟通 如果后期他也会维护你的代码 你俩就好好商量。如果他不参与你的代码维护 建议看着办 [手动狗头]

使用 unix domain socket ，就是上面有人说的 pf_unix ，权限充足的情况下在 linux 上是可以获取对端执行文件信息包括路径的。
从你的描述来看，你做了简单的认证，有多简单没描述，你们的安全基线或者说安全的可证明性前提也没有，所以我并不觉得能够证明是架构的水平不足。

“我林家满门忠烈，你懂个屁的 Windows”

发现 windows 也有 pf_unix
要求 Windows build 17061

https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/

windows 上用有名管道即可，用 socket 容易被别人攻击。
我看描述是在跨平台和安全性上的抉择，如果公司比较闲大家讨论讨论还是能增长不少见识的。
如果比较卷的话，谁负责就听谁的呗。

做两个 flutter 进程之间的通信，命名管道确实在 flutter 上封装的不完善，最后还是选择用 socket 。
不过只是作为传输层，后期有需求在换掉

@hxndg Android 目前没有做任何认证，只是绑定 127.0.0.1 ，我这边的 windows 是检查了下进程的路径，看下是不是合法的进程发起的通信。

@valord577 问题就是他只负责提要求，然后遇到的问题让我自己想办法……

@dododada 基本上需求的变更都是口述，没有留下会议纪要和痕迹。

有些甚至是他自己和后端拉个会，自己决定自己改，接口变更，我都不知道。

等我下次改代码，发现接口变了，只能被迫跟着改。

说实话我对 pipe 或者 Name pipe 印象很差,可能作为入门必学的 ipc 方案,很多初级工程师用的关系,经常出问题.
换我我用 socket,当然我只做 linux 下的开发就是了

拉磨的驴嫌弃鞭子不够瑟琴

挺多的

@blackstack #41 不懂灰度发布在某种程度上算蛮正常的 ，毕竟前段时间的全球蓝屏事件就是 CrowdStrike 的软件全局推送了有问题了 sys 文件，国外大厂都不知道咧~

没看懂您这描述，进程间通信是谁跟谁通信，Android 和你 Windows 通信吗？

@vipfts 哈哈，有道理

@DefoliationM 不是，Android 上是其他厂商和我们的程序通信，Windows 上也是如此。

强行要定规范改方案的，如果你质疑，他提不出什么理由，那大概率他只是按照自己以往的经验，或者他只知道这种方式，并且他也没想清楚这种方式的意义
哪怕他只是说：“安全性低点后面再加密，socket 扩展性好。”能说出这种，也算是对方案有自己考虑的，不管方案对错。
不解释的在哪都令人讨厌，无非就是那套官威罢了

gRPC 呢

用 DDS 吧

thrift 或者 grpc 感觉都行

@pagxir 妈妈。。。 不

不说技术，感觉你们技术方案的设计和确定上缺少流程这个问题更致命。
需求文档设计文档没有的话，后续很容易出问题。

而没文档能反映出很多管理上的问题。

我这边的项目用的进程间通信基本都是 domain socket 。。。。

用 socket 有啥问题

@blackstack 管道一般在父子进程用的比较多 不同进程用 socket 比较多

socket 应该是更通用，应用更广的 ipc 通信方式，一个是各个系统都能用，一个是扩展性好，改成跨机器也方便。在支持 socketpair 的系统上，趁手的很，再不济走回环性能也没比 pipe 差到哪去。

socket 可以和 poll 、epoll 之类的共用，win 的 pipe 却不行，在服务器端几乎是必选

不过你这是安卓和 win 的话，情况大不一样。因为 win 不支持 socketpair ，它的 pipe 接口和 linux 的也不一样，要么各个平台代码分开，那么 pipe 在 win 平台确实简单一些。可如果要统一代码，那只能改成 tcp socket 之类两个平台都有的东西。

至于安全性，这两个本身都没有安全性啊（如果非得说别人攻击时，肯定会首先扫端口，那 tcp 确实更容易暴露）。pipe 本身它也不知道另一端是哪个程序，要做安全还得在数据通信里做。

本地 socket 不是很常见吗？ 本地回环很快的

本机 socket ，别想太多，能扫你本机 socket 的啥不能干？一定要做安全也只能通信本身处理。

还是看业务场景。。。

好奇 socket 除了 op 说的验证问题还有什么缺点？

*nix 用 socket 没啥毛病，win 我会选 shared memory

我支持架构师，用 socket 就为以后可能的跨操作系统跨设备留好扩展空间，用管道就局限在本机这一亩三分地……
架构师不仅仅要实现眼前的需求，还要有点想象力，俗称 [规划] 。
至于安全认证，那是另一个问题。

这种不是直接上 grpc 就行了，简单通用还好写。不过 socket 也没啥毛病吧，以后 android 和 windows 搞不好还要互相通信呢，走网络栈怎么想都是比较稳妥的做法。

看下来非技术之争，乃话语权之争

我之前做 Windows 客户端也用过 Socket ，后来发现用户那边会遇到一些离奇 bug ，后面改用命名管道了。

android 用 binder ， 如果 android 给 window 通讯用 socket 没啥问题， 不然肯定是使用谷歌规定的方法比较好

你的命名管道有认证吗？

用 socket 再正常不过了，没记错的话 libevent 在 Win 上单进程内都有用 socket 做事件通知

看是什么 socket
socket domain 确实可选
但身为一个资深类 unix 用户给我选应该是写管道 需要远程转接即可 因为命令行标准输出入友好 可本地可远程脚本测试除错方便 符合 kiss 原则 使用起来爽的不能再爽

留书面证据时，还要明确写出你的 named pipe 在先、他的 socket 随后推出，这个时间关系很重要。

顺便把楼上各位提到的 Windows 为什么要用 pipe 的理由说清楚，重点讲述 Windows 的安全特性跟 Android 的不一样，只能这样做。

如果对方耍无赖，那就直接怼回去：我当初开始写的时候，你干嘛不把标准提出来？为什么你拒绝事先把话说清楚，非要在完工的时候才把“标准”列出来？你这样做会导致工期延误，造成的损失是不是你来承担？如果因为安全特性不同，按照你的标准干活后导致出现安全隐患，是不是你负责？ release 给客户前，要不你来做安全验收，一旦出了事你也得背锅。
（语气语句可以适当调整）

还有一点这么搞可以自动化 好用
现在应用动不动就 tcp api 很不好用

太难受了，他不走，就我走，我光看这你描述就难受。不管怎么操作都是给自己找了个天大的麻烦。

支持 @bagel 的答案。
既然你是安全产品，很可能是 system 权限。
socket 是没有权限限制的，后果就是任何一个具有普通权限的程序都可以暴力破解你的验证，从而接管你的软件，甚至通过你软件的 bug 提权。
而隔离不同权限之间通信，之前就是 named pipe ，现在也有了类似 Linux 的 pf_unix 。

虽然不想说,但是很多条例,本身就是记住就好了,要知道条例之所以是条例,那就只有踩一次坑了.哪来那么多的机会让你踩坑

一句话,菜就公式化.你想要灵活,就只有高手了.

不跨平台，windows 肯定命名管道啊。他哥们是不是没开发过 windows 。 用 socket 不是不行，坑有的你踩

@blackstack 真离谱，要真是这么回事，你说的这问题都不叫事，后面有你受的

我是觉得有多个端的话还是用通用的 IPC ，不管以后跨不跨端，需求赶不上变化

问题是你们没有提前讨论和确定实现细节

参考 QLocalSockets 封装一套? win 下命名管道, 否则就用文件 socket

@dajj 自从我接受了这个现实，想怎么改都行。只要给我时间，不让我加班，我都行的。

这其实不是一个技术问题。
只是你们两冲突的问题。就算我们说你的方案好，别人也不理你的。

请问下，IPC 用 Socket 的多吗？是纯属他太菜，还是我水平不足？？

为啥不说自己也菜？

我们 unix domain socket 挺好的啊。我们是 go 和 c++进程之间的交互。2000 台机器，每台都是这样的，没遇到过什么问题。