In-Reply-To: <20071206053016.GA1464@cs.unibo.it>
References: <20071205164055.GA2082@cs.unibo.it> <p73bq94k8yd.fsf@bingen.suse.de> <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 <andi@firstfloor.org>, linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 7bit
From: Kyle Moffett <mrmacman_g4@mac.com>
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)
Sender: linux-kernel-owner@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/