• Chttp / Connectremote() / fail.. randomly

    From Sherlock@21:1/5 to All on Mon Sep 20 18:07:40 2021
    oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
    //
    IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
    // Do stuff.

    Randomly at first this will return false.. same box the IP.
    Can ping to the IP.. it is there.
    Some other flags to pass or some other way to test.

    When I try and process again the connection continues to fail until I stop and start my VO service.

    Any ideas... things to try...

    Phil McGuinness

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Massimo Bighelli@21:1/5 to All on Tue Sep 21 15:35:51 2021
    can you set a timeout in your connectremote ?


    Massimo Bighelli
    ARCA Sistemi S.r.l.


    Il 21/09/2021 03:07, Sherlock ha scritto:
    oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
    //
    IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
    // Do stuff.

    Randomly at first this will return false.. same box the IP.
    Can ping to the IP.. it is there.
    Some other flags to pass or some other way to test.

    When I try and process again the connection continues to fail until I stop and start my VO service.

    Any ideas... things to try...

    Phil McGuinness


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil McGuinness@21:1/5 to All on Tue Sep 21 09:46:55 2021
    Massimo

    no Timeout in this class.

    oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }

    oHttp:Timeout := 6000 // Syntax like this not part of class

    //
    IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
    // Do stuff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil McGuinness@21:1/5 to All on Sun Oct 3 21:36:39 2021
    Based VO cHTTP class issue solved with a move to winHTTP
    I call this code and a lot of it via a VO app running as service for like 15 years.
    No reliable now and random.
    The service has to be stopped and started and wait for the random inability to ConnectRemote()

    interesting a Socket call prior to same port etc... works.
    The cHTTP connect fails.

    Phil McGuinness
    ----

    oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
    oHttp:Timeout := 6000 // Syntax like this not part of class
    //
    IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
    // Do stuff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wolfgang Riedmann@21:1/5 to Phil McGuinness on Mon Oct 4 13:43:39 2021
    Hi Phil,

    the VO cHTTP class is based on WinInet - this is practically the
    communication layer of the Internet Explorer.

    It could be that now that Internet Explorer is being dismissed also the
    WinInet library has some not fixed problems.

    Wolfgang

    Phil McGuinness wrote:

    Based VO cHTTP class issue solved with a move to winHTTP
    I call this code and a lot of it via a VO app running as service for
    like 15 years. No reliable now and random.
    The service has to be stopped and started and wait for the random
    inability to ConnectRemote()

    interesting a Socket call prior to same port etc... works.
    The cHTTP connect fails.

    Phil McGuinness
    ----

    oHttp := CHttp{"Secure_Rates", INTERNET_DEFAULT_HTTPS_PORT }
    oHttp:Timeout := 6000 // Syntax like this not part of class
    //
    IF oHttp:ConnectRemote( WEBSERVER_2016 ) // "27.50.65.xxx"
    // Do stuff



    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phil McGuinness@21:1/5 to All on Tue Oct 5 01:43:35 2021
    snip[ the VO cHTTP class is based on WinInet - this is practically the communication layer of the Internet Explorer. It could be that now that Internet Explorer is being dismissed also the
    WinInet library has some not fixed problems. Wolfgang ]

    I suspect app running as service has a throttle limit if exceeded the connect via cHTTP is deactivated for the session the service is running.
    Restart all good until some threshhold reached again. Sure with Internet Explorer. It only fails as service. For all other works fine, so far.

    Re winHTTP in most places in my Service replaced cHTTP and working great. First time in a month this random issue.
    Another part bit more complex but day or so will be replaced. I can still see it fails on cHTTP but my most critical does not anymore.
    Will release a Function you can use for most anything for those do not want to learn the inner workings.
    I have a HttpCall() function a wrapper and will release winHttpCall().

    Simple to drive, black box for those that just want something that works.

    Phil McGuinnness

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wolfgang Riedmann@21:1/5 to Phil McGuinness on Thu Oct 7 18:20:36 2021
    Hi Phil,

    the main issue why I wrote the winHttp class is that WinInet is not
    supported in Windows services, and I needed that:

    https://docs.microsoft.com/en-us/troubleshoot/browsers/wininet-not-suppo rted-in-services

    Wolfgang

    Phil McGuinness wrote:

    snip[ the VO cHTTP class is based on WinInet - this is practically
    the communication layer of the Internet Explorer. It could be that
    now that Internet Explorer is being dismissed also the WinInet
    library has some not fixed problems. Wolfgang ]

    I suspect app running as service has a throttle limit if exceeded
    the connect via cHTTP is deactivated for the session the service is
    running. Restart all good until some threshhold reached again. Sure
    with Internet Explorer. It only fails as service. For all other
    works fine, so far.

    Re winHTTP in most places in my Service replaced cHTTP and working
    great. First time in a month this random issue. Another part bit
    more complex but day or so will be replaced. I can still see it fails
    on cHTTP but my most critical does not anymore. Will release a
    Function you can use for most anything for those do not want to learn
    the inner workings. I have a HttpCall() function a wrapper and will
    release winHttpCall().

    Simple to drive, black box for those that just want something that
    works.

    Phil McGuinnness




    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sherlock@21:1/5 to All on Sat Oct 9 19:39:09 2021
    Wolfgang Riedmann

    snip[ the main issue why I wrote the winHttp class is that WinInet is not > supported in Windows services, and I needed that: ]

    Bugger it did for 15+ years.......... but a way forward. Your class a bit more, samples and good tutorial site for programmers.

    http://www.sherlock.com.au/sherlock32/Test_winHTTPCall.zip

    Hope others get good use out of this code.. we used it extensively. use the class use the function, it all works.

    Phil McGuinness

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Wolfgang Riedmann@21:1/5 to All on Sun Oct 10 16:40:20 2021
    Hi Phil,

    snip[ the main issue why I wrote the winHttp class is that WinInet is
    not > supported in Windows services, and I needed that: ]

    Bugger it did for 15+ years.......... but a way forward.

    I had used it too, but since I had some strange issues I have
    researched and found that link. Since I have changed the services no
    more issues.

    And in most GUI applications I have also started to use winHttp.

    Wolfgang


    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)