netdev - Re: [PATCH 0/1] IPN: Inter Process Networking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Dec 2007 03:31:48 -0800 (PST)
From:	david@...g.hm
To:	Renzo Davoli <renzo@...unibo.it>
cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	garden@...unibo.it
Subject: Re: [PATCH 0/1] IPN: Inter Process Networking

On Mon, 17 Dec 2007, Renzo Davoli wrote:

> Inter Process Networking (PATCH):
>
> 1. WHAT IS IPN?
> ---------------
>
> IPN is a new address family designed for one-to-many, many-to-many and
> peer-to-peer communication among processes.
> Berkeley sockets have been designed for client-server or point-to-point
> communication; AF_UNIX does not support multicast/broadcast. AF_IPN
> does, in a simple, efficient but extensible way.
> IPN is an Inter Process Communication paradigm where all the processes
> appear as they were connected by a networking bus.
>
> On IPN, processes can interoperate using real networking protocols
> (e.g. ethernet) but also using application defined protocols (maybe
> just sending ascii strings, video or audio frames, etc).
> IPN provides networking (in the broaden definition you can imagine) to
> the processes. Processes can be ethernet nodes, run their own TCP-IP stacks
> if they like (e.g. virtual machines), mount ATAonEthernet disks, etc.etc.
>
> IPN networks can be interconnected with real networks or IPN networks
> running on different computers can interoperate (can be connected by
> virtual cables).
>
> IPN is part of the Virtual Square Project (vde, lwipv6, view-os,
> umview/kmview, see wiki.virtualsquare.org).

other then the fact that this is bi-directional, how is this better then 
using pipes and splice?

wouldn't it be better to just add the ability for multiple writers to send 
to the same pipe, and then have all of them splice into the output of that 
pipe? this would give the same data-agnostic communication that you are 
looking for, and with the minor detail that software would have to filter 
out messages that they send, would appear to meet all the goals you are 
looking at, useing existing kernel features that are designed to be very 
high performance.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html