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

I'm having problems when trying to create "random" flows within the DIF.
My current scenario is that of 3 nodes (1, X and 2), similar to the SimpleRelay example (but replacing some modules with my own custom modules).
In the SimpleRelay example, all extreme nodes have an entry in the NeighborTable to their unreachable (directly) nodes (in my scenario, if I add manually in config or dynamically from the FWTabGenerator, the neighbor entries, it also works well).
The problem is that in a bigger scenario, we cannot have all nodes in the DIF with a NeighborTable containing entries to all other nodes as that is not scalable.

My question is, it's possible to create a flow to an IPC in the DIF of which we only know its IPCAddress (but the FWTable knows how to forward it) ? And how?

Discussion

  • gaixas1
    gaixas1
    2014-12-18

    • summary: Create flow any node within the DIF by address --> Create flow to any node within the DIF by address
     
  • Vladimír Veselý
    Vladimír Veselý
    2015-01-14

    This is definitely tricky. Current RINASim is using DIF Allocator as kind of magical oraculum, which knows everything about topology (through static configuration). I am seeing following options:

    We can easily update DA.NeighborTable functionality to contain "default neighbor" record in order to guarantee that during phase of Flow Allocation M_CREATE(flow) would reach its destination.

    This may work for certain topologies but for larger and more complex ones not. We are going to need "routing" + NSM working in order to have complete set of information about which names/addresses (APNs) are currently part of DIF and should we reach them.

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

    • status: open --> accepted
     
  • gaixas1
    gaixas1
    2015-01-14

    Well, I think that the best approach for now is for nodes to know where applications are (appName -> address) by static configuration each node knowing only apps with which it will connect (knowing all apps is not scalable). Then when a new flow is requested the src node will try to reach that app through the the know address using "routing", and if it can reach the destination app, then the flow is created.

    Having some NSM (distributed or centralized) in order to find destination addresses, at this moment is not necessary, and in the worst case, if needed, I suppose that we could use some "NSM" app in a known address, query it for addresses and add them dynamically into the node table.