github-starred/frp

Fork 0

mirror of https://github.com/fatedier/frp.git synced 2026-05-15 16:15:49 -06:00

[GH-ISSUE #1839] frps 启动时是否可以一并启动配置文件中声明使用的插件 #1452

New issue

Open

opened 2026-05-05 12:55:09 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 12:55:09 -06:00

Owner

Originally created by @deadlineOvO on GitHub (Jun 3, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/1839

就像上面说的那样
这个想法的一部分受到 shadowsocks SIP003 的启发

另一部分是对于 frps 可能没有在文档说明的问题：如果 frps 启动时插件的进程没有启动会出现什么意外？只是插件不会生效吗？

Originally created by @deadlineOvO on GitHub (Jun 3, 2020). Original GitHub issue: https://github.com/fatedier/frp/issues/1839 就像上面说的那样这个想法的一部分受到 shadowsocks SIP003 的启发另一部分是对于 frps 可能没有在文档说明的问题：如果 frps 启动时插件的进程没有启动会出现什么意外？只是插件不会生效吗？

gitea-mirror added the

todo

label 2026-05-05 12:55:09 -06:00

gitea-mirror commented

2026-05-05 12:55:11 -06:00

Author

Owner

@fatedier commented on GitHub (Jun 4, 2020):

目前是通过向插件发送 RPC 请求来执行插件的逻辑，插件没有启动，则请求失败，会导致拒绝执行原来的操作。这个方面你提醒我了，感觉有一些插件可能可以容忍错误，可以考虑在插件配置中增加一个参数来决定当出现错误时是否可以忽略，继续执行。
由 frps 负责启动插件可以考虑作为一个可选项。关于插件这个方向的后续发展，是计划考虑使用 WASM 来支持，这样不会有 RPC 请求的性能和效率、稳定性等问题，只是这一块 Go 的支持还不成熟，会继续跟进。

@fatedier commented on GitHub (Jun 4, 2020): 1. 目前是通过向插件发送 RPC 请求来执行插件的逻辑，插件没有启动，则请求失败，会导致拒绝执行原来的操作。这个方面你提醒我了，感觉有一些插件可能可以容忍错误，可以考虑在插件配置中增加一个参数来决定当出现错误时是否可以忽略，继续执行。 2. 由 frps 负责启动插件可以考虑作为一个可选项。关于插件这个方向的后续发展，是计划考虑使用 WASM 来支持，这样不会有 RPC 请求的性能和效率、稳定性等问题，只是这一块 Go 的支持还不成熟，会继续跟进。

gitea-mirror commented

2026-05-05 12:55:12 -06:00

Author

Owner

@deadlineOvO commented on GitHub (Jun 4, 2020):

目前是通过向插件发送 RPC 请求来执行插件的逻辑，插件没有启动，则请求失败，会导致拒绝执行原来的操作。这个方面你提醒我了，感觉有一些插件可能可以容忍错误，可以考虑在插件配置中增加一个参数来决定当出现错误时是否可以忽略，继续执行。

由 frps 负责启动插件可以考虑作为一个可选项。关于插件这个方向的后续发展，是计划考虑使用 WASM 来支持，这样不会有 RPC 请求的性能和效率、稳定性等问题，只是这一块 Go 的支持还不成熟，会继续跟进。

所以插件应当在 frps 前启动还是相反？

@deadlineOvO commented on GitHub (Jun 4, 2020): > 1. 目前是通过向插件发送 RPC 请求来执行插件的逻辑，插件没有启动，则请求失败，会导致拒绝执行原来的操作。这个方面你提醒我了，感觉有一些插件可能可以容忍错误，可以考虑在插件配置中增加一个参数来决定当出现错误时是否可以忽略，继续执行。 > 2. 由 frps 负责启动插件可以考虑作为一个可选项。关于插件这个方向的后续发展，是计划考虑使用 WASM 来支持，这样不会有 RPC 请求的性能和效率、稳定性等问题，只是这一块 Go 的支持还不成熟，会继续跟进。所以插件应当在 frps 前启动还是相反？

gitea-mirror commented

2026-05-05 12:55:13 -06:00

Author

Owner

@fatedier commented on GitHub (Jun 4, 2020):

上面已经说得比较清楚了，可以自行测试一下具体的逻辑。

@fatedier commented on GitHub (Jun 4, 2020): 上面已经说得比较清楚了，可以自行测试一下具体的逻辑。

gitea-mirror commented

2026-05-05 12:55:14 -06:00

Author

Owner

@deadlineOvO commented on GitHub (Jun 4, 2020):

上面已经说得比较清楚了，可以自行测试一下具体的逻辑。

好的

@deadlineOvO commented on GitHub (Jun 4, 2020): > 上面已经说得比较清楚了，可以自行测试一下具体的逻辑。好的

gitea-mirror commented

2026-05-05 12:55:16 -06:00

Author

Owner

@deadlineOvO commented on GitHub (Jun 6, 2020):

由 frps 负责启动插件可以考虑作为一个可选项。关于插件这个方向的后续发展，是计划考虑使用 WASM 来支持，这样不会有 RPC 请求的性能和效率、稳定性等问题，只是这一块 Go 的支持还不成熟，会继续跟进。

这个怎么样？

@deadlineOvO commented on GitHub (Jun 6, 2020): > 2. 由 frps 负责启动插件可以考虑作为一个可选项。关于插件这个方向的后续发展，是计划考虑使用 WASM 来支持，这样不会有 RPC 请求的性能和效率、稳定性等问题，只是这一块 Go 的支持还不成熟，会继续跟进。 [这个](https://varlink.org) 怎么样？

gitea-mirror commented

2026-05-05 12:55:17 -06:00

Author

Owner

@fatedier commented on GitHub (Jun 7, 2020):

It's no essential difference with HTTP or GRPC and not widely used.

@fatedier commented on GitHub (Jun 7, 2020): It's no essential difference with HTTP or GRPC and not widely used.

gitea-mirror commented

2026-05-05 12:55:17 -06:00

Author

Owner

@deadlineOvO commented on GitHub (Jun 7, 2020):