[Feature Request] Allow multiple transports/ports on frpc (in order of preference?)

fatedier / frp

A fast reverse proxy to help you expose a local server behind a NAT or firewall to the internet.

Apache License 2.0

85.32k stars 13.23k forks source link

[Feature Request] Allow multiple transports/ports on frpc (in order of preference?) #3909

Open gdevenyi opened 9 months ago

gdevenyi commented 9 months ago

Describe the feature request

In frps we can specify ports for tcp, kcp and quic, however in frpc.toml we only get to specify a single transport.protocol and serverPort.

It would be nice to be able to specify a comma-separated order of preferred protocols (and corresponding serverPort), that frpc would attempt.

Justification for this is the frpc that UDP protocols may be preferred, however firewalls may not always allow UDP, so a tcp fallback configuration would be nice.

Describe alternatives you've considered

Running multiple frpc daemons with different configs.

Affected area

[ ] Docs
[ ] Installation
[ ] Performance and Scalability
[ ] Security
[X] User Experience
[ ] Test and Release
[ ] Developer Infrastructure
[ ] Client Plugin
[ ] Server Plugin
[ ] Extensions
[ ] Others

fatedier commented 9 months ago

I did not expect a specific scenario that requires this feature.

Consider some potential issues:

Will it affect the retry interval? After the server restarts or network fluctuations, it may take longer to recover.
If we support configuring multiple server addresses in the future, combined with various retry strategies, it could become very complex.

Currently it is not very clear, more thinking is needed.

gdevenyi commented 9 months ago

Will it affect the retry interval? After the server restarts or network fluctuations, it may take longer to recover.

I would imagine that retry would start at the top and go through order of preference, it would use the retry interval, the user would be responsible for adjusting the interval to handle this.

If we support configuring multiple server addresses in the future, combined with various retry strategies, it could become very complex.

For me, if there were multiple server addresses, I would just consider it as nested orders of preference, first server, iterate through connection types, then second server, iterate through. As long as its explicitly documented what its going to do the config isn't too complex.

paolosezart commented 9 months ago

It would also be nice to be able to connect to alternative frp servers. For example, if one server goes down. All clients connect to one of the alternative FRPS.

gdevenyi commented 9 months ago

It would also be nice to be able to connect to alternative frp servers. For example, if one server goes down. All clients connect to one of the alternative FRPS.

Seems that was already planned, see https://github.com/fatedier/frp/issues/3909#issuecomment-1876252394 above

paolosezart commented 9 months ago

Seems that was already planned

Thank you very much for your quick response to requests. You are the best!

paolosezart commented 9 months ago

I apologize for my importunity. Is it possible to implement the principle of not switching to an alternative server, but a permanent connection to all available servers? In this case, there is no need to think about priorities. Each client, when connected and during operation, will poll all available servers and receive information about available ports.