Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!ucivax!gateway
From: vcerf@NRI.Reston.VA.US
Newsgroups: comp.protocols.iso.x400
Subject: Re: Ports in Abstract Protocol specs
Message-ID: <9012240900.aa19913@NRI.NRI.Reston.VA.US>
Date: 24 Dec 90 14:19:00 GMT
References: <Your message of Sun>,
	<554118*JPALME@QZ.qz.se>
Lines: 39
Approved: usenet@ICS.UCI.EDU
Autoforwarded: true

Jacob,

I can try to answer your question about the purpose of
ports in abstract protocols on the basis of the design
work done on TCP and UDP (the connection and connectionless
service protocols of the TCP/IP protocol suite).

Our initial model was that communication was between
cooperating processes in distinct machines. We assumed
that there would be more than one process in each
machine so that a communication service operated in
common at the operating system level would want to
be able to distinguish among "associations" by their port
identifiers. Actually, we said that a particular
communication was identified by a
pair of socket identifiers (a socket was a host
address and a port number). It was possible for
a process to have several TCP connections going
at once with other processes, each connection
uniquely identified by the PAIR of sockets on either end.

A single socket identifier could be used on one
side to associate with distinct sockets on many
different machines (so one process could be talking
to many others). By extension, a single process
on machine A could be communicating with many
processes on the same machine. Everything was
symmetric so it was even possible (and is common)
for a process to talk to other processes on the
same machine (ie all processes are housed on the
same computer).

By keeping the "associations" distinct, one can
apply flow control on each separately, so that
the behavior of one process on the system need
not interfere with the behavior of another, in
terms of TCP flow control, for example.

Vint Cerf