[5623] in www-talk@info.cern.ch
Re: holding connections open: a modest proposal
daemon@ATHENA.MIT.EDU (Simon E Spero)
Thu Sep 15 14:52:58 1994
Date: Thu, 15 Sep 1994 20:31:25 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: ses@tipper.oit.unc.edu
From: Simon E Spero <ses@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
I'll reply to this later - meanwhile here's a copy of the SCP session
control protocol I proposed on the IETF working list a while back.
Simon
------
Session Control Protocol (SCP)
------------------------------
Several heavily used Internet applications such as FTP, GOPHER, and
HTTP use a protocol model in which every transaction requires a separate
TCP connection. Since clients normally issue multiple requests to the
same server, this model is quite inefficient, as it incurs all the connection
start up costs for every single request.
SCP is a simple protocol which lets a server and client have multiple
conversations over a single TCP connection. The protocol is designed to be
simple to implement, and is modelled after TCP.
Services.
---------
SCP's main service is dialogue control. This service allows either end of the
connection to establish a virtual session over a single transport connection.
SCP also allows a sender to indicate message boundaries, and allows a reciever
to reject an incoming session.
Design goals.
-------------
o Unconfirmed service without negotiation.
SCP allows data to be sent with the session establishment; the
recepient does not confirm successful connection establishment, but
may reject unsuccessful attempts. This simplifies the design of the
protocol, and removes the latency required for a confirmed operation.
o Low overhead
SCP has a fixed overhead of 8 bytes per segment. This overhead is
half the size of an IPNG address, and is only incurred once per
segment, instead of once per packet.
o Simple design
The session protocol should be simple enough to implement for a
single application.
Protocol Description
Header Format:
--------------
32 24 16 8 0
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|S|F|R|P| SESSION ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEGMENT LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. DATA .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S = SYN F = FIN R = RST P = PUSH
Protocol Operation:
-------------------
Session ID allocation.
Each session is allocated a session identifier. Session Identifiers below
1024 are reserved. Session IDs allocated by clients are even; those allocated
by servers, odd.
Session establishment.
A session is established by setting the SYN bit in the first message sent on
that channel.
Graceful release.
A session is ended by sending a message with the FIN bit set. Each end of a
connection may be closed independently.
Disgraceful release.
A session may be terminated by sending a message with the RST bit set. All
pending data for that session should be discarded
Message boundaries.
A message boundary is marked by sending a message with the PUSH bit set. The
boundary is set at the final octet in this message, including that octet.
