Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 951
  • Last Modified:

wxWidgets - wxFTP connections are slow on windows

Any ideas why connections made using wxWidgets' wxFTP are slow when run in windows? I made an application that will manage files on an ftp server using wxWidgets. When the program is run in windows, the program is able to authenticate quickly enough but beyond that and things like FileExists and GetOuputStream take hellishly long to complete. Whereas the linux version runs really fast. What's even more interesting is that the windows version run under wine runs just as fast as the linux version. Any ideas how to fix this?
0
trigger-happy
Asked:
trigger-happy
  • 6
  • 4
1 Solution
 
trigger-happyAuthor Commented:
Can anyone answer? :(

--trigger-happy
0
 
trigger-happyAuthor Commented:
Platform is Windows XP since the problem is windows specific, library used is wxWidgets 2.8.7 compiled with mingw32 (cross compiler on a Fedora 9 system, both wxwidgets and the application I'm making are using the same compiler).

--trigger-happy
0
 
giltjrCommented:
Have no idea what wxWidgets is, but here are a few questions, which you may have already looked at.

How busy is the CPU when this function is running?
How much memory is is use when this function is running?
Is there a lot of disk I/O?

I will assume that there is no difference between the network connections, CPU, and memory, and normal workload running on the Windows and Linux boxes.

When you say slow, can you give a comparison of just how slow.  Like doing a function on Linux take 5 seconds and on Windows it takes 100 seconds.
0
Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

 
trigger-happyAuthor Commented:
There's barely any change in CPU and Mem and barely any disk activity as well. In terms of network connections, there's no difference at all since I dual boot my desktop while my laptop runs an ftp server for testing (which my program connects to). In terms of speed, the linux binary of the program completes the startup operations (connect, check for certain files, download some files and standby) in about 1 second, windows takes about 1 minute.

--trigger-happy
0
 
giltjrCommented:
Umm, interesting.  Have you run a packet capture while under Windows?  How is the ftp server found?  Meaning do you refer to it by name (DNS lookup required) or by IP address?

If you refer to it by name, try using IP address.  If that works much faster, then you have a DNS resolution problem someplace.

You may want to try running a packet capture on the client when running it under Windows to see what the network traffic looks like.  This will also verify if there is a DNS resolution issue.

0
 
trigger-happyAuthor Commented:
Haven't tried that yet but will do in a while, though i've always been referring to the server using its IP address

--trigger-happy
0
 
giltjrCommented:
Darn.  Well if you are using the IP address, unless something else is going on under the covers that needs a name (or IP address reverse lookup) resolution a packet capture may be your best bet.
0
 
DanRollinsCommented:
I also have no experience with that library.  However, an (oldish) problem with that function related to slow reverse lookup -- when using IP address
   http://trac.wxwidgets.org/ticket/2512
   http://lists.wxwidgets.org/pipermail/wx-dev/2005-May/062897.html

It might be worth a try to use a domain name -- in text, not ip numbers.

Also, if this the the problem, try getting the latest version of the library.
0
 
trigger-happyAuthor Commented:
Sorry it took me a while, had some stuff to take care of. In any case, I've uploaded the captured data of the program running in windows and linux. I've only included the ftp related data in the capture. As you can see, everything is exactly the same except for the time it took for the things to complete. Oh and disregard the last few lines of the windows capture, I closed the program in question before I stopped capturing in wireshark.

Link: http://www.geocities.com/trigger_happy_elite/captures.zip

--trigger-happy
0
 
giltjrCommented:
To make sure I understand everything:

 packet catpure was run on the client where the wxWidgets is running
192.168.1.100 = client where wxWidget is running
192.168.1.102 = FTP server

If this is correct you can see a definite issue on the client between the two.  If you look at both traces at the same time look packets 7 and 8 in both traces.  You will see the server sending back "Entering Passive Mode".   However, Linux responds with the NLST cc_main.swf request in 0.45 seconds, whereas Windows takes 9.0 seconds.

In almost every case, it takes Windows 8-9 seconds to respond after receiving "Entering Passive Mode".

That was the easy part.  The hard part is figuring out why.  What you may want to do (I have no clue how these Widgets work) is see if you can display messages and time stamps as the program goes along.  So you display a message when the Widget sends the PASV request (with timestamp), display a message (with timestamp) when the response comes back, and then display a message (again with timestamp) when the program sends the NLST command.  This MAY help isolate where the time is being spent.
0
 
trigger-happyAuthor Commented:
Ok so I found out through the wxwidgets forums that the issue is due to some windows specific stuff within the library.
http://wxforum.shadonet.com/viewtopic.php?t=19928
I haven't actually tested the intrusive fix mentioned (I got compiler errors that I'm still resolving) but at least I found the reason there. I'll have this question closed if you guys don't mind since I found he solution elsewhere.

--trigger-happy
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 6
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now