[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Large file uploads via PHP - ftp limitations etc...




On Dec 7, 2006, at 6:58 AM, Duncan Robertson wrote:

Yes, ftp login banner has something along the lines of "ftp problems? -
try filezilla" as pretty much the first comment, unfortunately the end
users may be "random" (as far as I am concerned) people in "random
locations" (as far as I am concerned) that may need to transfer a file
to one of my end users, and they could be in any country, in any network situation, with no prior notice to me. Of course most of the time ftp is
Just Fine, but sometimes hairy problems arise.

Understand.

Another shortcut is the oliver ftp frontend:
http://oliver.sourceforge.net/
for simple ftp stuff, instantly all the messing about with firewall
issues goes away as long as http works, of course then you hit the
limits of the php upload etc, - if this was tweaked to upload in chunks
rather than the entire file at once into RAM and then dump it into ftp
(the php ftp module?) it would be great.

Will have to check that out.  Sounds nice.

Yes, thats what I mean, overcome the limitations of the ftp protocol by not using it. I have just dabbled with winSCP but it seems to solve most of the problems of ftp, except it needs a dedicated client exe installed for windows users.. but then to get anything aproaching non-sucking ftp
you need to do this anyway. And yes some place broken for ftp may be
broken for ssh, but the single tcp connection over port 22 ssh uses does
work heaps better in general.

Isn't that odd? I've seen it too -- strange network behavior out there on some networks. I often wonder if it's just broken "transparent" proxies... but like your situation I'm rarely able to see what the person complaining is seeing.

Personally I rarely use ftp, I use rsync over ssh or scp it just seems
for some reason windows users are stuck with this old protocol to move
large files around more by intertia and I end up having to support it as
a lowest common denominator kind of thing.

They made their bed... now they have to lie in it.  :-)

Also from my research ftp cannot be reliably NATted if any of the
encrypted variants of ftp are
used, meaning you have a choice of telnet level security, or not working
across nat/firewalls.

Ummm... I think that depends on various factors, but all add so much complexity to the question that the average end-user's eyes will be glazed over by the time you start the second sentence when explaining it.

But if PASV FTP won't work, the chances of SCP/SFTP working are
pretty low.  They're just on a horribly broken network.  Ask them if
they're getting what they paid for and turn 'em loose on that admin
who's still recovering from the lobotomy... he needs the practice to
regain his skills.

And we could even start a legal debate about the SLA and TOS that the
other end have committed to while we are at it, under whatever legal
jurisdiction they happen to be in!

LOL!

Ok for example lets say I had a user in Laos.. can http reliably but
most other traffic controlled by state firewall. Or a random
netcafe/hotel-that-advertises-internet in (say..) Cambodia.. where
discussions about whether or not the network is broken or how leet their
admins are won't get you far as the place is full of tourists who are
happy if hotmail works, and the staff just turn on "the internet" at the
wall every morning and otherwise have no idea, or concern as long as
google and hotmail pops up. user in that location needs to upload a file
urgently.. of course I can have a great time discussing (in Laos or
Khmer) how much the admin was paid to build the network or the
broken-ness of the network if ftp is failing, but really the job at hand
is just to help the user receive the file(s) ASAP.

Hmmm... yeah.

Fixing the other end is good if I have time, but I'd also like to have
flexible tools available at my (server) end that can overcome the
brokenness I know I will encounter sooner or later at the other end.

Makes sense.

Something important came to mind while I was reading your reply, but looking at my (almost devoid of content) reply above, it must have slipped away... 1:18 AM... I guess that's to be expected... (GRIN).

Oh I remember now at least one funny thought that came to mind, reading your comments about the PHP-based system delivering the file in chunks... It made me laugh out loud and think of the "good old days" of 1200 baud modems and BBS's. Various protocols for handling file up/downloads in chunks were bandied about, but you know what really worked... and there's code out there if anyone wanted to tackle such a thing in the lrzsz package... the old X, Y, and Z modem protocols.

They work flawlessly over dedicated bit pipes like our modern Internet/Ethernet, albeit with lots of unnecessary overhead and error correction added on. (slower)

I use Z-modem all the time (just out of habit) from within SecureCRT on a Windows machine at work. Works from the Linux command line too, actually... just a bit different syntax.

If the lrzsz package is loaded on the machine, a simple "sz filename" in the shell on the host I'm logged into will initiate an auto-start Z modem download within SecureCRT over whatever type of shell session I'm on... pretty nifty trick. Same going the other way, "rz" will pop a dialog box on SecureCRT asking what file I wanted to upload.

Old-school tools... maybe someone could hack lrzsz into a Java applet that would load into a browser. (GRIN)... Yeah, kinda nuts... but would be an interesting experiment!

Judging by your top-level domain, I believe the ethos of the phrase "have a go" would capture the type of mentality it would take to give it a try!

Cheers,
--
Nate Duehr
nate@natetech.com





Reply to: