Browse Prior Art Database

Data transfer protocols (RFC0163)

IP.com Disclosure Number: IPCOM000002465D
Original Publication Date: 1971-May-19
Included in the Prior Art Database: 2000-Sep-12
Document File: 2 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

V.G. Cerf: AUTHOR

Abstract

This is an informal statement of material discussed at the SJCC. There are two peoblems.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 57% of the total text.

Network Working Group V. Cerf

Request for Comments #163 19 May 71

NIC #6775 UCLA - NMC

Categories: D.7 Computer Science

Updates: None

Obsoletes: None

DATA TRANSFER PROTOCOLS

This is an informal statement of material discussed at the SJCC. There

are two peoblems.

1. Movement of data from one site to another.

2. Interpretation of the data at receiving site.

The first task (1) requires a simple protocol which accomplishes the

following

1) Standard connection procedure for connecting

transmitting and receiving processes

2) Standard packaging which allows network to

collect the transmitted data stream in the

right order and know when the end of the

file has been reached.

Standard Connection Procedure

Suppose every HOST has a process charged with the responsibility of

sending and receiving files between -HOSTS-(processes?)[The Data

Manager]. If the Data Manager offers to listen on a given socket for

file xmt requests, then ICP is sufficient to establish a connection

between a serving Data Manager and a using process.

We have completely avoided the discussion of data interpretation, and

also the problem of control. For instance, we have not said how a

process can ask the Data Manager to send a file of a par- ticular name,

nor how to end the transmission of a file. This is deferred for later.

Another desirable ability is to have processes transmit files to each

other independent of the HOST Data Manager. ICP should suffice, for the

creation of a full duplex connection. File naming, and format

interpretation are left to the individual process to solve.

It is of interest to note that files need not have names. If two

processes are connected, then the file name is in a sense implicit in

the sending and receiving socket pair. One imagines, however, that

connections with Data Managers for the purpose of file transmission are

too transient to serve as permanent file names, so information about

file name will be needed by the Data Manager. This information could be

supplied either embedded in the file transmission data stream, or

supplied over a separate control connection established at ICP time.

It seems reasonable that a Data Manager have a network-wide, fixed

socket number on which it is listening to service data transmission

requests.* In this sense, it acts much like the Network Logger. For

inter-process file transmission, less rigidity seems called for, and we

can leave such decisions to the individual peocesses communicating with

each other. Public processes at serving HOSTS could have known (nia

NIC?) sockets over which file transmission is acceptable.

Standard Packaging

We naively imagine that very little in the way of formatting is needed

to move data across the connection. A few bits (8?) at the beginning of

transmission could specify the formatting protocol (e.g. arbitrary bit

string until connectio...