[GH-ISSUE #1378] Support for persistent reservations #1093

Closed
opened 2026-05-05 12:42:14 -06:00 by gitea-mirror · 15 comments
Owner

Originally created by @lukacu on GitHub (Aug 12, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1378

Hi, is there any interest in supporting persistent port reservations (so that a proxy is assigned the same port even if the server is restarted)? I am willing to implement it myself because we need it in our usage scenario, I am just asking if I should also create a PR to the main repo?

Originally created by @lukacu on GitHub (Aug 12, 2019). Original GitHub issue: https://github.com/fatedier/frp/issues/1378 Hi, is there any interest in supporting persistent port reservations (so that a proxy is assigned the same port even if the server is restarted)? I am willing to implement it myself because we need it in our usage scenario, I am just asking if I should also create a PR to the main repo?
gitea-mirror 2026-05-05 12:42:14 -06:00
Author
Owner

@fatedier commented on GitHub (Aug 13, 2019):

How do you want to do that? Save in db or local file?

I prefer not import much complexity and consider do these things as a plugin feature.

We can design some interface exported to plugins. Like RequestNewPort or CheckAuthentication support GRPC or just HTTP protocol.

In frps.ini, it may be:

port_manager_interface: grpc://127.0.0.1:8080
authentication_interface: http://127.0.0.1:8081

frps will send grpc request to 127.0.0.1:8080 and get the result to assign a port.

<!-- gh-comment-id:520671336 --> @fatedier commented on GitHub (Aug 13, 2019): How do you want to do that? Save in db or local file? I prefer not import much complexity and consider do these things as a plugin feature. We can design some interface exported to plugins. Like `RequestNewPort` or `CheckAuthentication` support GRPC or just HTTP protocol. In frps.ini, it may be: ```ini port_manager_interface: grpc://127.0.0.1:8080 authentication_interface: http://127.0.0.1:8081 ``` frps will send grpc request to `127.0.0.1:8080` and get the result to assign a port.
Author
Owner

@lukacu commented on GitHub (Aug 13, 2019):

Well, my idea was simply to use a local file, but I do not mind the plugin version, although I am not sure if the current plugin architecture allows this (plugins are currently used on client?). The RPC solution sounds very complicated, for my use case a plugin that would save reservations to a file would be enough.

<!-- gh-comment-id:520767597 --> @lukacu commented on GitHub (Aug 13, 2019): Well, my idea was simply to use a local file, but I do not mind the plugin version, although I am not sure if the current plugin architecture allows this (plugins are currently used on client?). The RPC solution sounds very complicated, for my use case a plugin that would save reservations to a file would be enough.
Author
Owner

@fatedier commented on GitHub (Aug 13, 2019):

Plugins i mentioned above is not the plugins used in client, it can be a long running processor.

I want to see that every one can write plugins for different scenario and share with others to expand the usage of frp.
Users can download plugins they need or just run single frp server without plugins.

I will take the time to do the design for Manager Plugin. After that, maybe you can provide a plugin called PortManager.

<!-- gh-comment-id:520908074 --> @fatedier commented on GitHub (Aug 13, 2019): Plugins i mentioned above is not the `plugins used in client`, it can be a long running processor. I want to see that every one can write plugins for different scenario and share with others to expand the usage of frp. Users can download plugins they need or just run single frp server without plugins. I will take the time to do the design for `Manager Plugin`. After that, maybe you can provide a plugin called `PortManager`.
Author
Owner

@lukacu commented on GitHub (Aug 13, 2019):

Yes, indeed. That would be very cool, but I guess it will require some work. Also, the current plugin architecture does not seem to use dynamic libraries as it is usually the case with plugins. You have to compile the entire executable which then makes plugins a bit redundant. From what I have seen, Go supports plugins, but only on Linux and Mac at the moment.

I will then wait for a plugin architecture and then write my use case as a plugin.

<!-- gh-comment-id:520950938 --> @lukacu commented on GitHub (Aug 13, 2019): Yes, indeed. That would be very cool, but I guess it will require some work. Also, the current plugin architecture does not seem to use dynamic libraries as it is usually the case with plugins. You have to compile the entire executable which then makes plugins a bit redundant. From what I have seen, [Go supports plugins](https://golang.org/pkg/plugin/), but only on Linux and Mac at the moment. I will then wait for a plugin architecture and then write my use case as a plugin.
Author
Owner

@fatedier commented on GitHub (Aug 14, 2019):

What we need is not the dynamic libraries. I think RPC is good enough. You can write extension feature on any os with any language not only in golang. This is important.

<!-- gh-comment-id:521082828 --> @fatedier commented on GitHub (Aug 14, 2019): What we need is not the dynamic libraries. I think RPC is good enough. You can write extension feature on any os with any language not only in golang. This is important.
Author
Owner

@lukacu commented on GitHub (Aug 14, 2019):

Ok, fine, although this will eventually make the system more complex. The port manager case will work well in such a way, I am less sure about some more data-intensive use-cases. Then I am awaiting you implementation so that I can implement persistence.

<!-- gh-comment-id:521230527 --> @lukacu commented on GitHub (Aug 14, 2019): Ok, fine, although this will eventually make the system more complex. The port manager case will work well in such a way, I am less sure about some more data-intensive use-cases. Then I am awaiting you implementation so that I can implement persistence.
Author
Owner

@lukacu commented on GitHub (Nov 29, 2019):

Hey, so I do not want to bother you too much, but are there some plans to implement a general server plugin API? I now have at least two use-cases for this :) Is it possible that you at least draft your idea in a comment and then somebody can try and implement it? I really do not want to fork the code just to add some quick and dirty hacks.

<!-- gh-comment-id:559721920 --> @lukacu commented on GitHub (Nov 29, 2019): Hey, so I do not want to bother you too much, but are there some plans to implement a general server plugin API? I now have at least two use-cases for this :) Is it possible that you at least draft your idea in a comment and then somebody can try and implement it? I really do not want to fork the code just to add some quick and dirty hacks.
Author
Owner

@fatedier commented on GitHub (Nov 29, 2019):

Sorry. I am busy at work at present. I will try to draft a design doc next month.

<!-- gh-comment-id:559736399 --> @fatedier commented on GitHub (Nov 29, 2019): Sorry. I am busy at work at present. I will try to draft a design doc next month.
Author
Owner

@fatedier commented on GitHub (Dec 2, 2019):

I write the design doc here #1403
You can read it and make sure if it can meet your need.

<!-- gh-comment-id:560307357 --> @fatedier commented on GitHub (Dec 2, 2019): I write the design doc here #1403 You can read it and make sure if it can meet your need.
Author
Owner

@lukacu commented on GitHub (Dec 2, 2019):

Great, thanks. It is suitable for the use case in this issue, but my other use case would need support for generating a file from a template for the entire list of proxies (this is how I could easily add Let's encrypt support using Traefik). I assume that this can be added using additional plugin operations? I do not want to go too off-topic here, so I can open another issue for that once some work on the API is implemented to some degree.

<!-- gh-comment-id:560336039 --> @lukacu commented on GitHub (Dec 2, 2019): Great, thanks. It is suitable for the use case in this issue, but my other use case would need support for generating a file from a template for the entire list of proxies (this is how I could easily add Let's encrypt support using Traefik). I assume that this can be added using additional plugin operations? I do not want to go too off-topic here, so I can open another issue for that once some work on the API is implemented to some degree.
Author
Owner

@fatedier commented on GitHub (Dec 2, 2019):

I'm not clear at your second use case. You can open another issue to describe it in detail.

If you write the persistent reservations plugin, you can share it in https://github.com/gofrp/plugin .

<!-- gh-comment-id:560360748 --> @fatedier commented on GitHub (Dec 2, 2019): I'm not clear at your second use case. You can open another issue to describe it in detail. If you write the persistent reservations plugin, you can share it in https://github.com/gofrp/plugin .
Author
Owner

@fatedier commented on GitHub (Jan 5, 2020):

@lukacu v0.31.0 is released and it support server manage plugin.

<!-- gh-comment-id:570853979 --> @fatedier commented on GitHub (Jan 5, 2020): @lukacu v0.31.0 is released and it support server manage plugin.
Author
Owner

@lukacu commented on GitHub (Jan 6, 2020):

Excellent, I will try it out. Thanks!

<!-- gh-comment-id:571081982 --> @lukacu commented on GitHub (Jan 6, 2020): Excellent, I will try it out. Thanks!
Author
Owner

@lukacu commented on GitHub (Mar 27, 2020):

Just to let you know that I have implemented a persistent reservation plugin in my dockerized version of FRP server. The other plugin that I was talking about is also there. It is a Let's Encrypt proxy that enables TLS for plain HTTP clients. I hope that it could someday be implemented directly in FRP core because it is kind of hacky.

<!-- gh-comment-id:605318962 --> @lukacu commented on GitHub (Mar 27, 2020): Just to let you know that I have implemented a persistent reservation plugin in my [dockerized version of FRP server](https://github.com/lukacu/docker-frps). The other plugin that I was talking about is also there. It is a Let's Encrypt proxy that enables TLS for plain HTTP clients. I hope that it could someday be implemented directly in FRP core because it is kind of hacky.
Author
Owner

@fatedier commented on GitHub (Mar 28, 2020):

@lukacu Great! I will add a link on https://github.com/gofrp/plugin .

ACMEProxy maybe could include in frp core. I will take time to consider it.

<!-- gh-comment-id:605439636 --> @fatedier commented on GitHub (Mar 28, 2020): @lukacu Great! I will add a link on https://github.com/gofrp/plugin . ACMEProxy maybe could include in frp core. I will take time to consider it.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#1093
No description provided.