My tablet app has been deployed to the field for a couple of years very successfully. Tablets accompany delivery trucks and connect to services via Verizon Mobile data services. We wrote the Windows Service as well using Visual Studio.
Suddenly one day it quit working. Turns out our DNS server was blocking queries from Verizon. Once we fixed that then tablets could determine our IP from the server's full domain name.
Currently where I am using HTTPUTILS2 version 2.50 and HTTP version 1.36 is that connections from the tablet by IP address, and not name, connect to our service just fine. This is an emergency work around mode because connections are not secure. Our server won't promote incoming connections unless they are on port 8080 or 8082. But by IP address to port 8081 works perfectly. And correctly interacts with web services fine.
Yes, my service listens on 3 ports, 8080, 8081, and 8082. For 8080 and 8082 it will promote the incoming connection to SSL. For 8081 it works without encryption and does not even attempt SSL promotion.
When I start a "job" to "https://servername.domain.com:8080/OurServices" I don't even see a tap at the door in my service. I don't see a tap at the door from our firewall. Nothing. When we work from Visual Studio we 1) Make an IP connection, 2) Promote it to SSL (starts the handshake).
COULD IT BE, that HTTPUTILS2 or ANDROID does not work this way? What I am asking you, is if it will do the SSL handshake FIRST before attempting connection? If this is true, and the SSL handshake fails, then we may never see anyone tapping at the door at our service. But to understand and diagnose this if someone can authoritatively answer; in the way I am using this, could these symptoms indicate SSL handshake failure?
What I see in the LOGS at ANDROID is the connection is timing out.
Suddenly one day it quit working. Turns out our DNS server was blocking queries from Verizon. Once we fixed that then tablets could determine our IP from the server's full domain name.
Currently where I am using HTTPUTILS2 version 2.50 and HTTP version 1.36 is that connections from the tablet by IP address, and not name, connect to our service just fine. This is an emergency work around mode because connections are not secure. Our server won't promote incoming connections unless they are on port 8080 or 8082. But by IP address to port 8081 works perfectly. And correctly interacts with web services fine.
Yes, my service listens on 3 ports, 8080, 8081, and 8082. For 8080 and 8082 it will promote the incoming connection to SSL. For 8081 it works without encryption and does not even attempt SSL promotion.
When I start a "job" to "https://servername.domain.com:8080/OurServices" I don't even see a tap at the door in my service. I don't see a tap at the door from our firewall. Nothing. When we work from Visual Studio we 1) Make an IP connection, 2) Promote it to SSL (starts the handshake).
COULD IT BE, that HTTPUTILS2 or ANDROID does not work this way? What I am asking you, is if it will do the SSL handshake FIRST before attempting connection? If this is true, and the SSL handshake fails, then we may never see anyone tapping at the door at our service. But to understand and diagnose this if someone can authoritatively answer; in the way I am using this, could these symptoms indicate SSL handshake failure?
What I see in the LOGS at ANDROID is the connection is timing out.