Re: [Spud] SPUD's open/close are unconvincing

[Toerless Eckert <[e-mail]>]

On Thu, Apr 09, 2015 at 08:42:07AM -0700, Tom Herbert wrote:
> On Thu, Apr 9, 2015 at 6:55 AM, Toerless Eckert <[e-mail]> wrote:
> > On Thu, Apr 09, 2015 at 09:09:17AM -0400, Phillip Hallam-Baker wrote:
> >> TCP should probably not happen in the kernel either. Nor should
> >> printer drivers be in the kernel or anything that does not require the
> >> intermediation of the security monitor.
> >
> > Right. As an OS person i would love for someone to implement a
> > "raw transport socket" option for unprivileged processes. Implement
> > in linux, go to POSIX, spend a decade trying to get it proliferated across
> > OSs.
> >
> Good luck on finding an OS vendor willing to give random applications
> unfettered access to the network. Anyway, you can already do this by
> just wrapping whatever you want in UDP-- TCP, SCTP, RDMA, whatever.

I didn't say "raw ip socket", "pcap socket" or the like. "raw transport
socket"to me means something that behaves pretty much like a UDP
socket only that you can select the IP layer protocol from a list
of eg: OS level configured options. That list could include all the
transport protocols that share the common method of 4-byte demultiplexing
header with Sport/Dport. Eg: TCP, SCTP, and a few others. So the kernel
would still do the demultiplexing bas on either (*,Dport) for sockets
in listening state and (Sport,Dport) for sockets in connected state.

But fully agree with your conclusion. This would be design wise nice and
clean, but has no business opportunity to it to make it worth our while.
Just use UDP and declare it to be the mandatory future OS-level demultiplexer
layer for any future transport (+ the discussion that we likely want to
have that SPUD like layer for common flow-setup).

Cheers
    Toerless