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

[blackstack]

我们是做安全产品的厂商，最近一个客户端程序，有 Androd 和 Windows 两个平台。

架构师原先是做 Java 的，负责 Android 端的开发，我负责 Windows 端开发。

因为需要和其他程序通信，所以他选定的是 socket ，用于本地进程的进程间通信，这里没有任何跨操作系统和跨设备的通讯需求。

我在 Windows 端用的是命名管道，现在强压我要改成 Socket 。

改 Socket 是没什么难度，但是被强制往自己的代码里糊屎非常难受。

Socket 他还没做任何权限认证，也就是本地的任何线程，不管是其他合法进程还是木马病毒，都可以给它的 Socket 端口发消息，只要格式正确它都会执行。

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

[blackstack]

@ldw4033 我前面说了呀，我也不是专门搞 windows 客户端开发的，也是一边弄一边学…

[blackstack]

@SuperDaFu 这实在要好心态，一个设计被改便了，然后再被要求改回去……

[blackstack]

@iceiceice9527 问题是他用的是 tcp socket…

[blackstack]

@iOCZS 基本上没有讨论，他权利大，想改就改了，想让后端改就让后端改，从来没问过我这里这样改有没有问题。

[xsen]

主流的 IPC 通讯方式（实际产品使用的）或者二次封装的 MQ ，99%以上都是基于 socket 的
按照我理解，N 年前开始应该都没什么人用文件或者 pipe 这样的方式做 IPC 的了

socket 监听 localhost （ 127 ）不存在什么安全性问题，若需要额外加个鉴权则是（应用层协议）

[blackstack]

@SuperDaFu 还是考虑安全性问题，前面已经解释过。
还有另外一方面，客户端的技术选型、框架搭建、功能实现，都是我自己来的。

然后现在他跑出来要求按他的规范来改，他是搞 java 的，我搞.net ，他对.net 完全不懂，硬要来给我制定规范。

[c3de3f21]

在公司，我只为我的上司和老板服务。

[hxzhouh1]

我写过客户端组件之间使用 grpc 通信的

[Araell]

反正就是把所有风险点书面提出来，at 所有相关人确认，说清楚谁做决策谁负责，再细点就是 CR 一行一行跟他过。结算的时候能撇清责任就行，别的不用太纠结，就是上个班儿，不值得

[chutianyao]

用 domain socket 挺好的啊,我记得 android 的 binder 好像就是基于这个实现的? 说明这个架构师有水平

[sampeng]

不是臭 java 怎么样。。但是。。。java 出生的所谓架构师 10 个里面 9 个菜。
你可以提出你的意见，你也可以规划后续的扩展，强压算什么？倒是先解释为什么用 socket 啊？就是一句我们所有程序通信用 socket ？

其实压根不是技术问题。就是沟通问题。用什么都可以，说服团队是所谓架构师最基本的职业技能。如果只是用 title 职位压人，是我肯定要怼回去，最少要怼到上级我不同意。

[sampeng]

按楼主描述。你和他是平行的。。鸟他干啥？？？架构师很少是上级，我就见过一个 titile 是架构师的。天天说我是架构师，你们要听我的。问为什么要选型 xxx 。因为我是架构师。问这个选型可能有问题，能不能换一个。因为我是架构师。

谁鸟啊。。爱谁谁，有本事自己找我老大说去。公开怼技术不虚。全是就事论事。

[victorc]

你菜
主流是用 socket ，不安全就加上鉴权

[james122333]

@xsen

socket 不能直接标准输入 也不需要真的写 pipe 只要标准输出输入正常即可 用 shell 就可以把它们串起来了 socket 要自己实现鉴权多麻烦 不如直接依靠作业系统权限 简单暴力灵活才是王道

[changepll]

建议你写你的。他写他的。达不成统一的。 就走服务端中转。 他不鸟你， 你迁就他有什么好处。

[james122333]

通常纯的 web 仔才会整天 socket 理解深刻点的不会这么想 说人菜的更是不知所云

[xavierchow]

我看楼主的烦恼其实不是具体的技术方案，而是人和人的关系。
良好的团队氛围应该是可以用开放的心态一起讨论问题，其实很多方案也没有绝对的好和坏，要根据场景和其他的各种因素（比如 timeline ，扩展性，成本等）综合考虑，经常要做 tradeoff 。
如果意见不一致，就直接按 owner 的想法走就可以，谁 own 谁决定，谁决定谁负责。换句话说，楼主需要事先明确这个通信方案的最终 owner 是谁，如果是这位架构师，楼主配合就可以，事后如果方案不妥当要返工楼主不背锅就行；如果 owner 是楼主自己，架构师的方案不认同就拒绝。
最怕的楼主心里的 owner 是自己，但是老板心里的 owner 是架构师...

建议找老板聊一下，但是不要先聊技术方案，而是先明确组织关系和权责。

[james122333]

所有人追求不同 但能的话化境宗师都不够 当然要天下无敌

[jamlee]

Node 的进程间通信都是用的这个，还可以传输 fd （例如已经打开的 socket ）。另外进程间可以传输大量数据的，例如日志发给主进程写入文件。

[zerovoid]

这不是技术问题，这是权力斗争问题，你先来，他后到，但是他可以给你定标准，你不爽，但是你最终还是按他的标准改了，这说明他的权力就是比你大，那你听他的差遣就完事了。

[liyafe1997]

个人也觉得在没有网络需求的情况下，在 Windows 上用 127.0.0.1 做进程间通信（或者说仅仅用来做进程间通信）是件很别扭的事情。哪怕在*nix 下也应该用 domain socket 。
建立把这个甩他脸上 https://learn.microsoft.com/zh-cn/windows/win32/ipc/interprocess-communications
让他给个不用 namedpipe 的理由，甚至在 Win10+上已经可以用 AF_UNIX 了。

[tuiL2]

没看明白命名管道怎么就安全了？非法程序想连也可以连吧

[siweipancc]

把我干哪来了？

[yplam]

觉得架构师的技术选型没问题，团队开发用 socket 更容易测试与调试

[moooxin]

可能，单纯的就是 ，其他的 他不会

[zhazi]

从技术层面看
我觉得架构师的设计有问题。
从软件设计的角度看起码得有一个设计思想作为指导，
比如可重用性高、可读性强、可靠性高、灵活性好、可维护性强。起码得沾一样。

所有技术栈都是为了某种需求延申出来的，当前的技术栈可以满足当前需求，为什么要引入新的技术栈。
程序没有任何跨平台通讯的需求，使用一个为了网络通讯的技术，做本地通讯，提高了程序复杂度和可维护性。

从非技术层面我赞同 xavierchow

[blackstack]

@tuiL2 命名管道至少可以知道哪个进程发来的数据，socket 就完全不知道了。命名管道在 windows 下也有基本的用户权限隔离，socket 也没有。

在没做鉴权的情况下，其实都不算安全，但是我个人觉得命名管道还是好点。

[blackstack]

@yplam 主要是就我和他两个人，一人负责一个客户端…

我说可以把我这边的输入输出格式和他统一，但是不同操作系统，没必要强求通讯方式一致，这没有意义。

但他还是要求改 tcp socket 。

[ashuai]

你要么可以把他给干离职，否则这气没什么好生的。

自己抽象个数据收发层，socket 和 name pipe 全支持喽，顺手把 udp 也支持掉。做个数据包的校验，加个开关，默认不启用

[djasdjds]

😂op 的回答反而让我明白了来一个团队第一件干的事情就是先换成自己的人，干活听话

[proxytoworld]

@blackstack 进程名可以伪造啊

[lucasxu00]

@blackstack 话说命名管道也没有比 socket 更安全啊，同样可以被其他进程写数据

[tuiL2]

听起来很鸡肋，他都连上来了，数据也写完了，即使名字有什么用。况且 socket 也可以通过端口号来获得进程名字啊。

[blackstack]

@proxytoworld 进程名加进程路径判断，用户现场基本上不会重装程序或者把程序安装到其他地方。

不过最终还是要加身份认证比较稳妥。

[blackstack]

@tuiL2 感谢指正，查了下资料，tcp socket 的确也是可以获取到的，就是比较绕。

命名管道还有一个好处是可以通过设置安全描述符来实现用户权限隔离，这个据我所知在 tcp socket 上做不到。

[blackstack]

@lucasxu00 命名管道有一个好处是可以通过设置安全描述符来实现用户权限隔离，这个据我所知在 tcp socket 上做不到。

[blackstack]

@ashuai 已经这么做了，他是异地，偶尔过来，他提方案，后面实现如果有坑他都不管的，得我自己来填，否则我也懒得管这么多。