Re: Is Wininet the only choice for FTP?

[Pavel A.]

I have a similar symptom with "Live Mail" on XP SP3 - a misterious timeout
when sending mail
with attachment. But it does not always reproduce.
When I got around to install a sniffer, it now works fine...

The appropriate NGs for this are microsoft.public.win32.programmer.networks,
microsoft.public.windowsxp.network_web, maybe
microsoft.public.windows.vista.networking_sharing.

Of course, not this one.

Regards,
--pa

"Bogdan" <bog...@nocompany.com> wrote in message
news:eTkMonoe...@TK2MSFTNGP05.phx.gbl...
>
> "Brian Muth" <bm...@mvps.org> wrote in message
> news:4FBA2814-B919-4AAB...@microsoft.com...
>> We have used Wininet to FTP very large files, and have never had any
>> trouble. I'm not convinced that there is a hitherto unknown bug in your
>> program. I think it is worth troubleshooting with a debugger and a
>> sniffer before giving up on Wininet.
>>
>> Brian
>>
>>
> Thanks Brian. This gives me some comfort and hope.
>
> I'm quite certain that the code is OK. In its simplest form it is just one
> line of code which is a call to FtpGetFile(). I can see that after the
> call is issued the file on the local disk keeps growing until it almost
> reaches its size. For example, if I try to transfer 150 MB file then the
> file on the local disk gets pretty close to 150MB (minus 1-2K) and then
> FtpGetFile() returns false.
>
> I finally managed to put WireShark (as suggested by Pavel) on the
> problematic machine. I discovered that at the end of file transfer both
> command line ftp and my app run into identical problems. The difference
> is that command line ftp is able to recover somehow but FtpGetFile() is
> not.
>
> This is what happens after about 180K packets:
> 1) servers sends "TCP Previous segment lost"
> 2) client responds with ACK
> 3) server sends "TCP Out-of-order"
> 4) client responds with ACK
> 5) client sends FIN,ACK
>
> The above is identical for ftp.exe and FtpGetFile(), including values in
> Ack fields. The next exchange is what differentiates ftp from
> FtpGetFile().
>
> ftp.exe:
> 6) server sends "226 Transfer complete"
> 7) server sends ACK
> 8) client sends ACK
>
> FtpGetFile():
> 6) server sends ACK (identical to 7 for ftp.exe above)
> 7) client sends FIN,ACK
> ... nothing happens for 30 seconds
> 9) client sends FIN,ACK
> 10) server responds with reset (RST)
>
>
> It looks like FtpGetFile() expected "226 Transfer complete" in step 6) and
> got ACK instead. This caused it to response with FIN/ACK.
>
> Would you know what could be causing the above? Or, do you know of any
> newsgroups/blogs that I can post this problem to?
>
> Thanks,
> Bogdan

[Bogdan]

Thanks again Pavel for your reply.

I got it working on the problematic machine by replacing an older version of
Linksys router with a new Trendnet (nothing wrong with Linksys, I think,
just its age).

I'm still puzzled by that whole experience because I do not understand why
one app can work fine with a 'faulty' router and another cannot. This would
indicate that wininet API has some weaknesses. But, it is free and very
easy to use so I think I can live with it.

When it comes to NGs... The microsoft.public.win32.programmer.networks is
almost dead. Other that you have suggested - your 'maybe' is a bit
discouraging :).

This newsgroup seems to be most active so posting an issue about
wininet/FtpGetFile() seemed like a best bet. And it worked for me!

Many thanks to everyone who responded by my post.
Bogdan

"Pavel A." <pav...@12fastmail34.fm> wrote in message
news:B280EF77-53EE-4BA8...@microsoft.com...

[Pavel A.]

Wait for few days, maybe the problem will return.
For me, the problem with WLM and attachments also misteriously disappears
and
later returns, without any change in hardware at all.

--pa

"Bogdan" <bog...@nocompany.com> wrote in message

news:##BfCs$eKHA...@TK2MSFTNGP04.phx.gbl...