Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

Request for comments on socket name structure (RFC0129)

IP.com Disclosure Number: IPCOM000002109D
Original Publication Date: 1971-Apr-22
Included in the Prior Art Database: 2000-Sep-12
Document File: 5 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Harslem: AUTHOR [+3]

Abstract

This RFC is in answer to a request (made at the February NWG Meeting at the University of Illinois) that we comment on several suggested socket name structures. We apologize for the delay in getting out these comments and we hope that you will respond more quickly with your reactions. Please direct your replies via the standard RFC mechanism. Two structures are presented in this RFC as shown below.

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

Network Working Group 22 April 1971

Request for Comments: 129 E. E. Harslem-Rand

NIC 5845 J. F. Heafner-Rand

E. Meyer-MIT

A REQUEST FOR COMMENTS ON

SOCKET NAME STRUCTURE

INTRODUCTION

This RFC is in answer to a request (made at the

February NWG Meeting at the University of Illinois) that

we comment on several suggested socket name structures.

We apologize for the delay in getting out these comments

and we hope that you will respond more quickly with your

reactions.

Please direct your replies via the standard RFC

mechanism.

Two structures are presented in this RFC as shown

below.

31 1

+-------------------------------+-+

1. | Arbitrary | | <-- gender

+-------------------------------+-+

24 7 1

+------------------------+------+-+

2. | User ID | tag | | <-- gender

+------------------------+------+-+

Three variations are given for the way in which

socket names are assigned, as examples of use of the

first structure.

1. Users pick the arbitrary number arbitrarily

and associate it with a process.

2. A logger chooses the arbitrary number dynamically

and associates it with a process via a directory.

3. The arbitrary number is assigned outside of a

logger but may be issued by a logger to the

remote party.

The second format shown above associates sockets specifi-

cally with users as opposed to processes.

The following discussion covers three different schemes

of socket identifier assignment using a simple example.

User A at Host A has agreed (by letter, telephone, etc.)

with User B at Host B for their respective processes to

establish a connection through the Network at a particular

time. User B is to be waiting for the connection attempt

initiated by User A. The issues to be faced are those of

addressing (how is User A to know to which socket to connect?),

and of security (how are both users to be confident that

they are talking each other, and not some interloper?).

A fourth scheme follows which addresses another concept

of Network use--that connections are made between processes

and that processes not users should be identified via

Socket names.

FREELY SELECTED RANDOM SOCKET IDENTIFIERS (Scheme 1)

Under this scheme a user is able to use any 32-bit

socket identifier he chooses. Two restrictions apply: the

least significant bit denotes the socket's gender (0-read,

1-write), and no more than one socket bearing a given iden-

tifier can be active at a host at a time.

The two users select suitably random identifiers ("a"

and "b"). User A will attempt to activate his socket with

identifier "a" an connect it to socket "b" at Host B. There

is the possibility that somebody other than User B has

a...