Go to goldenfrog.com

Please tell us your feature request....

Allow VyprVPN service to selectively start / start at app start

Crosspost from:
http://forum.goldenfrog.com/t/vyprvpnservice-exe-constantly-running/1247/8
"vyprVPNservice.exe constantly running"

Crossposted here at request of Golden Frog.

@keegan

Thanks for the update! I had also noticed this behavior and figured that something like the reasons you enumerated were the cause of it.

Suggestion:
This is especially important on potentially memory-starved systems where the user may wish to use VyprVPN, but cannot afford to have it running full-time, or on the Android version where memory and processor cycles are very likely to be at a premium:

* Create separate option items for "Start Application and start Service on startup, where "Start Application on startup" would automatically enable service start too.

* Add the behavior that, if both "Start application" and "Start service" at startup are not selected, when the application quits that all subordinate processes are killed as well.
** Alternately, there could be an option " 'Quit' also kills background services" that would be enabled if neither of the previous options are selected. (i.e. This option would be greyed-out if either of the two prior options get selected.)

* Add the behavior that, if the service is not running at application startup, that the service gets started silently. (This would also solve the "Cannot Contact Service" issues everyone is reporting!) An exception (error) would only get thrown if the service could not be started within a reasonable amount of time, or after "X" number of attempts.

The justifications for these actions are thus:

* If the user does not want the app to run at startup, he probably has a good reason for not wanting it to run at all. (i.e. He's on a trusted network, etc.) Forcing the user to specifically hunt-down and kill the service, if not selected at startup, is just pissy and annoying.

* If the user wants the service to run at startup, it can be selected. It can even be selected as the default setting during installation.

* In memory starved environments, or operating systems that are just pigs, (make that read "Windows 8"), leaving the service running can impact system performance.

* Android systems, especially on phones, are often memory and processor cycle starved. Leaving potentially unnecessary services running can have a seriously negative impact on performance, causing the user to ultimately un-install the app to avoid the performance crunch.

Thanks again for an excellent application, and I hope that these suggestions will receive expedited consideration.

Jim (JR)

51 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Jim shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    6 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        I am also considering unsubscribing from this service due to this CPU issue. It makes me rather unconfortable that the service is doing constant 2-3% CPU work when no VPN is connected. The list of "work" done in the background is not sufficient to warrant even 1% constant CPU and is not acceptable for an idle background service! Smells fishy.

      • Daniel Johnson commented  ·   ·  Flag as inappropriate

        I have it installed in all of my hardware. I do not use all of my hardware constantly to connect to VPN. Why must I take a constant 1% CPU usage hit for the service when the APP is not running?

      • Hennie commented  ·   ·  Flag as inappropriate

        I strongly agree with this. I only need VyprVPN occasionally and I do not want it to be running in the background constantly taking up more CPU power than any other process.
        I did see the solution above about manually switching off/on the process but that is far from user friendly, having to remember to start a process manually before I can use VyprVPN.

        The solution is so easy:
        1) Have an option so that VyprVPN starts nothing at all.
        2) Simply start all processes automatically that you need when the user starts VyprVPN.

      • Jim commented  ·   ·  Flag as inappropriate

        Update:

        An additional justification:
        * The user may need to run other VPN clients

        In the course of my work, I have opportunities to access client sites where the data may be sensitive, regulated, or restricted somehow. In these cases the client usually provides his own VPN software package, by whomever, that I use to access their site. Some of these packages may, or may not, also start persistent background service processes as well.

        What say ye?

        Jim (JR)

      • Jim commented  ·   ·  Flag as inappropriate

        Update:

        An additional justification:

        * The user may need to use ***other*** VPN services/clients too.

        In my case I have clients that have "sensitive data" about their clients that may be regulated, or protected, by law. In these cases I am (usually) given a client supplied VPN application that I use when accessing their networks. These VPN packages may, or may not, have persistent background services running.

        Jim (JR)

      • Jim commented  ·   ·  Flag as inappropriate

        Update:

        Another justification for allowing the VyprVPN service to be started selectively, (and killed selectively as well), is the fact that some users - myself among them - ***may need to use more than one VPN package*** depending on what they are doing.

        I have clients that due to the sensitiveness of their data, require me to use client-provided VPN software which may, or may not, run a persistent service.

        IMHO, running more than one service that's trying to do the same thing at the same time is a recipe for disaster.

        What say ye?

        Jim (JR)

      Feedback and Knowledge Base