Fog Creek Software
Discussion Board




Procomm or custom?


I have to implement a solution for companies to dial in to our network and upload a file. The transaction is established and straightforward.

The machine has four modems to watch.

I can either:
a) Write an Aspect script in Procomm, then run four instances of Procomm, watching each modem.

b) Write a custom service in C#, with threads to watch each modem.

With (a), I get all the code in Procomm to handle serial comms, but I have to figure out Aspect scripting, it's a desktop UI app, and I have to run four instances. With (b), I can write the code pretty quickly, but .Net doesn't have native serial protocols, so I have to use MSCOMM and I have to handle the comms issues. But I do get to write it as a proper server service.

Thoughts? I'd like to do (b), but a nagging voice is telling me I'm doing the "when all you have is a hammer" thing, and should be using the capabilities already available in (a).

Philo

Philo
Tuesday, May 06, 2003

Other than security issues (which might be the reason), why can't they FTP to a server managed by you, either inside your network or where you (or some application), can get to it?

Otherwise, I might even be tempted to dust off the old BBS software and run that as a means of them coming in.  If I remember rightly Procomm has that as well. 

Simon Lucy
Tuesday, May 06, 2003

They can't/won't FTP. It has to be dial-in. This is non-negotiable.

Philo

Philo
Tuesday, May 06, 2003

Do you ever work for rational people?

I think the BBS method would be the least painful then.

Simon Lucy
Tuesday, May 06, 2003

Actually, I'll have to admit it's a reasonable decision - the company dialing in has a million dollar business system that's been in place for decades. It does what they need just fine, but it doesn't FTP.
My solution is at a business partner - why should a company have to replace their business system just because a partner can't handle the way they've always done business?

Sure, when there are enough value added factors to justify changing systems, they'll make the shift - but this is just one reason, and not a reason that really affects them.

Philo

Philo
Tuesday, May 06, 2003

Maybe something like
http://www.sax.net/Framework/Communications/
could speed things up?

Just me (Sir to you)
Tuesday, May 06, 2003

Everyone isn't on the internet and many big institutions don't give a shit about techie "everything ought to be FTP" snobbery. (although do I agree that it feels pretty stupid to be developing a character based solution in 2003.)

I think the main concern is DOS attacks and general vulnerability to internet chaos. Also, on the internet it's possible for an attacker to run through thousands of user/password combinations very rapidly, while with dial up most backends will drop the connection after a few failed login attempts.

The IRS's e-file backend, and many credit card processors, to use two prominent examples, are proudly stuck in the dial-up async - zmodem/kermit/xmodem protocol character mode backwater.

Nasty Curmudgeon
Tuesday, May 06, 2003

Procomm, eh? I thought the early nineties ended about ten years ago! Qmodem Pro is better anyway.

DrAwesome
Tuesday, May 06, 2003

Is there some reason you're limiting communications software solutions to Procomm?

I recently did an interface to an EDI order system using HyperAccess, the big brother to the Hyperterminal app that's packaged with every Windows install.  The nice thing about it was its OLE automation that allowed you to do scripting in other languages.  I used VBA, but you can also use C++ for the automation if you want:

http://www.hilgraeve.com/hyperaccess/win32/index.html

Herbert Sitz
Tuesday, May 06, 2003

How 'bout Kermit?

Source is available - which might make it easier to hook into.

http://www.columbia.edu/kermit/ckermit.html#download

Nat Ersoz
Tuesday, May 06, 2003

I have exactly the same situation.

I'm in banking, it is against regulations for our data to cross the internet no matter how encrypted it may be.

Our solution: an old NT 4 box running RRAS, remote users have accounts on the machine, they can dial in with any windows version and drag and drop their files,  box has IP forwarding turned off so they can't get on our network.

Seems this would solve your problem too without writing any code.

Anonymous Coward
Tuesday, May 06, 2003

Slightly off topic, but in which country is it illegal to transfer banking information across the internet?

My business is corporate/commercial electronic banking, and I've yet to meet this restriction.

HeWhoMustBeConfused
Wednesday, May 07, 2003

Sax? Oh. God. No.


Wednesday, May 07, 2003

"Sax? Oh. God. No."

Could you elaborate? Not that I have worked with this or have a need for it in the foreseable future, but it is always nice to learn about the merits of a product from someone with direct experience.

Just me (Sir to you)
Wednesday, May 07, 2003

The experience was a long time ago, so maybe things have changed. To be honest I am too traumatised by the experience to talk about it.


Wednesday, May 07, 2003

I'll put in a second vote for HyperACCESS from Hilgraeve ( www.hilgraeve.com ). It has the full OLE automation layer, and a seperate EXE called HyperHost that handles stuff like watching modems and taking calls.

And it's still sold and supported by the company that wrote it. I imagine getting help for Procomm is getting pretty tough these days.

Bob

BC
Wednesday, May 07, 2003

It is not a law it is a regulation.

We are a financial switch.

We are members of Interac, Plus, Cirrus, and Visa/Mastercard. We are settlement agents for Interac and Visa/Mastercard. We operate all the ATMs for nearly sixty credit unions and schedule 2 banks.

It is definetely against Interac regulations to send data across the internet. It is definetly against the policy of the schedule 1 banks to send their clients data across the internet.

Last year we finally moved our communication links to the schedule 1 banks from X25 to a private leased line TCP/ip network. Note that this is not a VPN but seperate circuits end-to-end.

Anonymous Coward
Wednesday, May 07, 2003

We are borg. Resistance is futile.

[grin] Couldn't resist.

I think you need some clarification on that regulation, AC. I just checked my account info, including credit card info, online. I'm pretty sure that data came across the internet.

I suspect the issue is interbank communications?

Philo

Philo
Thursday, May 08, 2003

Well I have open in front of me a photocopy of: "The Interac Association -  Security Standards and Operating Regulations", with a printing date of 1998.

I'm told that it is on-line somewhere at:

http://www.interac.org/en_n1_00_about.html

But I can't find it. Maybe I'd need to be logged in.

Anonymous Coward
Thursday, May 08, 2003

ATM networks are probably a little more secure than your on-line checking account Philo. :-)

I worked in IT at a credit union and there are many regulations that you have to follow. What the customer (or "member") sees is just the tip of the iceberg. There are all kinds of networks and settlement procedures and protocols behind the scenes and they are all subject to very explicit rules of the organization that runs each network.

I can definitely see rules like "no Internet connections" being enforced on these back-end systems. The people who run them are *very* conservative and you want it that way, believe me.

Nate Silva
Friday, May 09, 2003

I was addressing this statement:
"It is definetely against Interac regulations to send data across the internet. It is definetly against the policy of the schedule 1 banks to send their clients data across the internet."

and simply commenting that there was probably something like "unless specifically requested by the customer" or words to that effect as a caveat.

Because by the letter of the law stated above, customers cannot retrieve balance info over a web browser - that would be the bank sending client info across the internet.

Philo

Philo
Monday, May 19, 2003

*  Recent Topics

*  Fog Creek Home