Hi, As this patch set is not getting any attention, I guess the need for this is not clear enough from the commit messages. To be blunt, --management-query-remote is pretty useless the way it stands. Let me explain:
(1) It queries the user with one remote at a time taking about 1 second per query. With 100 remotes, if the user wants to select the 100th one, a UI has to show 100 popups and take ~100 seconds. So one wants two things in good UI (i) show a list of all available remotes to the user (ii) have a way to jump to a remote that user chooses For (i) one could scan the config and make a list but I'll come to why that doesn't work in a minute. Consider (ii) first: we currently have an option to skip remotes one by one or send a MOD request where the host and port can be changed. Skipping one by one is very slow, and MOD doesn't allow change of protocol. So, if the 100th item that user chooses is TCP and all other 99 are UDP, we have to wait until we get prompted with the right one. There are other reasons why MOD doesn't work but I want to keep this mail simple. Thus, we want a way to skip "N" remotes by one command (say skip 99, get prompted with the 100th which we accept). One of the three patches in this set does that. Now back to (i) about making a list. For "SKIP N" to work, the UI and the core must have an identical view of the list -- especially the order of entries. If remote-random is in use, the only way to assure that is by making the list by querying the core. Even otherwise independently parsing the list from the config is not the right approach when identity of content is important. This, hopefully, justifies the patch that allows the UI to query the core for a list of remotes and their indices. The third patch is to relax the restriction on the number of remote entries and connection lists. Currently it's hard coded to 64, there is no reason why we can't allow 100 or even 1000 remote entries. >From experience, I know that patches that languish stay like that for months if not years. Please, either review and ACK or hate it at first sight and NAK. Or ask for clarification. A patch for the GUI is waiting for the fate of this. Thanks, Selva On Tue, Sep 7, 2021 at 6:27 PM Selva Nair <selva.n...@gmail.com> wrote: > Hi, > > While implementing this feature in the GUI, I have come across some > limitations of management-query-remote: > > (i) Using a remote selected by the user from a list requires skipping > several remotes and accepting when the right one is reached. This is very > slow when there are more than a dozen remote entries: about ~1 second per > command. > > Solution: Extend "remote SKIP" to take an optional parameter to skip "n" > entries by one command. > > Use of "remote MOD" is not useful here as it does not support change of > protocol. It also has some "misbehaviour" due to the way resolved addresses > are cached. > > (ii) remote-entry-get introduced here needs to be extended to support > requesting multiple or all remote entries in one command. > > Please ignore the current version. v3 is coming. > > Selva >
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
