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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Apr 9, 2015 at 9: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.

Yep


> Alas, as a network person, i think this would be an exercise in futility
> because the only real benefit would be to create connections between
> a legacy kernel TCP stack and a new userland TCP stack and those
> connections would likely be mostly have little benefits over a simple
> old kernel to old kernel TCP stack:

As I said, water under the bridge. We are now constrained by what
legacy implementations provide.


> If you want new functionalities, most of the time, both sides need to support
> these, the fastest way to get both sides to support them is to both
> run them in userland over UDP and once people get their minds around
> the fact that this is good and not just a workaround, the interest in
> "native TCP" for new improved transport functions should recede.

The current trend is actually in the opposite direction. On Windows
the HTTP server is an O/S resource and user mode processes bind to
specific URL paths. This allows different Web services to be
implemented in completely separate processes.


>> When TCP was designed, the mantra was 'everything is a stream'. That
>> was the right abstraction for Telnet and FTP and Mail. It is probably
>> not the right abstraction for real time web where an unreliable
>> sequence of chunks seems a better fit.
>
> What's missing from SCTP ?

Quite, do we have the opportunity for a quick fix here? If SCTP has
already done all the necessary design work, can we just bolt that on
top of UDP in place of IP and declare a quick victory?

Worth a look to see...