cudep@warwick.ac.uk (Ian Dickinson) (06/28/90)
In article <PCG.90Jun25084059@rupert.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Ironically a number of JANET hosts are migrating as fast as they can to >TCP/IP; I expect that eventually JANET will be used only to carry TCP/IP >traffic on X.25 circuits. In other words, it can also be true that JANET >hosts find quite a bit of utility in being able to access the INTERNET, >which is some orders of magnitude larger. I wouldn't have said there were many sites migrating to TCP/IP though. Most of us are heading for OSI as soon as possible. I thought the amount of IP tunneling on JANET was quite small. Even as it is, it is possible to FTAM to the Internet from my box. >Well, in the UK there are quite a few; let's say half a dozen at least, >and maybe as much as a dozen. Anonymous FTAM is far less convenient >(it's currently strictly offline, spooled, batch) than FTP, but at >least the user is is the much more convenient "guest" rather than >"anonymous" :-). This is simply not true. You can use the ISODE FTAM implementation which does I pretty good emulation of the Berkeley Internet ftp. It is the Blue Book NIFTP which is batched. Cheers, -- \/ato. Ian Dickinson. GNU's not got BSE. "Oh MS-DOS! Why don't you tell vato@cu.warwick.ac.uk Plinth. me why the world in which vato@tardis.cs.ed.ac.uk Sabeq. you're living is so strange?" gdd046@cck.cov.ac.uk On-U Sound System - Undress your mind to this bastard.
yukngo@obelix.gaul.csd.uwo.ca (Cheung Yukngo) (07/06/90)
In article <419@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > Anonymous FTAM is far less convenient > (it's currently strictly offline, spooled, batch) than FTP, but at > least the user is is the much more convenient "guest" rather than > "anonymous" :-). ... The problem with ftp (and rcp) is that the terminal (or window) is tied up for the duration, and I have to sit there and hold its hand to get it to work right. Well, I think we should differentiate ftp the protocol and ftp the program. You can implement a ftp client with interactive mode, batch mode, and half batch mode (you login interactively, find the file you want to transfer, and tell the ftp to get rid of the control terminal and do the transfering in the background without supervision). If you like the challenge you can also design and implement a script language for it. But then, this has nothing to do with ftp, the protocol.
jc@minya.UUCP (John Chambers) (07/06/90)
> Anonymous FTAM is far less convenient > (it's currently strictly offline, spooled, batch) than FTP, but at > least the user is is the much more convenient "guest" rather than > "anonymous" :-). Eh? These are exactly the reasons that I prefer using uucp to ftp, when both are available. The problem with ftp (and rcp) is that the terminal (or window) is tied up for the duration, and I have to sit there and hold its hand to get it to work right. With uucp, I can submit the job (with a -m option if I want notification when it'd done) and go about other work. Across a LAN, ftp and uucp run at about the same speed (though uucp is usually somewhat faster), so there's no reason there to choose between them. Convenience is all on the side of uucp. I don't even have to tell it to do a binary copy; forgetting this is the thing that makes most ftp copies take twice as long as they should. Of course, there is the minor inconvenience that uucp creates files at the destination that are owned by uucp, but I solved that one years ago. I have a little script "mine file ..." that changes the files' ownership to mine. (It's a trivial script for a Real Unix Hacker; so much for filesystem security. ;-) -- Typos and silly ideas Copyright (C) 1990 by: Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers) Home: 1-617-484-6393 Work: 1-508-952-3274
new@udel.EDU (Darren New) (07/06/90)
In article <YUKNGO.90Jul6013142@obelix.gaul.csd.uwo.ca> yukngo@obelix.gaul.csd.uwo.ca (Cheung Yukngo) writes: >You can implement a ftp client with interactive mode, batch >mode, and half batch mode Actually, there is a BITFTP server somewhere that you can mail an FTP script to and it will do the FTP and mail you back the results automatically. Hence, you have the best of both worlds. I don't remember anything in the FTAM spec that would imply that the service cannot be interactive, either. Anyway, I think that the implementations of the FTP and FTAM protocols are a separate issue than the protocols themselves, either of which can be batch or interactive. -- Darren
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/07/90)
In article <YUKNGO.90Jul6013142@obelix.gaul.csd.uwo.ca> yukngo@obelix.gaul.csd.uwo.ca (Cheung Yukngo) writes: In article <419@minya.UUCP> jc@minya.UUCP (John Chambers) writes: > Anonymous FTAM is far less convenient > (it's currently strictly offline, spooled, batch) than FTP, but at > least the user is is the much more convenient "guest" rather than > "anonymous" :-). ... The problem with ftp (and rcp) is that the terminal (or window) is tied up for the duration, and I have to sit there and hold its hand to get it to work right. Well, I think we should differentiate ftp the protocol and ftp the program. You can implement a ftp client with interactive mode, batch mode, and half batch mode (you login interactively, find the file you want to transfer, and tell the ftp to get rid of the control terminal and do the transfering in the background without supervision). If you like the challenge you can also design and implement a script language for it. A little note: I think that a you will already find a decent implementation for all this, as perl scripts, in any comp.lang.perl archive. On the other hand you can also have interactive OSI style file transfer, as it has been pointed out (ISODE). In this country (UK) however it is rarely available (the offline variety is prevalent, and apparently the reason is a conscious decision to "minimize network traffic" resulting from interactive use, as well as a feeling that interactive access is less secure), and it is mainly used gatewayed to Internet FTP servers... :-). I still reckon that the move to TCP/IP tunnelled over X.25 public networks (from local TCP/IP based lan to remote TCP/IP based LAN via an OSI WAN) is still going on strongly in Europe, especially on the Continent (but also in the UK), and in the academic community. Migration *to* TCP/IP indeed... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (07/07/90)
Well, I think we should differentiate ftp the protocol and ftp the
program.
For better or worse, this is what it all boils down to. X.400 is seen
as a big advantage over SMTP because there are some very polished
X.400 applications out there, while the SMTP world is stuck with
university style hacks. Similarly, IP will be very hard to get rid of
because of things like SUN NFS, which haven't been implemented on an
ISO stack yet.
It isn't really a battle of protocols, except down here in the trenches.
It's really a battle waged on the basis of user perception of applications.
BillW
-------