mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #3558] [Feature Request] xtcp 失败切换为 stcp 协议后是否可自动复用 xtcp 配置生成 stcp 协议 #2836
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#2836
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xingdaos on GitHub (Jul 30, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3558
Describe the feature request
需求描述
目前 xtcp 协议已支持 fallback_to 参数，可以自动回落至指定的 stcp 协议，
但是这样的话需要同时配置一个 xtcp 和 一个 stcp 协议才行，
可否当 xtcp 协议连接失败时，软件自动复用 xtcp 协议，生成 stcp 协议进行自动切换，配置更为简洁友好。
目前行为
走 xtcp 协议指定 fallback_to 参数后，frpc 需要同时配置 xtcp 和 stcp 两个协议，才能在 xtcp 连接失败后自动回落至指定的 stcp 协议
预期行为
走 xtcp 协议指定 fallback_to 参数后（或新增一个 auto_to_stcp 参数），frpc 只单独配置一个 xtcp 协议，当连接失败时，软件自动复用 xtcp 的配置信息，切换为 stcp 协议
Describe alternatives you've considered
No response
Affected area
@fatedier commented on GitHub (Jul 31, 2023):
目前的基础配置里不会这样做，保持逻辑简化和可扩展，但是如果有一个配置生成的工具或服务，在那个上面可以做类似的简化。
@xingdaos commented on GitHub (Aug 2, 2023):
那做一个备选项呢，和 fallback_to 参数不冲突，不影响其扩展性，
比如加一个保留参数【fallback_to = self】的时候才会自动切换协议，
或者新增一个参数【auto_stcp = true】时才切换，这样配置文件更简洁一些，也更好维护一些，
@fatedier commented on GitHub (Aug 2, 2023):
fallback 机制未来可能不限于 stcp，所以
auto_stcp会是一个特别定制的配置，不够优雅。fallback_to 的目标是 visitor，
fallback_to = self会是一个 special case，加入这种逻辑会使后续维护增加成本，也更容易引入 bug。目前暴露的可以理解为基础配置/通用配置，不会为了便于配置而去做太多的语法糖，这种逻辑长期来看会带来的负担大于价值。也许未来可以提供另外一套更灵活和简化的配置，或者你可以直接创建一个配置转换工具来实现类似的功能，但目前不会出现在这个项目里。你可以简单理解成类似 nginx 的配置本身是复杂的，但是可以灵活组合实现非常多的能力，但是如果为了特定的场景，为每个场景增加一堆配置，那对项目维护来说将会是一个灾难，相反，会出现其他的工具/UI 帮助你去配置。
配置文件可以理解为暴露给用户的 API，需要保持一定的兼容性，稳定性，为了项目长期的发展，不会仅仅为了个别场景的简化而增加太多非必需的参数，除非没有这个参数，相关的能力就无法实现。
@xingdaos commented on GitHub (Aug 2, 2023):
好的，理解，同时感谢你提供出如此优秀的软件。