#16 Abstract Modules on IPCProcess

1.0
accepted
gaixas1
None
2015-01-14
2014-12-18
gaixas1
No

We want to do:
Be able to select what module should be loaded for common tasks of IPCprocesses.

Problems that we currently find in RinaSim:
Currently, modules of the IPC process are "fixed" on ned files so we have to create new ned files in order to replace them.
E.g. For test on routing I'm using a Host with two types of IPCProcesses. A Level 0 IPCProcess (the already existing) and a level 1 IPCProcess that uses a new PDUForwardingTable and PDUFwdTabGenerator modules. In order to do that, I had to create not only the new ned files for the new modules, but a new IPCProcess and ResourceAllocator ned file in order to link all this.
Also, as the new modules (in c++) needs to extend the previous existing classes in order to be loaded without modification in other classes, as the originals are not abstract, then there is some problems, like all unused variables or that functions like PDUForwardingTable::lookup needs to be changed to virtual.

Proposed modifications/extensions:
I propose to, like with Apps, make modules susceptible to be modified depending on policies. So for example, in the ResourceAllocator.ned change:

pduForwardingTable: PDUForwardingTable
pduFwdTabGenerator: PDUFwdTabGenerator
to
pduForwardingTable: : <fwtType> like PDUForwardingTable
pduFwdTabGenerator: <fwtgType> like PDUFwdTabGenerator

And create the abstract classes as needed (adding the current existing modules as default actions).

Given that, we can then simply set in the ini files the correct module needed in each case.

Discussion

  • gaixas1
    gaixas1
    2014-12-18

    • Description has changed:

    Diff:

    --- old
+++ new
@@ -12,8 +12,8 @@
 <i>pduForwardingTable: PDUForwardingTable
 pduFwdTabGenerator: PDUFwdTabGenerator</i>
 to 
-<i>pduForwardingTable: : <fwtType> like PDUForwardingTable
-pduFwdTabGenerator: <fwtgType> like PDUFwdTabGenerator</i>
+<i>pduForwardingTable: : &lt;fwtType&gt; like PDUForwardingTable
+pduFwdTabGenerator: &lt;fwtgType&gt; like PDUFwdTabGenerator</i>

 And create the abstract classes as needed (adding the current existing modules as default actions).
     
    Link

  • Tomáš Hykel
    Tomáš Hykel
    2014-12-18

    Hello,

    I'm assuming you're talking about the current master branch where PDUFwdTabGenerator is still an empty placeholder module. Kewin Rausch from CREATE-NET is currently working on implementation of PDUFTG in a separate branch and the plan is to merge those changes at some point.

    The solution you are describing certainly could be done, but it seems like a bit of an overkill and a lot of extra work for future users; as far as I know, Kewin separates some parts of PDUFTG (and maybe even PDUFT) into policies, so I have a feeling this could be enough for your needs!

    I'm going to ask him to comment on this.

     
    Link

  • gaixas1
    gaixas1
    2014-12-18

    Ok. Yes, I was talking about the current master branch.
    If it is being separated into policies then it should work (I didn't say that possibility as that would be a bigger change at short-term, but the best approach in this case.)

    Thanks.

     
    Link

  • Kewin Rausch
    Kewin Rausch
    2014-12-18

    Actually the forwarding branch of rina simulator has a framework for the forwarding stuff which will allows in the future to implement your own policy(or use one of the policies which will be included in the simulator).

    The framework has been developed in a way that allow to notify events occurring in the IPC Process(such as Flow allocation/Flow destruction/Flow state updates recevied) to the selected forwarding policy, which will decide what to do in such case(care about it or update the forwarding table usually following its logic).

    At the end, when all will be ready, you will be able to select a custom/standard policy per IPC Process, or change it at runtime.

    Such functionality is under test and will be merged in the master branch in the near future.

     
    Link

  • gaixas1
    gaixas1
    2014-12-18

    ok, perfect

     
    Link

  • Vladimír Veselý
    Vladimír Veselý
    2015-01-14

    Nevertheless, creation of interfaces and abstract classes for NED and C++ implementation is needed feature for whole RINASim. We know about this issue since beginning but is easier for us to prototype functionality and THEN pulling out interfaces and abstract classes when we already know what is the responsibility of each module.

     
    Link

  • Vladimír Veselý
    Vladimír Veselý
    2015-01-14

    • status: open --> accepted
     
    Link