Routing config: Replace processName with process (full-name/abs-path/abs-folder)

[Fangliding]

进程名/绝对路径/文件夹 在Windows上测试了 Linux暂时没有

[RPRX]

测一下吧

匹配自身改成 self/ 了吗

[Fangliding]

改了

[Fangliding]

明天吧 要去吃饭了 Windows上测了一遍主要逻辑没啥问题 Linux就改了几行应该爆不了 也不急着合 主要是想听听其他人意见

[Fangliding]

对了 因为涉及巨大多系统调用 一次这个匹配在Linux上耗时将近2ms(Windows时钟分辨率过于垃圾无法测试)

[RPRX]

还可以接受吧，正常使用平均顶多一秒一个 TCP 连接 / 一组 UDP 来源

[Fangliding]

对路由来说很多了 Meo之前弄的那一揽子geo也就只能让大多数路由匹配过程快个 0.000001 ms 不到的样子

[majorcheng]

Linux下每次匹配会读 /proc/net/tcp*|udp* 并遍历 /proc/*/fd 找 inode 对应 PID, 这在一个高负载的网关上...不可想象

[RPRX]

ss -tulnp 会不会快一些，不过只有 PID 和进程名，如果有人填了绝对路径/文件夹的话，看看能不能让它显示完整路径

[Fangliding]

Linux下每次匹配会读 /proc/net/tcp*|udp* 并遍历 /proc/*/fd 找 inode 对应 PID, 这在一个高负载的网关上...不可想象

我试过用netlink 只是不知道为什么它会让延迟飙升到5ms 至于占用暂时没看过 所以我说还得再看看

[majorcheng]

Linux下每次匹配会读 /proc/net/tcp*|udp* 并遍历 /proc/*/fd 找 inode 对应 PID, 这在一个高负载的网关上...不可想象

我试过用netlink 只是不知道为什么它会让延迟飙升到5ms 至于占用暂时没看过 所以我说还得再看看

其实，linux下为啥要有匹配process的功能...如果是作为网关，匹配自身process的功能没啥必要（多的是iptables mark/uid之类的手段）， 作为桌面， 都用linux了，系统策略路由啥的还不随便搞。
总不会是奢望去匹配客户机上的process吧[狗头]
最大的用处应该是在安卓？ 如果是安卓就不用考虑着几个ms的性能了，没多少进程也不会做高负载网关.

[Fangliding]

首先作为一个网关（路由器） 它大概率是用不上这个功能的
这里考虑的是作为桌面端软件的时候 能用 进程名/路径 在ray内部路由还是比较方便 那堆ipt操作太麻烦而且Windows有Linux没总会有人喊的
不过就我个人而言估计都不会用(

[majorcheng]

首先作为一个网关（路由器） 它大概率是用不上这个功能的 这里考虑的是作为桌面端软件的时候 能用 进程名/路径 在ray内部路由还是比较方便 那堆ipt操作太麻烦而且Windows有Linux没总会有人喊的 不过就我个人而言估计都不会用(
作为linux桌面，那不也得先系统上用tproxy之类的把流量导到xray？ 哦，走tun做默认网关也OK

[RPRX]

可以合了吗

[Fangliding]

跟7楼说的那样 这样暴力遍历很丑
但是netlink也没好到哪去甚至略微不如暴力版本 还是没想好怎么搞好(

[RPRX]

测一下 Windows 有没有问题，没问题就先合了

Linux 桌面有几个人用，我根本就不用，谁用谁优化吧

[Fangliding]

用的话两个系统都试了 没啥问题
目前是这样
无斜杠视作进程名
xray/视为匹配xray自己
有斜杠且斜杠结尾视作文件夹匹配
有斜杠且不以斜杠结尾视作绝对路径匹配
Windows也必须使用正斜杠否则不工作

[RPRX]

xray/ 需要改成 self/ 并且通过 PID 来判断是否是当前进程，不能 path 一样就视为自己

[Fangliding]

口胡了 是 self/ 视作自己
还有Windows可以填反斜杠 但是和之前说的一样必须双写（json限制） 会正常转换

[RPRX]

两个都要吧

self/ 匹配自身 PID
xray/ 匹配自身 path，加一下

[Fangliding]

匹配自身path意义在哪 pid不是够精确了吗

[RPRX]

一个 Xray 开两个进程，path 就是一样的

[RPRX]

这个 PR 优先级更高