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  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

Powered by blists - more mailing lists