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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
