Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754222AbXLFGTb (ORCPT ); Thu, 6 Dec 2007 01:19:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752594AbXLFGTY (ORCPT ); Thu, 6 Dec 2007 01:19:24 -0500 Received: from smtpoutm.mac.com ([17.148.16.67]:61376 "EHLO smtpoutm.mac.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752539AbXLFGTX (ORCPT ); Thu, 6 Dec 2007 01:19:23 -0500 In-Reply-To: <20071206053016.GA1464@cs.unibo.it> References: <20071205164055.GA2082@cs.unibo.it> <20071206053016.GA1464@cs.unibo.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BD0AF2A-959D-4744-9D2A-3AE84CF96CBB@mac.com> Cc: Andi Kleen , linux-kernel@vger.kernel.org Content-Transfer-Encoding: 7bit From: Kyle Moffett Subject: Re: New Address Family: Inter Process Networking (IPN) Date: Thu, 6 Dec 2007 01:19:13 -0500 To: renzo@cs.unibo.it (Renzo Davoli) X-Mailer: Apple Mail (2.752.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3625 Lines: 82 On Dec 06, 2007, at 00:30:16, Renzo Davoli wrote: > AF_IPN is different. AF_IPN is the broadcast and peer-to-peer > extension of AF_UNIX. It supports communication among *user* > processes. Ok, you say it's different, but then you describe how IP unicast and broadcast work. Both are frequently used for communication among "*user* processes". Please provide significantly more details about exactly *how* it's different. > Example: > > Qemu, User-Mode Linux, Kvm, our umview machines can use IPN as an > Ethernet Hub and communicate among themselves with the hosting > computer and the world by a tap like interface. You say "tap like" interface, but people do this already with existing infrastructure. You can connect Qemu, UML, and KVM to a standard linus "tap" interface, and then use the standard Linux bridging code to connect the "tap" interface to your existing network interfaces. Alternatively you could use the standard and well-tested IP routing/firewalling/NAT code to move your packets around. None of this requires new network infrastructure in the slightest. If you have problems with the existing code, please improve it instead of creating a slightly incompatible replacement which has different bugs and workarounds. > You can also grab an interface (say eth1) and use eth0 for your > hosting computer and eth1 for the IPN network of virtual machines. You can do that already with the bridging code. > If you load the kvde_switch submodule IPN can be a virtual Ethernet > switch. As I described above, this can be done with the existing bridging and tun/tap code. > Another Example: > > You have a continuous stream of data packets generated by a > process, and you want to send this data to many processes. Maybe > the set of processes is not known in advance, you want to send the > data to any interested process. Some kind of publish&subscribe > communication service (among unix processes not on TCP-IP). Without > IPN you need a server. With IPN the sender creates the socket > connects to it and feed it with data packets. All the interested > receivers connects to it and start reading. That's all. This is already done frequently in userspace. Just register a port number with IANA on which to implement a "registration" server and write a little daemon to listen on 127.0.0.1:${YOUR_PORT}. Your interconnecting programs then use either unicast or multicast sockets to bind, then report to the registration server what service you are offering and what port it's on. Your "receivers" then connect to the registration server, ask what port a given service is on, and then multicast-listen or unicast-connect to access that service. The best part is that all of the performance implications are already thoroughly understood. Furthermore, if you want to extend your communication protocol to other hosts as well, you just have to replace the 127.0.0.1 bind with a global bind. This is exactly how the standard-specified multiple-participant "SIP" protocol works, for example. So if you really think this is something that belongs in the kernel you need to provide much more detailed descriptions and use-cases for why it cannot be implemented in user-space or with small modifications to existing UDP/TCP networking. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/