[TUHS] Research Datakit notes

Rob Pike robpike at gmail.com
Tue Jun 28 22:36:31 AEST 2022

I am not a networking expert. I said that already. The issue could well be
a property more of sockets than TCP/IP itself, but having the switch do
some of the call validation and even maybe authentication (I'm not sure...)
sounds like it takes load off the host.


On Tue, Jun 28, 2022 at 8:39 PM Derek Fawcus <
dfawcus+lists-tuhs at employees.org> wrote:

> On Sun, Jun 26, 2022 at 09:57:17AM +1000, Rob Pike wrote:
> > One of the things we liked about Datakit was that the computer didn't
> have
> > to establish the connection before it could reject the call, unlike
> > where all validation happens after the connection is made.
> Nor does TCP, one can send a RST to a SYN, and reject the call before it is
> established.  That would then look to the caller just like a non listening
> endpoint, unless one added data with the RST.
> So this is really just a consequence of the sockets API, and the current
> implementations.
> I've a vague recall of folks suggesting ways to expose that facility via
> the sockets
> layer, possibly using setsockopt(), but don't know if anyone ever did it.
> As I recall that TCP capability was actually exposed via the TLI/XTI API,
> and (for some STREAMS based TCP stacks) it did function. Although I may be
> thinking of embedded STREAMS TCP stacks, not unix based stacks.
> Or by 'connection' are you referring to an end-to-end packet delivery,
> and that Datakit allowed a closer switch to reject a call before the packet
> got to the far end?
> DF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220628/150184a9/attachment.htm>

More information about the TUHS mailing list