• Subject: Re: SNADS over TCP/IP
  • From: Larry Bolhuis <lbolhui@xxxxxxx>
  • Date: Wed, 03 Mar 1999 18:35:20 -0500
  • Organization: Arbor Solutions, Inc


 Having used both and written code to leverage both I must say there is
definitaly room for FTP and SNADS.  Certainly for connectivity to NON IBM
servers FTP is generally simpler and more likely to be available.  For moving
one or two files it's way faster.  For reliability and ease of monitoring go

 Tim is really on target. If FTP can't get to the other machine you gotta read
the unformatted log output, parse it best you can, guess in some cases, wait,
then try again.  With SNADS, you Send it and forget it. On the recieve side with
SNADS you just wait for the message CPxnnnn telling you what file and from and
to whom and deal with it. No guesswork, always in sequence.

 FTP has it's place and I use it a lot, but you CANNOT replace SNADS with FTP
unless you really like writing code.
 - Larry

Tim McCarthy wrote:
> >
> >
>         >My point is FTP doesn't care if it can't attach to another
> machine either.
>         >Finding if the transmission was successful is as simple as
> reading the FTP
>         >log text, manually or via a program that knows what to look
> for.

>         Huh??? What do you mean FTP doesn't care if it can't attach to
> another machine? FTP is a connection oriented protocol, it has to be
> connected to the destination server to perform the file transfer. If the
> connection is broken then too bad, start again. SNADS is connectionless.
> If the connection to the remote host is not active then the request is
> queued; if the connection is broken it can recover on another route - no
> user intervention required. As far as checking the FTP output log to
> determine if the transmission was successful: this is not only difficult
> but it's highly unreliable and the output varies from server to server.
>         >> To set up this same
>         >> processing via FTP would require jumping through many more
> hoops.
>         >>
>         >I disagree.  Maybe a couple hoops, but at least you'd be using
> something
>         >that is platform independant.  That outweighs the one or two
> hoops you need
>         >to jump through to see if the transmission was successful.
>         I understand the omnipresence of FTP but I agree with Rob here
> on the hoops issue. With SNADS I can monitor for files intended for me
> or my application as a user. I do not have to depend on the remote user
> using a certain file name or putting to a particular directory. Plus if
> I get multiple files they're all queued nicely in order for me and they
> can be prioritized. Think of the processes you have to build at both
> ends just to control the situation where a remote sends another copy of
> the same file before I've processed the data in the first copy. Does he
> append or replace? What if I've got the file locked?
>         In addition don't forget to consider the issues associated with
> running an FTP server on the host side...giving out user id's,
> controlling the remote users access etc. I'm not trying to be negative
> on FTP here - the company I work for writes and sells FTP clients and
> servers - but FTP is not always a good replacement for SNADS.
>         Tim

Larry Bolhuis         |
Arbor Solutions, Inc  | Two rules to success in life:
(616) 451-2500        | 1. Never tell people everything you know.
lbolhui@ibm.net       |

| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].