From Grid-Appliance Wiki

Jump to: navigation, search

This is old and needs updating.


Where To Get IpopNode and Its Dependencies

IPOP Requires the following:

  1. An IPOP binary release or the Brunet and IPOP Sources, see IPOP#Software:_Current_Release
  2. TAP device, see Tap_Device
  3. On Linux, Mono and gcc, see How_to_install_gcc_and_mono_on_Linux
  4. On Windows, .NET and either a precompiled dll (which it comes with it) or a native C compiler
  5. On Linux, resolvconf can be used to improve the handling of nameservers (and hence your /etc/resolv.conf file), see How_to_install_resolvconf_on_Linux.

If you chose a source bundle, run nant in the base directory of ipop to compile the entire project including BasicNode.

What Is IpopNode?

IpopNode is an abstract class that provides virtualization of IP over Peer to Peer links provided by the Brunet library. Ipop requires an inherited class to support the mechanisms for IP Address to Brunet Address binding, DHCP, DNS, Multicast, and other features. The most commonly used version of IpopNode is DhtIpopNode, other ones include CondorIpopNode, and RpcIpopNode. The rest of this document details deploying your own virtual network.

How to Deploy IPOP

IPOP requires an a P2P Overlay to connect to in order to support connectivity. To deploy your own please see the BasicNode Readme. To use our own, see Current Free-to-Join Brunet Overlays. Afterwards continue on in this document.

Choosing an IpopNode

In most scenarios, DhtIpopNode will be the recommended format for using Ipop. The DhtIpopNode requires limited amount of extra work as opposed to the RpcIpopNode and it allows users to specify their own hostname unlike CondorIpopNode. The only difference between DhtIpopNode and CondorIpopNode is that the former uses the Dht for hostnames, where as the latter uses statically mapped address.

In this document, deploying only Dht and Condor IpopNode will be reviewed.

Deploying DhtIpopNode and CondorIpopNode

To deploy a DhtIpopNode or CondorIpopNode, follow these steps:

  1. Configure a DHCPConfig
  2. Insert it into the Dht
  3. Configure an IpopConfig xml file
  4. Run the IpopNode

DHCP Setting Up the Dht DHCP Server

In order for DHCP to work with DhtIpopNode and CondorIpopNode, a DHCPConfig needs to be inserted into the DHT first. An example is provided in the config/dht_dhcp_namespace. It is important to keep the document free of white space as the dht is limited to 1024 bytes per entry.

Below is a sample DHCPConfig in XML format:


Now line by line...

The first entry is the Namespace, this refers to an Ipop Namespace and is distinct from BrunetNamespace. This naming convention allows us to have multiple DhtIpopNode pools in the same Brunet infrastructure.


Next is address allocation, specifying addresses to use in the pool and the netmask. Sometimes users may want the netmask to be larger than the pool, if they want to use static IP Addresses (which is not supported in DhtIpopNode).


In some cases, there are need for Reserved IP Addresses and its easier to do this method than specify a netmask that is larger than the pool allocation.


This specifies in seconds how long a DHCP Lease will last. Leases are reacquired beginning after the lease half life. Making this too small can unnecessarily increase dht activity and making this too big leads to a possibility of a value being lost from the Dht. 60 minutes is more than safe.


At this point you are ready to deploy your DhtDHCPServer, which is as easy as entering the data in to the dht. To do that, we will make use of the bput.py script (provided in the scripts directory). Remember to re-insert the item into the dhcp at the half-life of your ttl, the input should be the dhcp server config file without whitespace, and the last "Generic" should be replaced by your namespace.

python bput.py --ttl=3600 --input=dhcpconfig.xml dhcp:ipop_namespace:Generic

Dht/Condor Multicast

By enabling mutlicast, all nodes subscribing to multicast in your pool will receive any out going multicast packets originating from you and you will receive all out going multicast packets originating in your pool. This emulates the behavior on a Layer 2 network. You will still need to use the standard socket multicast practice to take advantage of multicast.

Dht Hostnames

By specifying a hostname, your node will be accessible to other users in the pool at your_hostname.ipop. Hostnames are unique per pool and so there will be no name collision between nodes in different pools.

Condor Hostnames

Condor hostnames are well documented here.


Ipop requires an IpopConfig xml file in addition to the NodeConfig xml file. Below is a sample config followed by a description of the fields.


IpopNamespace must match the namespace specified in the DHCPConfig.


This is the name of the Tap device running on your host.


This is an empty AddressData node with Hostname filled in. This gives the node the name Example.ipop. AddressData will fill-in after the first run of Ipop.


By enabling multicast, you will be able to receive and send multicast packets.


RunningIpop Running IpopNode

After configuring your environment, you are ready to begin using your IpopNode. IpopNode needs to be run as root in Linux or be the user of the tap device. In Windows, there is a possibility that a firewall message may pop-up asking permission to allow Ipop to work, please accept it.

To use Ipop on Linux run:

mono IpopNode.exe node.config ipop.config &> logs &
dhclient tapipop

In Windows run (no dhcp necessary, Windows automatically starts the dhcp client):

IpopNode.exe node.config ipop.config

Once an IP Address is assigned, you may begin communicating with remote nodes.

Personal tools