Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Contribute hammering FTP servers?

We’re having a problem at work with Macromedia Contribute. We host sites for a number of local companies, and one of them wants to use Contribute to update its site. The problem is that whenever Contribute tries to connect to our FTP server, it opens up 30 simultaneous connections, effectively running a denial of service that prevents other clients from logging in during peak times. I’ve searched the ’net and haven’t found any references to this problem; does anyone know anything about the issue? We’re running ProFTPD 1.2.9 and the client is using Macromedia Contribute 2.

Posted 17th November 2003 at 11:34 pm

This is Contribute hammering FTP servers? by Simon Willison, posted on 17th November 2003.

View blog reactions

Next: Sprint PCS goes CSS

Previous: Linux on the desktop at IBM

7 comments

  1. This is a total shot in the dark (I've haven't used Contribute), but are the Contribute users behind a NAT box? I'm just thinking that maybe Contribute is brain-dead when it comes to handling all the usual FTP problems which arise from trying to FTP through a NAT, and maybe it tries opening a new connection when it has trouble opening a port. Or do you experience the same problem when you run Contribute on a computer local / not NATTed to the server? It would also be helpful to know if you've tried using FTP to your server in both passive and active mode, just to be sure the problem isn't on your end (since everyone might have been using passive FTP until now or something). Even if there aren't any NAT boxes between Contribute and the server, you might still want to try changing the settings in Contribute to try a passive connection, just in case that triggers some different code that works around the bug you're experiencing. Well, that's it for my suggestions, if they don't help I hope you find someone who knows more about Contribute than I do.

    Nick - 17th November 2003 23:58 - #

  2. We use Contribute 2 at work through a local/network connection. I don't think I have ever seen it open more than one connection. We had it set up to go remote for a while to test the viability of using it 'long-distance', and I don't rememember it doing anything funky then either. The NAT idea is a good suggestion - but I know that The FTP Server Checker might be a good way to diagnose or at least see part of the issue.

    Eric - 18th November 2003 01:19 - #

  3. A different approach: What happens if you limit the number of connection they can open (on a per host basis)? Info here Setting it to say 5 should not cause anyone much of an issue.

    Chris - 18th November 2003 10:50 - #

  4. I can confirm a similar result. I'm not looking at it from a server standpoint, but when connected to a server outside my network via OSX Contribute, the app (maybe?) seems to be swamping my bandwidth. Perhaps my issue is unrelated, not sure.

    Nate - 18th November 2003 19:01 - #

  5. I would recommend, on the server side, to move to PureFTPd. ProFTPd has numerous problems and is just generally unstable. Everyone I know who has experienced problems like this, while appearing to be caused by a poor client, have been cleared up with the migration to PureFTPd.

    Ian - 18th November 2003 20:53 - #

  6. We've solved the problem by limiting the maximum number of connections per user - see this entry.

    Simon Willison - 19th November 2003 23:07 - #

  7. One acronym to fix this: WebDAV.

    Bill Humphries - 22nd November 2003 20:56 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2003/11/17/contributeProblem

A django site