Re: Is Wininet the only choice for FTP?
- From: "Pavel A." <pavel_a@xxxxxxxxxxxxxxx>
- Date: Mon, 14 Dec 2009 04:59:21 +0200
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" <bogdan@xxxxxxxxxxxxx> wrote in message news:##BfCs$eKHA.4636@xxxxxxxxxxxxxxxxxxxxxxx
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." <pavel_a@xxxxxxxxxxxxxxx> wrote in message news:B280EF77-53EE-4BA8-A4FC-C007F460426A@xxxxxxxxxxxxxxxxI 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" <bogdan@xxxxxxxxxxxxx> wrote in message news:eTkMonoeKHA.5792@xxxxxxxxxxxxxxxxxxxxxxx
"Brian Muth" <bmuth@xxxxxxxx> wrote in message news:4FBA2814-B919-4AAB-9EDB-2AFF1A0F3486@xxxxxxxxxxxxxxxxWe 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.Thanks Brian. This gives me some comfort and hope.
Brian
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
- Prev by Date: UDP hole punching
- Next by Date: Winsock socket handle reallocation
- Previous by thread: UDP hole punching
- Next by thread: Winsock socket handle reallocation
- Index(es):
Relevant Pages
|
