diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc962.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc962.txt')
-rw-r--r-- | doc/rfc/rfc962.txt | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/doc/rfc/rfc962.txt b/doc/rfc/rfc962.txt new file mode 100644 index 0000000..6fa3875 --- /dev/null +++ b/doc/rfc/rfc962.txt @@ -0,0 +1,112 @@ +Network Working Group M. A. Padlipsky +Request for Comments: 962 Mitre-Bedford + November 1985 + + TCP-4 Prime + + +STATUS OF THIS MEMO + + This memo continues the discussion of a possible transaction oriented + transport protocol. This memo does not propose a standard. + Distribution of this memo is unlimited. + +DISCUSSION + +In response to Bob Braden's call for a transaction oriented +protocol (RFC-955), the following thoughts come to mind: + + o The perceived problem is that connection set-up and tear-down + take too long. + + o Other aspects of TCP's reliability/robustness approach are + presumably still desirable. + + o We have some spare command bits in the TCP header, and I trust + that there's still a version number field. + + o So why not add NYS (no-way handshake) and NIF (graceless close) + commands to TCP and leave everything else as was (except for the + version, of course)? + +Philosophically, that might be somewhat at variance with "the spirit of +TCP," but pragmatically it ought to do the trick. Some careful crafting +might be required for ISN handling with NYS, but my guess is that if you +have to resend the first/possibly only segment you just pretend you're +all of a sudden in the middle of SN space (initially you start at the +bottom of it) and when it sees the funny ISN the NYS handler knows it +should dequeue anything it might have had pending for (re)transmission +and start fresh, assuming that if anything gets through to the starting +side belatedly it'll get chucked because of being well outside the left +edge of the window, if I'm remembering that part right--and please be +aware that I'm not bothering to confirm recollections because I don't +want to pretend that this is the spec: it's just meant to be the +concept, in TV talk. (On the NYS emitting side, presumably you just +drop right into ack_expected state--or whatever the right name is--after +setting an appropriate bit that'll get you to fiddle the ISN if you take +a timeout.) Maybe you even fiddle the ISNs more elaborately, to allow +for several false starts rather than "two strikes and you're out," and +maybe we take some spurious segment hits if SNs get suitably balled up, +but if you really think handshaking is too expensive then that's the way +the premise crumbles. + + +Padlipsky [Page 1] + + + +RFC 962 November 1985 +TCP-4 Prime + + +Speaking of graceless closes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Padlipsky [Page 2] + |