7

I have a partner who would like us to use a commercial product called Connect Direct where we would normally use ssh based scp or sftp. Besides reading their website, which is of course not quite impartial, is there any material (or do any of you have any opinions or info) on why this software is better than cron (or at) and scp scripting?

1
  • think this may be a wiki.
    – Kyle
    Aug 27, 2009 at 14:12

4 Answers 4

7

Wikipedia has some nice information at: http://en.wikipedia.org/wiki/NDM.

From what I can ascertain with a bit of searching, it was built to guarantee stability with arguably less of a compromise in speed than similarly flexible solutions.

4
  • 3
    Hmm it's probably inferior to rsync+ssh in that respect.
    – niXar
    Aug 27, 2009 at 15:12
  • 1
    Agreed, Rsync, SFTP and SSH seem to replace all NDM functionality in open, free and, most importantly, easy to understand, ergo secure, ways. NDM is too complex to use in any situation requiring a modicum of security unless it is a full time NDM position where people use it day in, day out and manage all aspects of it. May 8, 2013 at 21:06
  • 1
    I think wikipedia article was moved to en.wikipedia.org/wiki/Connect:Direct Sep 29, 2016 at 7:21
  • The problem with the wiki page (NDM or its new home Connect:Direct), the article does not cite enough independent sources about its functionality.
    – ShooShoSha
    Oct 11, 2017 at 22:00
9

Having used Connect Direct, I would say avoid it if you can.
My reasons are:

  • Is very hard to set up (it took our infrastructure team a year)
  • There is a massive learning curve to the application, no one here really understands it still
  • We haven't found it any more reliable than psftp and a cron job.

On its plus sides:

  • Banks seem to love it
  • When it works it guarantees that the file is sent and received and you can be quite sure that the communication is secure.
4
  • As you point out, massive learning curve and that means that you are insecure due to complexity. You put your data at risk because the security isn't simple and obvious. May 8, 2013 at 21:04
  • Crazy. An app that transfers files takes a team of people a whole year to set up properly? if it took more than a day for one person I'd say it's rubbish, avoid it at all costs! On the other hand, maybe your partner company is insisting and they are a bank. I'd still push back if I were you
    – hookenz
    May 8, 2013 at 21:37
  • Connect:Direct is also used to transfer data between legacy mainframe systems (more often on IBM mainframes nowadays) and other systems.
    – ShooShoSha
    Oct 11, 2017 at 22:01
  • Your infrastructure team took it a year? how many minutes did they alloted for this setup in a day? I only took 3 hours to setup C:D on a client.
    – EAL
    Mar 18, 2018 at 12:08
4

Sometimes you've got to ditch mainframe era technology, even if it used to be top-notch and cost an arm and a leg. From the description I fail to see what Direct:Connect provides that isn't matched or outclassed by scripted rsync, ssh, or even (depending on your needs) tar.

1
  • And sometimes you have to ditch it when it just isn't very good. May 8, 2013 at 21:04
4

My biggest concern with Connect:Direct is how unnecessarily complex it is. That it is costly and outdated is another issue. And that it is closed source and doesn't have the industry support, eyeballs and testing that OpenSSH is still another issue. My key concern with CD is that it violates one of the most fundamental security concerns - that "complexity is the enemy of security." You can be complex or you can be secure but you can't be both. From a high level, I feel that Connect:Direct is insecure through its own complexity. I can only assume that there are many other security blunders under the hood - being closed source and barely used makes it easy to hide or ignore other types of security problems. I would not have faith in this product. I'm not happy at all that I've had to use it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .