CFtpConnection fails in Win95
Leor Amikam -- amikam@mindspring.com
Saturday, November 23, 1996
Environment: Win95/MSVC4.2b
I am trying to use the CInternetSession/CFtpConnection and its
related classes under win95. If I construct a
CInternetSession object for syncronous FTP I/O ( not calling
EnableStatusCallback(TRUE) ), I can connect to a server
and do stuff. Of course, this is blocking - not what I
wanted.
If I call EnableStatusCallback(TRUE), when I try
to call GetFtpConnection, I get an exception, "
Overlapped I/O operation is in progress", error
#997 - ERROR_IO_PENDING. I know win95 does not
support overlapped I/O, but I thought this was=20
only for disk I/O. Network I/O IS supposed to
support this feature. Any suggestions ?
Thanks,
Leor Amikam
Mike Blaszczak -- mikeblas@nwlink.com
Sunday, November 24, 1996
At 19:23 11/23/96 GMT, Leor Amikam wrote:
>Environment: Win95/MSVC4.2b
>I am trying to use the CInternetSession/CFtpConnection and its
>related classes under win95. If I construct a
>CInternetSession object for syncronous FTP I/O ( not calling
>EnableStatusCallback(TRUE) ),
Calling EnableStatusCallback(TRUE) enables status callbacks.
It doesn't turn on asynchronous WININET transfers.
Specifying the INTERENT_FLAG_ASYNC flag will provide
asynchronous I/O.
>I can connect to a server and do stuff.
>Of course, this is blocking - not what I wanted.
Do it in a different, subordinate thread.
>If I call EnableStatusCallback(TRUE), when I try
>to call GetFtpConnection, I get an exception, "
>Overlapped I/O operation is in progress", error
>#997 - ERROR_IO_PENDING.
That you got this error message means that your code wouldn't benefit
from FLAG_ASYNC, anyway. If you open a WININET connection and
ask for ASYNC, you'll end up returning from the connection call
_before you get a valid handle to the connection_! Your code
is going off and doing some more work against that connection
before it is ready to be used. Since you don't have enough work
to keep you busy while you're waiting for the network operation
to complete, you wouldn't benefit from not blocking during the
call to do the network operation.
When you open the connection in asynchronous mode, you're really
not writing code that says "return to me a connection"; you're
writing code that asks the API "get started on getting me a connection,
and call me back when you're done". Instead of taking that connection
object and subsequently using it, you need to wait until you get the
appropriate callback to use the connection--mainly because the connection
hasn't even been made until you get the callback!
As you perform subsequent operations, you need to follow the same
model: asking for a file to be sent to you doesn't do that operation
atomically; it just initiates the operation. The operation doesn't
progress or complete until you process the callback.
WININET's asynchronous model isn't very simple. There's no way
to test for completion or blocking, and even that withstanding,
design using that architecture isn't very easy.
MFC 4.2B doesn't support FLAG_ASYNC inherently, though if you
understand the model you can use the MFC classes to get the work
done in asynchronous mode.
MFC may add true support for it in a future version of the libraries,
but there is far more interesting and important work to be done; as
you've demonstrated, most people don't understand WININETs
asynchronous programming model. And unless you're following that
model strictly, it really doesn't make your work asynchronous at all.
You're far better off, instead, with a worker thread that does your
WININET stuff for you.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
| Вернуться в корень Архива
|