• Kirill Smelkov's avatar
    xnet/pipenet: Generalize it into xnet/virtnet · 40120cb0
    Kirill Smelkov authored
    As we are going to implement another virtual network it would be good to
    share common code between implementations. For this generalize pipenet
    implementation to also cover the case when one does not own full network
    and owns only some hosts of it.
    
    An example of such situation is when one process handles one group of
    virtual hosts and another process handles another group of virtual
    hosts. Below a group of virtual hosts handled as part of network is
    called subnetwork.
    
    If hosts are not created in one place, we need a way to communicate
    information about new hosts in between subnetworks. This leads to using
    some kind of "registry" (see Registry interface).
    
    Then for the common code to be reused by a virtual network
    implementation it has to provide its working in the form of Engine
    interface to that common code. In turn the common code exposes another
    - Notifier - interface for particular network implementation to notify
    common code of events that come from outside to the subnetwork.
    
    Pipenet is reworked to be just a client of the common virtnet
    infrastructure.
    
    Virtnet documentation follows:
    
    """
    Package virtnet provides infrastructure for TCP-like virtual networks.
    
    For testing distributed systems it is sometimes handy to imitate network of
    several TCP hosts. It is also handy that ports allocated on Dial/Listen/Accept
    on that hosts be predictable - that would help tests to verify network
    events against expected sequence.
    
    Package virtnet provides infrastructure for using and implementing such
    TCP-like virtual networks.
    
    Using virtnet networks
    
    Addresses on a virtnet network are host:port pairs represented by Addr.
    A network conceptually consists of several SubNetworks each being home for
    multiple Hosts. Host is xnet.Networker and so can be worked with similarly
    to regular TCP network access-point with Dial/Listen/Accept. Host's ports
    allocation is predictable: ports of a host are contiguous integer sequence
    starting from 1 that are all initially free, and whenever autobind is
    requested the first free port of the host will be used.
    Virtnet ensures that host names are unique throughout whole network.
    
    To work with a virtnet network, one uses corresponding package for
    particular virtnet network implementation. Such packages provide a way to
    join particular network and after joining give back SubNetwork to user.
    Starting from SubNetwork one can create Hosts and from those exchange data
    throughout whole network.
    
    Please see package lab.nexedi.com/kirr/go123/xnet/pipenet for particular
    well-known virtnet-based network.
    
    Implementing virtnet networks
    
    To implement a virtnet-based network one need to implement Engine and Registry.
    
    A virtnet network implementation should provide Engine and Registry
    instances to SubNetwork when creating it. The subnetwork will use provided
    engine and registry for its operations. A virtnet network implementation
    receives instance of Notifier together with SubNetwork when creating it. The
    network implementation should use provided Notifier to notify the subnetwork
    to handle incoming events.
    
    Please see Engine, Registry and Notifier documentation for details.
    """
    
    Another virtnet-based network that is not limited to be used only in 1
    OS process will follow next.
    40120cb0
interfaces.go 7.51 KB