Hi, On Wed, Sep 22, 2021 at 12:55 PM Gert Doering <g...@greenie.muc.de> wrote:
> Hi, > > On Wed, Sep 22, 2021 at 06:22:15PM +0200, Bo Berglund wrote: > > - send a silent_connection 1 command > > - Wait a while for the command to be executed > > - then send the actual connection command > > - Wait until we have a connection > > @selva: how complicated would it be to create a "hey, gui, please make > this call *blocking* until all pending VPN client connections are > established (or have given up)" command? > We do use SendMessage() which blocks until the receiver has "processed" the message (up to 30 seconds). But the meaning of "processing" is vague. Currently, it means the receiver has parsed it and issued a command to its message queue. Nothing is done immediately in a GUI -- for connect, it will spawn openvpn and yield. At some point management i/f will trigger a read and after many such events a connection is established. If the GUI were to send a message back to the sender at that point we have to decide what those critical events are -- connection established, disconnected, reconnected or something else? The receiver has no idea at what point the sender wants a message. Also we do not have a method for receiving messages from the running instance. Even if we were to add it, it's still hard to define the meaning of completion of a command. More natural way would be for the sender to periodically check the state of a connection. Which also requires the ability for the GUI to send back messages. As the sender has no Window initialized, that will have to use some other IPC mechanism than messages. Is it worth the trouble? Isn't this use case arising from wanting to use the GUI for something that it's not? Selva
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
