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

[blackstack]

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

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

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

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

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

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

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

[pagxir]

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

[BD8NCF]

IPC 用 Socket 的很多

[bloceanc]

问问他的理由

[mioktiar56]

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

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

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

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

[nagisaushio]

用 socket 不是很常见

[bloceanc]

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

[iceheart]

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

[zsxzy]

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

[wshcdr]

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

[shijingshijing]

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

[GeekGao]

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

[blackstack]

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

[blackstack]

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

[ecloud]

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

[blackstack]

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

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

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

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

[blackstack]

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

[blackstack]

@ecloud 了解了，感谢。

[GeekGao]

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

[MoYi123]

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

[blackstack]

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

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

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

[GeekGao]

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

[blackstack]

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

[blackstack]

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

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

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

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

[povsister]

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

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

[bagel]

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

[blackstack]

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

[blackstack]

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

[mainjzb]

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

[Mithril]

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

[tool2dx]

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

[defphilip]

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

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

[defphilip]

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

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