Transfer Queue and Connections

I believe this to be a bug at the design level of SmartFTP 3.0.

I'm really frustrated with 3.0 so far since it appears to use one connection for the browser and seperate connections for the transfer queue workers. This means that multiple connections need to be opened to the server, which is not good for my situation.

With previous versions of SmartFTP, I could upload stuff so easily it was a breeze. Now this transfer queue gets stuck trying to open new connections which appear to get blocked by the server I'm trying to connect to. They SOMETIMES go through, but more often than not, things get stuck in the queue and it appears that I just have to sit there waiting for a retry and hope that eventually a connection goes through.

Can someone tell me if there is a way to get 3.0 to use a single connection to the server?

This is by design. If you only want 1 connection close the Remote Browser before you start the Transfer Queue.

Every "modern" protocol today uses multiple connections to the server. e.g. HTTP, Torrent, etc. Do you consider them badly designed? Even the FTP protocol uses a control and a data connection to the server.

Please use the search feature in the forum for further explanations.

Regards,
Mat

This is by design. If you only want 1 connection close the Remote Browser before you start the Transfer Queue.

Every "modern" protocol today uses multiple connections to the server. e.g. HTTP, Torrent, etc. Do you consider them badly designed? Even the FTP protocol uses a control and a data connection to the server.

Please use the search feature in the forum for further explanations.

Regards,
Mat

Mat,

Thanks for your quick reply. I understand your points, and perhaps I overstated mine. The issue is that under pre-3.0 versions of SmartFTP, I could upload files very easily. There was a connection to the server, I'd drag-and-drop, and boom, I'm done. Now, with things going in to the transfer queue, if there is an issue making an additional connection, things get hung up. I'm fighting major frustration just trying to do what used to be SO EASY. This is what I meant by it being a design "bug". Look, I'm a developer too. I understand your points. Perhaps it's the stupid server I'm forced to connect to. But the fact that I know how it used to work and now it doesn't go smoothly, is painful. I'll follow up with some transfer queue logs, etc. and maybe you can give me some additional advice. At this point though, I may have to go looking for another tool. This stinks because SmartFTP is a beautiful piece of software.

- Mark

Hello Mark ..

Most likely the reason why you experience problems is because your server only allows you to open a single connection to the server. To verify this double click the item at the top of the Transfer Queue. In the log you should find something as described here:
https://www.smartftp.com/support/kb/421- ... f2602.html

We believe that only a very small percentage of users are affected by this problem. Connection limitations of 1 connection/user are typically set up by free hosting providers to encourage their users to upgrade to a paid plan.

If you have a server with no such limitations the Transfer Queue is fully transparently to the user. There is no additional step involved from a user's perspective.

Regards,
Mat

Ive got exactly this problem since updating today

a set of files that should take 5 mins has taken over 3 hours
& my isp does not limit the amount of connections

any way around this??

G

gibby: Please post the log from the Transfer Queue.

Mat,

My server allows me to have up to 8 simultaneous connections from a single source IP address. I have a single worker in the transfer queue (I tried 3 at one point, but it only seemed to make things worse), and I have the transfer queue set to reuse connections.

I just tried switching to active mode and so far, things look good. (I appologize, because I thought I had tried that already, but maybe my head wasn't screwed on straight at the time.) I'm guessing that what was happening was that the server I'm connecting to, or some firewall issues inbetween were the culprit...

...As I write this, I tried passive mode again and things seem fine now. (???) Perhaps something changed at the server since I was having issues, I don't know. But, this problem appears to have cleared up for me now. And, I can set the worker count up to 3 and it goes along very well. Perhaps others that are having this problem can try active mode, I don't know if that is an answer or not.

For me, I think I'm good now... This is a relief because, as I said, SmartFTP is really great software that I didn't want to abandon.

Thanks,
Mark

Hello Mark ..

The Transfer Queue has an automatic fail-over for Active Mode / Passive Mode. If Active Mode fails it will automatically try Passive Mode and vice versa.
So you shouldn't have a problem with that. Should you experience problems in the future please post the log from the Transfer Queue and we can see what goes wrong with the transfer. Thank you.

Regards
Mat

Hi!
In the old version i have disabled the transfer queue, but in this new version, how i can do it?
Transfer for small files is bad...

How i disable transfer queue?

Thanks!

I'm not sure this is an uncommon issue at all - I think you're going to be seeing quite a lot of posts in here. I use a number of FTP servers (none free - all paid for hosting accounts) and several have connection limits set, with severe throttling/temporary IP blocking as a penalty for exceeding them. It usually seems to be done as a denial of service defence. None of these servers limits you to one connection, though, it's more likely to be around six-eight.

I get round this by setting up a connection limit on the favourite for that server, but this is going to be a recurring problem for new users who aren't aware of this functionality and just see connection problems. I'm also no sure how you could do this for ad-hoc connections?

The only way round this I can see is to ship SmartFTP with a low per-server connection limit set and let people remove this once they find their way around. That's going to make it look like SmartFTP performs badly on more capable servers, though, and you'd have to decide how to handle upgrades. Let direct transfer users upgrading get caught by the current issue or wind up queue users by messing with their settings?

The default number of workers in the transfer queue is 1.

No paid hosting provider I know has a 1 connection per ip limit. Even the cheapest web hosting providers (dreamhost/godaddy for 5 USD/month) offer at least 10 concurrent connections.
There are no problems with the default settings for 99.99% of all ftp servers.

Regards,
Mat

But, in the old version i don't* use transfer queue, and in this new, I can use without transfer queue?

Well i just got SmartFTP 3 and i find it very annoying using this Transfer Queue method, i knew it was available with the previous versions, i believe there were 3 options, Direct, Transfer Queue and another one that i can't recall, the point is we had a choice, now it seems we do not. Or do we, can someone tell me if it is possible just to download using a Direct method? I much preferred it, and it seems with SmartFTP 3.0 i can't get it to resume, it just won't work on the FTP i like to use to get all my game patches, the Multiplay.co.uk FTP that is VERY fast and reliable.

I appreciate that i can get SmartFTP for free and then update to another build, it's great, i like SmartFTP above other FTP clients i have tried but the main reason i like using FTP's and SmartFTP in particular is because it allows me to resume downloads, usually large downloads like video game patches. It seems with SmartFTP 3.0 it just won't work, if i try i get 3 options, none of which are resume and when i try and resume it in the Transfer Queue window it keeps giving a Retry time.

I just want to download the way i used to do it with a Direct download, one connection, one download, simple easy and i could resume with no problems.

I don't like this at all, i hope someone can tell me how to sort it.

Post the log from the Transfer Queue and we can see why the server doesn't let you resume.

Post the log from the Transfer Queue and we can see why the server doesn't let you resume.

Hi!
Is possible active in this new version the direct transfer?

Thanks!

The log doesn't show anything, it just says "The operation has been added to the Transfer Queue. Check the Transfer Queue for the status." and that's it, then in the Transfer Queue window all i get is a Retry at time and it doesn't resume. I am using an anonymous log in so it says 'restrictions apply', that might well be why it doesn't work, i don't know. Point is, it worked fine before and the options were there, now they don't seem to be, no Direct Transfer, why?

All i want is the Direct Transfer with Resume like it used to be. I used the Transfer Queue before when i could do simultaneous downloads which was great, but it was rare with the FTPs i was using, it was much more common for me to use the Direct Transfer option.

I really do not like this version of SmartFTP and i will probably be looking to a previous version soon that has the options i want.

Solinar:
You can get version 2.5 from here:
https://www.smartftp.com/support/kb/smar ... f2599.html

But it would help if you can post the log of the Transfer Queue. There is one if the item state is retry.

Regards,
Mat

Here's a cut from my log, since nobody seems to be listening:

[16:20:04] 250 End.
[16:20:34] CWD /
[16:20:35] 250 OK. Current directory is /
[16:20:35] PWD
[16:20:35] 257 "/" is your current location
[16:20:35] NOOP
[16:20:35] 200 Zzz...
[16:20:35] CWD /admin/templates
[16:20:35] 250 OK. Current directory is /admin/templates
[16:20:35] PWD
[16:20:35] 257 "/admin/templates" is your current location
[16:20:35] MLST new_category.tpl
[16:20:36] 250-Begin
[16:20:36] type=file;size=2745;modify=20080213081306;UNIX.mode=0644;UNIX.uid=3516;UNIX.gid=
450;unique=11g46924f; new_category.tpl
[16:20:36] 250 End.
[16:20:36] MLST search_results.tpl
[16:20:36] 250-Begin
[16:20:36] type=file;size=590;modify=20080213081336;UNIX.mode=0644;UNIX.uid=3516;UNIX.gid=4
50;unique=11g469250; search_results.tpl
[16:20:36] 250 End.

It's like it's transfering a file and then sitting and waiting for 30 seconds to transfer the next.

This is the log from the Remote Browser. Please post the log from the Transfer Queue. To get it double click the item in the Transfer Queue.

The file seems to transfer just fine.

Do you have set the number of workers in the Transfer Queue to 1? If not I recommend you to do so because your server has a connection limit of 2.

Regards,
Mat

The file seems to transfer just fine.

Do you have set the number of workers in the Transfer Queue to 1? If not I recommend you to do so because your server has a connection limit of 2.

Regards,
Mat

No, I had it set to 5. I also disabled the the background transfers as stated in the help. It seems to be rolling without stopping now. Just didn't expect to have to make changes like this when I uploaded the new version.

Thanks for your help!
E-nerd

It's the server connection limit for me too, i am allowed 2 connections. I looked in to this Background Transfer thing and disabled it, it didn't seem to work but i am just going to get what i want in the Transfer Queue and close the Browser and that seems to work fine, but i am still a bit dubious about it and don't understand why we can't have the options like in previous versions.

It is a 530 error in the log.

I am unsure where the connections are being used up, 1 for transfer and 1 for the browser, but when i stop the transfer it doesn't seem to want to resume so i don't know why it doesn't close the connection when i stop it.

What can I say? A new user, full of excitement to use SmartFTP (due to excellent reviews/ recommendations, the whole schebang) and then the very first transfer lead to exactly the same problem as discussed by so many other users.... Always deeply disappointing if you need to tweak, tweak, tweak before something works.
I don't know, maybe I just want to complain, instead of thrashing my PC out of the window in frustration.

Oh, and by the way, I am switching to V2.5, maybe better luck before I uninstall this program forever.

I believe these topics annoy admin very much.
I just want to say my opinion.

I strongly believe the new feature is a better design,
but for uers, is it a better choice?

In my opinion, for a user,
when choose a software, "assuetude" is one of the most important consideration.

I used SmartFTP about 4 years,
since I am a freshman, and now going to graduate :o
why do I not change the FTP clinet?
sure SmartFTP is an excellent software,
but another reason is just "assuetude" :)

when an "assuetude" is not so bad that damage the system,
throw away it completely is a good choice?


---
my mother language is not English,
the speaking may strange :-)