Text preview for : M973 File Transfer Protocols Used At Universities; Tzoar, Auerbach.pdf part of IBM M973 File Transfer Protocols Used At Universities; Tzoar, Auerbach IBM share SHARE_61_Proceedings_Volume_1_Summer_1983 M973 File Transfer Protocols Used At Universities; Tzoar, Auerbach.pdf
Back to : M973 File Transfer Protoc | Home
SESSION REPORT ~SHARE~
----.:
18. Murray, W. D.; Moss, C.E.; Parr, W.H. and Cox, C., A radiation and 61 M973 File Transfer Protocols Used at Universities _______________
industrial hygiene survey of video display terminal operations, Human
SHARE NO. SESSION NO. SESSION TITLE ATTENDANCE
Factors, 1981, 23 (4), 413-420.
Unive~y Information Exchange Project Sandra Ward ---.RAT...---
19. Quick, M. J., 1982, "Information Systems Requirements for Development PROJECT SESSION CHAIRMAN INST. CODe
Engineering Productivity," Task Force Report, Internal IBM Report, Dept. of Computing Services, Univ of Waterloo, Waterloo, Ontario N2L 3Gl, 519-885-1211
Kingston, New York. Cited in Minicucci, R. A., sub-second response
time, a way to improve interactive user productivity, IBM STL, 28, 1982. seSSION CHAIRMAN'S CONl'ANV. ADDRESS. and PHONE NUMBER
20. Rosenthal, S.G., and Ghundy, J.W., Avoiding eye problems with VDU's, 1. KERMIT - The File Transfer Protocol Used at Columbia
Physics Technology, 1980, II 175-186.
Daphne Tzoar
21. Rouse,- W. B., 1975, Design of man-computer interfaces for on-.iine
interactive systems. Proceedings of the IEEE, 63 (6), 847-857. Columbia University
Center for Computing Activities
22. Shneiderman, B., 1979, Human factors experiments in designing 612 West 115th Street
interactive systems, Computer, 12, 9-19. New York, NY 10025
23. Smith, M. J., Cohen, B. G., F. Stammerjohn, L.W. Jr., and Happ, A., An Installation Code: BWY
investigation of health complaints and job stress in video display
operations. Human Factors, 1981, 3l, 387-400.
2. YTERM!PCTRANS FILE TRANSFER PROTOCOL
24. Smith, W.A., Jr., 1967, Data Collection - Systems - Part 1:
Characteristics of Errors. Journal of Industrial Engineering, Josh Auerbach
18 (12), 703-707.
(1") Computing Center
1:,,) 25. Stewart, T.F.M., Displays and the software interface, Ergonomics, Yale University
C"J 1976, 7 (3), 137-146. New Haven, Connecticut
26. Thadhani, A.J., 1981, "Interactive User Productivity, II IBM Systems Installation Code: YU
Journal, 20 (4), 407-423.
27. Tomeski, E.A., 1975, Building human factors into computer applications:
computer profession must overcome a "jackass fallacy"! Management
Datamatics, 4 (4), 115-120.
28. Treu, S., 1975, Interactive command language design based on required
mental work. International Journal of Man-Machine Studies, 7, 135-149.
29. Welyczkowsky, G. D., 1982, "A Study in Interactive User Productivity:
The Effect of Remote Transmission Delay on TSO Productivity," Internal
IBM Report, Poughkeepsie, New York. Cited in Minicucci, R. A., sub-
second response time, a way to improve interactive user productivity,
IBM STL, 28, 1982.
14
SHRM-730-1/Bl
2
included so Kermit's use is uniform across any two systems. The protocol makes no
THE KERMIT FILE TRANSFER PROTOCOL assumption about speed, duplex or flow control. It does assume, however, that: (a) all
printable ASCII characters are accepted as input to the host and will not be transformed,
(b) a single non-printable character can be used for synchronization (generally, Control-A),
and (c) if a host requires a line terminator for terminal input, it is a single ASCII character
Everyone wants to get different computers talking to each other. At Columbia, we have (like CR or LFI. As implied, all transmission is done in ASCII. If a system uses anything
been doing this with great success. File transfer is performed with a protocol we call else (EBCDIC, for example), it is its responsibility to convert all data. So, the CMS version
"Kermit". Kermit is also the name of a family of programs that use the protocol to does ASCII/EBCDIC and EBCDIC/ ASCII translations.
provide error-free file transfer between various types of computers -- word processors,
microcomputers, minicomputers and large mainframes. We connect the two systems over The protocol is designed for character oriented transmission over serial telecommunication
TTY lines thus tricking each computer into thinking the other is a terminal. lines. It allows for restrictions and peculiarities of different operating systems (buffering.
duplex, parity, and so on.) For example, when receiving a packet from the IBM. it knows
Kermit was originally developed at Columbia two years ago for students with limited to wait for the XON before sending the next packet
on-line storage allocations. Kermit enabled them to keep their work on floppies. We
provided Intertec SuperBrains and the means by which they could transfer files to and In designing the protocol, we wanted the flexibility to talk to our half-duplex IBM system
from the micro and our DEC-20. Since then and the proliferation of many different in addition to the full duplex DEC-20. And we wanted to avoid bombarding our DEC-20
micros, and due to the needs of our users in the university community, we expanded the front end with continuous data - it assumes that all incoming data comes from a person
protocol and implemented Kermit for numerous mainframes and micros, with contributions typing at the keyboard. It cannot allocate buffers quickly enough to accomodate streams
from several sites other than Columbia, most notably Stevens Institute of Technology. To of data coming to it and hence data can be lost Therefore, we developed Kermit to be
date, Kermit has been shipped to over 250 sites in the US, Canada, and overseas -- it has not truly full duplex or asynchronous. The protocol does not allow for "stacked" packets
been well tested to be sure!1 It is used by many educational institutions, companies, and long packets are not sent For every packet of data that gets sent, Kermit expects a
research laboratories and several dial-up databases. response before the next packet is sent So while Kermit does not have transfer rates as
high as truly asynchronous full-duplex protocols, we usually achieve 50-80% efficiency
You might ask why do we need a protocol? There are two major reasons why a protocol (that is, user bits / baud rate.)
is necessary: (1) Noise - data can become garbled in transmission. The longer the wire,
c:J') and the faster the baud rate of the line, the more the data is prone to noise and error. Kermit is generally used for file transfer between a mainframe and a micro, although host
(.:)
Noise corrupts the data often in subtle ways. Therefore, we use a protocol - we to host and micro to micro file transfer are possible.
-,1
intermingle control information with data to achieve data integrity. (21 Synchronization
- One computer may be faster or have larger buffers than the other. If it sends data We have two types of Kermits - dumb ones and smart ones. The smart Kermits are
faster than the other can receive, data will be lost Built in flow control mechanisms such capable of timing out when waiting to receive data from the serial port That means, they
as XON/XOFF cannot be guaranteed to work, because different computers may not honor can detect remote system crashes or protocol deadlocks where part of a packet is lost