[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ih] Origin of the loopback interface

The fundamental problem is that ip networking doesn?t see far enough into the os to be sufficient as the sole IPC mechanism. There arren?t enough demuxing identifiers. 

It would preclude having a multiprocess stack too. You can?t coordinate components to process Ip using ip. 

The problem with loop back is the assumption of locality, which is false without additional filters. Ipc typicallly defaults to local only until extended, which naps better to expectations.


> On Oct 23, 2017, at 11:47 AM, Toerless Eckert <tte at cs.fau.de> wrote:
>> On Mon, Oct 23, 2017 at 11:17:52AM -0700, Joe Touch wrote:
>>> On Oct 23, 2017, at 10:30 AM, Toerless Eckert <tte at cs.fau.de> wrote:
>>> n Mon, Oct 23, 2017 at 07:26:28AM -0700, Joe Touch wrote:
>>>> Loopback should not be a substitute for IPC. At least one additional reason is that packets sent there might not end up where you think (they could be tunneled elsewhere, e.g..).
>>> [ Btw: I could also tunnel any non-IP form of IPC if i have access to the OS.
>>> ]
>> You can but why would you? Ipc should be more efficient and necessary anyway  
> You said that loopback IP traffic would not stay local to a node. You did not
> say wether that would be an attack or a feature. I just said i could do the
> same thing with any other IPC, eg: security and performance IMHO are
> not arguments to decide between IP and other IPC.
> I do not see a need for non-IP based IPC. Ultimately, whenever i want highest
> performance, i am primarily talking about APIs atypical to classical TCP/IP
> stacks (aka: beyond message passing APIs. Like RDMA APIs. Ylu just want to
> make sure your API uses IP addressing of entities, and e voila, you can now
> provide optimized local and remote implementations in the stacks without apps
> having to bother learning two separate mechanisms. E.g.: RoCEv2. If you
> want to constrain the scope of communications, you just use the right
> addressing.
> Cheers
>    Toerless
>> Joe
>>> Cheers
>>>   Teorless
> -- 
> ---
> tte at cs.fau.de