Hi Stephen,
Post by Stephen SulzerPost by Robert FerraroIf you are generally satisfied with the overall stability, performance,
and scalability of the WinInet-based...
Yes, at this point, I have to say I'm quite satisfied. I will eventually
test with WinHTTP just to have a better idea of its capability vs.
WinINet...
Post by Stephen SulzerPost by Robert Ferraro...Although using a dedicated thread for each camera connection,
resulting in dozens to 100 or more simultaneous threads, is not a scalable
design, if that is what your app is doing.
Yes, this is exactly the scenario. There's no other way that I know of to
accomplish the same result. Of course, the capability to connect to 100
cameras is meant to be used in a multi-user scenario, where more than one
desktop has shared access to the connection details of 100 (or more)
cameras, and each desktop will view/record a more reasonable number of
connections.
Post by Stephen SulzerPost by Robert Ferraro(WinHTTP's default receive timeout is 30 seconds.) WinHTTP would not
restart the interrupted read operation--the app would have to resend the
request.
I implemented the InternetSetOption (setting the receive and send timeout to
30 seconds, as you suggested) and
tested 20 camera connections (10 recording) overnight, with my router set to
renegotiate its lease every hour. By morning, all cameras were connected and
recording. I have a feature that allows the user to specify auto-reconnect
on and auto-record on a dropped connection. So, the "limbo" state seems not
to have occurred...
Thanks again for your help.
Robert Ferraro.
Post by Stephen SulzerSounds like an interesting application. If you are generally satisfied with
the overall stability, performance, and scalability of the WinInet-based
application, then there really isn't any reason to change it to use WinHTTP.
WinHTTP would handle a high-stress, heavily multi-threaded application
better than WinInet. (Although using a dedicated thread for each camera
connection, resulting in dozens to 100 or more simultaneous threads, is not
a scalable design, if that is what your app is doing.)
However, for this particular problem in which the network connection is lost
during a send or receive operation, WinHTTP would not do better than
WinInet, other than perhaps returning an error in a timely fashion.
(WinHTTP's default receive timeout is 30 seconds.) WinHTTP would not restart
the interrupted read operation--the app would have to resend the request.
Post by Robert FerraroThanks Stephen, I'll try that first.
I use WinINet in an application that connects to network cameras that
run
Post by Stephen Sulzeran
Post by Robert FerraroOS with a built-in web server and HTTP support. The app does
surveillance
Post by Stephen SulzerPost by Robert Ferraroand recording, and can be connected to many cameras simultaneously
(possibility of connecting to 100 cameras), so there are many threads
making
Post by Robert FerraroHTTP requests. The app has been in use for several months, and thankfully,
appears to be working well-enough with the WinINet lib. The router IP
renegotiation is the only issue to date.
I've started to look at WinHTTP --do you think it would offer more robust
support for this type of application?
Best regards,
Robert Ferraro.
I don't think WinInet is very robust in the case where the internet
connection disappears during a send or receive operation. I seriously
doubt
that InternetReadFile will be able to recover from this type of network
connectivity interruption.
The only thing you can do, if you haven't already, is to set send &
receive
timeouts that are better than WinInet's defaults. WinInet's default read
timeout is 60 minutes(!), and 5 minutes for a send operation. Try
setting
Post by Robert Ferraromore reasonable send and receive timeouts; say, 30 seconds for each. Use
InternetSetOption to set the INTERNET_OPTION_RECEIVE_TIMEOUT and
_SEND_TIMEOUT options. (However, be aware of KB article 176420,
http://support.microsoft.com/default.aspx?scid=kb;en-us;176420.)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wininet/wininet/option_flags.asp
Post by Stephen SulzerPost by Robert FerraroWith a shorter timeout setting, your program will (hopefully) see an
INTERNET_ERROR_TIMEOUT error and be able to recover and re-try the HTTP
request.
Stephen
Post by Robert FerraroHi,
Is there a known issue with the InternetReadFile function under the
1) you're connected to a web server, and actively reading data in a
loop
Post by Robert FerraroPost by Robert Ferrarowith the InternetReadFile function
2) the router connecting you to the web server renegotiates it's IP
lease,
Post by Robert Ferraroand you experience a momentary loss of connectivity
It appears that InternetReadFile isn't aware of the momentary
disconnect;
it
Post by Robert Ferrarodoesn't flag an error, doesn't resume where it leftoff...in fact, it
leaves
Post by Robert Ferraroyour application in limbo until you programmatically disconnect.
Does anyone know anything about this?
Thanks in advance,
Robert.