To: Ian Heavens <ian@spider.co.uk>
Cc: end2end-interest@charm.isi.edu
Subject: Re: half baked anycastoff idea...
In-Reply-To: Your message of Mon, 27 Jun 94 07:23:47 A.
Date: Mon, 27 Jun 94 07:19:38 PDT
From: Van Jacobson <van@ee.lbl.gov>

> The market demands conformance to Berkeley TCP/IP semantics and
> API, but I thought the RFCs and not the damn Berkeley code was
> the standard!

RFCs typically do a detailed description of the protocol and a
cursory description of the API.  Berkeley sockets actually
follow the API sketched in RFC793 very closely (compare the
description of "OPEN" on p.45 with the semantics of "accept")
and if you know the early BBN-to-Berkeley history of the BSD
code, you know that this similarity is no accident.

It's fairly easy to extend the Berkeley API, in a backwards
compatible way, to allow a defered accept.  Here is part of the
accept(2) manual page from 4.4BSD:

     For protocols marked as requiring an explicit confirmation, such as ISO
     or DATAKIT, accept() can be thought of as merely dequeueing the next con-
     nection request and does not imply confirmation.  Confirmation is im-
     plied by a normal read or write on the new file descriptor, and rejection
     is implied by closing the new socket.

     One can obtain user connection request data without confirming the con-
     nection by issuing a recvmsg(2) call with an msg_iovlen of 0 and a non-
     zero msg_controllen, or by issuing a getsockopt(2) request.  Similarly,
     one can provide user connection rejection information by issuing a
     sendmsg(2) call with providing only the control information, or by call-
     ing setsockopt(2).

The 'lazy accept' on first read/write is compatible with almost
all the existing programs.  Work was planned to add a sockopt to
set/reset the "explicit confirmation" option on a per-listen-socket
basis for TCP and to do the minor surgery on tcp_input &
tcp_usrreq needed to implement the option.  Berkeley CSRG died
from lack of funding before this work was completed.

 - Van