ipn/README

   1 Inter Process Networking (and Kernel Virtual Distributed Ethernet)
   2
   3 WHAT IS IT?
   4 -----------
   5 Berkeley socket been designed for client server or point to point
   6 communication. All existing Address Families implement this idea.
   7 IPN is a new family designed for one-to-many, many-to-many and peer-to-peer
   8 communication.
   9 IPN is an Inter Process Communication paradigm where all the processes
  10 appear as they were connected by a networking bus.
  11 On IPN, processes can interoperate using real networking protocols
  12 (e.g. ethernet) but also using application defined protocols (maybe
  13 just sending ascii strings, video or audio frames, etc).
  14 IPN provides networking (in the broaden definition you can imagine) to
  15 the processes. Processes can be ethernet nodes, run their own TCP-IP stacks
  16 if they like, mount ATAonEthernet disks, etc.etc.
  17 IPN networks can be interconnected with real networks or IPN networks
  18 running on different computers can interoperate (can be connected by
  19 virtual cables).
  20 IPN is part of the Virtual Square Project (vde, lwipv6, view-os,
  21 umview/kmview, see wiki.virtualsquare.org).
  22
  23 WHY?
  24 ----
  25 Many applications can benefit from IPN.
  26 First of all VDE (Virtual Distributed Ethernet): one service of IPN is a
  27 kernel implementation of VDE.
  28 IPN can be useful for applications where one or some processes feed their
  29 data to several consuming processes (maybe joining the stream at run time).
  30 IPN sockets can be also connected to tap (tuntap) like interfaces or
  31 to real interfaces (like "brctl addif").
  32 There are specific ioctls to define a tap interface or grab an existing
  33 one.
  34 Several existing services could be implemented (and often could have extended
  35 features) on the top of IPN:
  36 - kernel bridge
  37 - tuntap
  38 - macvlan
  39 IPN could be used (IMHO) to provide multicast services to processes.
  40 Audio frames or video frames could be multiplexed such that multiple
  41 applications can use them. I think that something like Jack can be
  42 implemented on the top of IPN. Something like a VideoJack can
  43 provide videoframe to several applications: e.g. the same image from a
  44 camera can be viewed by xawtv, recorded and sent to a streaming service.
  45 IPN sockets can be used wherever there is the idea of broadcasting channel
  46 i.e. where processes can "join (and leave) the information flow".
  47 Different delivery policies can be defined as IPN protocols (loaded
  48 as submodules of ipnvde.ko).
  49 e.g. ethernet switch is a policy (kvde_switch.ko: packets are unicast
  50 delivered if the MAC address is already in the switching hash table),
  51 we are designing an extendended switch, full of interesting features like
  52 our userland vde_switch (with vlan/fst/manamement etc..), and a layer3
  53 switch, but other policies can be defined to implement the specific
  54 requirements of other services. I feel that there is no limits to creativity
  55 about multicast services for processes.
  56
  57 HOW?
  58 ----
  59 The complete specifications for IPN can be found here:
  60 http://wiki.virtualsquare.org/index.php/IPN
  61
  62 Bind create the socket (if it does not already exist). When bind succeeds,
  63 the process has the right to manage the "network".
  64 No data is received or can be send if the socket is not connected
  65 (only get/setsockopt and ioctl work on bound unconnected sockets).
  66 Connect is used to join the network. When the socket is connected it
  67 is possible to send/receive data. If the socket is already bound it is
  68 useless to specify the socket again (you can use NULL, or specify the same
  69 address).
  70 Connect can be also used without bind. In this case the process send and
  71 receive data but it cannot manage the network (in this case the socket
  72 address specification is required).
  73 Listen and Accept are for servers, thus they does not exist for IPN.
  74
  75 1- Peer-to-Peer Communication:
  76 Several processes run the same code:
  77
  78   struct sockaddr_un sun={.sun_family=AF_IPN,.sun_path="/tmp/sockipnvde"};
  79   int s=socket(AF_IPN,SOCK_RAW,IPN_BROADCAST);
  80   err=bind(s,(struct sockaddr *)&sun,sizeof(sun));
  81   err=connect(s,NULL,0);
  82
  83 In this case all the messages sent by each process get received by all the
  84 other processes (IPN_BROADCAST).
  85 The processes need to be able to receive data when there are pending packets,
  86 e.g. using poll/select and event driven programming or multithreading.
  87
  88 2- (One or) Some senders/many receivers
  89 The sender runs the following code:
  90
  91   struct sockaddr_un sun={.sun_family=AF_IPN,.sun_path="/tmp/sockipnvde"};
  92   int s=socket(AF_IPN,SOCK_RAW,IPN_BROADCAST);
  93   err=shutdown(s,SHUT_RD);
  94   err=bind(s,(struct sockaddr *)&sun,sizeof(sun));
  95   err=connect(s,NULL,0);
  96
  97 The receivers do not need to define the network, thus they skip the bind:
  98
  99   struct sockaddr_un sun={.sun_family=AF_IPN,.sun_path="/tmp/sockipnvde"};
 100   int s=socket(AF_IPN,SOCK_RAW,IPN_BROADCAST);
 101   err=shutdown(s,SHUT_WR);
 102   err=connect(s,(struct sockaddr *)&sun,sizeof(sun));
 103
 104 In the previous examples processes can send and receive every kind of
 105 data. When messages are ethernet packets (maybe from virtual machines), IPN
 106 works lile a Hub.
 107
 108 Different protocols (delivery policies) can be specified by changing
 109 IPN_BROADCAST with a different tag.
 110 A IPN protocol specific submodule must have been registered
 111 the protocol tag in advance. (e.g. when kvde_switch.ko is loaded
 112 IPN_VDESWITCH can be used too).
 113 The basic broadcasting protocol IPN_BROADCAST is built-in (all the
 114 messages get delivered to all the connected processes but the sender).
 115
 116 IPN sockets use the filesystem for naming and access control.
 117 srwxr-xr-x 1 renzo renzo 0 2007-12-04 22:28 /tmp/sockipnvde
 118 An IPN socket appear in the file like a UNIX socket.
 119 r/w permissions represent the right to receive from/send data to the
 120 socket. The 'x' permission represent the right to manage the socket.
 121 "Connect" automatically shuts down SHUT_WR or SHUT_RD if the user has not
 122 the correspondent right.
 123
 124 WHAT WE NEED FROM THE LINUX KERNEL COMMUNITY
 125 --------------------------------------------
 126 0- (Constructive) comments.
 127
 128 1- The "official" assignment of an Address Family.
 129 (It is enough for everything but interface grabbing, see 2)
 130
 131 in include/linux/net.h:
 132 - #define NPROTO          34              /* should be enough for now..  */
 133 + #define NPROTO          35              /* should be enough for now..  */
 134
 135 in include/linux/socket.h
 136 + #define AF_IPN 34
 137 + #define PF_IPN AF_IPN
 138 - #define AF_MAX          34      /* For now.. */
 139 + #define AF_MAX          35      /* For now.. */
 140
 141 This seems to be quite simple.
 142
 143 +-----
 144 |Note (2009 January): unfortunately it is not.
 145 |The Address Family #34 has been already assigned to AF_ISDN.
 146 |So, we'll continue using AF stealing of AF_NETBEI (13) until
 147 |we have an AF officially assigned. (we are not superstitious!)
 148 +-----
 149
 150 2- Another "grabbing hook" for the interface (like the ones already
 151 existing for the kernel bridge and for the macvlan).
 152
 153 In include/linux/netdevice.h:
 154 among the fields of struct net_device:
 155
 156         /* bridge stuff */
 157                                 struct net_bridge_port  *br_port;
 158                                 /* macvlan */
 159                                 struct macvlan_port     *macvlan_port;
 160 +        /* ipnvde */
 161 +        struct ipn_node        *ipn_port;
 162
 163                                 /* class/net/name entry */
 164                                 struct device           dev;
 165
 166 In net/core/dev.c, we need another "stanza" for grabbing packets....
 167 like the one defined for CONFIG_BRIDGE and CONFIG_MACVLAN.
 168 I can write the patch (it needs just tens of minutes of cut&paste).
 169 We are studying some way to register/deregister grabbing services,
 170 I feel this would be the cleanest way.
 171
 172 +-----
 173 |Note (2011 January): This issue seems to have been solved in 2.6.37
 174 | the new interface netdev_rx_handler_{register,unregister} can
 175 | be effectively used for ipn.
 176 +-----
 177
 178 WHERE?
 179 ------
 180 There is an experimental version in the VDE svn tree.
 181 WARNING/SUGGESTION: The code has not been extensively tested. It is safer
 182 to run it on virtual machines or experimental systems where a kernel panic
 183 or a forced reboot do not result in loss of data/service.
 184 The current implementation can be compiled as a module on linux >= 2.6.22.
 185 We have currently "stolen" the AF_RXRPC and the kernel bridge hook, thus
 186 this experimental implementation is incompatible with RXRPC and the kernel
 187 bridge (sharing the same data structure). This is just to show the
 188 effectiveness of the idea, in this way it can be compiled as a module
 189 without patching the kernel.
 190 We'll migrate IPN to its specific AF and grabbing hook as soon as they
 191 have been defined.
 192
 193 NOTE FOR UBUNTU USERS:
 194 If the compilation fails try:
 195 make CFLAGS="-DAPPARMOR"
 196
 197 renzo