Connection iteration is not done...

[Jens Buysse]

Dear all,

 

I’m relatively new to Omnet++ and I have the following problem. This is my module definition:

 

module DataCenter

{

    parameters:

        int numberofNodes;

        int DC_id;

        int P_Idle;

    gates:

        input in;

        output out; 

        inout toServer[numberofNodes];

    submodules:

        nodes[numberofNodes]: Server;

    connections:

        for  i=0..numberofNodes-1 {

            toServer[i] <--> nodes[i].port;

        }

}

 

simple Server

{

    parameters:

        int maxFlops;

        int P_idle;

        int P_Max;

    gates:

        inout port;

}

 

The thing is, that when I start my simulation, it states that the (only) DataCenter module does not have the gates connected :

 

Error in module cCompoundModule: Test (id=1) during network setup: Gate TEst.F.toServer$i[0] is not connected to sibling or parent module.

 

Thus this means my for loop in DataCenter is not run right? I inspect the module and the numberofNodes parm. is correct and the toServer array is initialized... only not connected.

 

For ref. this is my test network setup:

 

network Test

{

    parameters:

        int totalNumberLambdas;

        int waType; //FF

    submodules:

        A: GmplsRouter {

            parameters:

                @display("i=block/routing;p=70,335");

                address = 0;

                waType = waType;

                totalNumberLambdas = totalNumberLambdas;

 

        }

        B: GmplsRouter {

            parameters:

                @display("i=block/routing;p=70,76");

                address = 1;

                waType = waType;

                totalNumberLambdas = totalNumberLambdas;

 

        }

        C: GmplsRouter {

            parameters:

                @display("i=block/routing;p=235,76");

                address = 2;

                waType = waType;

                totalNumberLambdas = totalNumberLambdas;

 

        }

        D: GmplsRouter {

            parameters:

                @display("i=block/routing;p=235,335");

                address = 3;

                waType = waType;

                totalNumberLambdas = totalNumberLambdas;

 

        }

        E: Generator {

            parameters:

                @display("i=block/broadcast");

                address = 4;

 

 

 

        }

        F: DataCenter {

            parameters:

                DC_id = 5;

                @display("p=70,431");

        }

 

 

    connections:

        A.in++ <-- {  delay = 100ms; } <-- B.out++;

        A.out++ --> {  delay = 100ms; } --> B.in++;

 

 

        B.in++ <-- {  delay = 100ms; } <-- C.out++;

        B.out++ --> {  delay = 100ms; } --> C.in++;

 

        C.in++ <-- {  delay = 100ms; } <-- D.out++;

        C.out++ --> {  delay = 100ms; } --> D.in++;

 

        D.in++ <-- {  delay = 100ms; } <-- A.out++;

        D.out++ --> {  delay = 100ms; } --> A.in++;

 

        A.in++ <-- {  delay = 1ms; } <-- F.out;

        A.out++ --> {  delay = 1ms; } --> F.in;

 

}

[Rudolf Hornig]

Check the error message carefully: 

Error in module cCompoundModule: Test (id=1) during network setup: Gate TEst.F.toServer$i[0] is not connected to sibling or parent module.

This means that the error occurred while omnet was trying to create the Test (network). And it complains that you have not connected tha DataCenter's (F module) toServer gate to any other module. Which is true because only the "in" and "out" gates are connected:

   A.in++ <-- {  delay = 1ms; } <-- F.out;

   A.out++ --> {  delay = 1ms; } --> F.in;

So it is not a problem inside the DataCenter (i.e. the interation is done correctly), but a problem in Test netwok (that the toServer gates are not connected here).

Moreover, if you get rid of this problem, you will get an other error, because inside the DataCenter "in" and "out" are not connected and only toServer is connected. 

You should think again what you want to achieve because the current topology is incorrect.

Rudolf

--
You received this message because you are subscribed to the Google Groups "omnetpp" group.
To post to this group, send email to omn...@googlegroups.com.
To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/omnetpp?hl=en.

[Jens Buysse]

MM I'm not sure that this is the problem because:

(i) If the iteration would have been done, that the toServer gates
would be connected cfr.

for i=0..numberofNodes-1 {
toServer[i] <--> nodes[i].port;
}

(ii) The in and out gates of Datacenter are connected cfr.

A.in++ <-- { delay = 1ms; } <-- F.out;
A.out++ --> { delay = 1ms; } --> F.in;

It seems that in the construction of the module Datacenter, the
submoduled are not generated as I don't see them appear in the
inspector. Could this be the problem?

Kind regards

On 20 dec, 15:29, Rudolf Hornig <rudolf.hor...@gmail.com> wrote:
> Check the error message carefully:
>

> Error in module cCompoundModule: *Test* (id=1) during network setup: Gate

> TEst.F.toServer$i[0] is not connected to sibling or parent module.
>
> This means that the error occurred while omnet was trying to create the Test
> (network). And it complains that you have not connected tha DataCenter's (F
> module) toServer gate to any other module. Which is true because only the
> "in" and "out" gates are connected:
>
>    A.in++ <-- {  delay = 1ms; } <-- F.out;
>    A.out++ --> {  delay = 1ms; } --> F.in;
>
> So it is not a problem inside the DataCenter (i.e. the interation is done
> correctly), but a problem in Test netwok (that the toServer gates are not
> connected here).
>
> Moreover, if you get rid of this problem, you will get an other error,
> because inside the DataCenter "in" and "out" are not connected and only
> toServer is connected.
>
> You should think again what you want to achieve because the current topology
> is incorrect.
>
> Rudolf
>

> > omnetpp+u...@googlegroups.com<omnetpp%2Bunsu...@googlegroups.com>
> > .

[Rudolf Hornig]

On Mon, Dec 20, 2010 at 5:45 PM, Jens Buysse <bunzen...@hotmail.com> wrote:

MM I'm not sure that this is the problem because:

(i) If the iteration would have been done, that the toServer gates
would be connected cfr.

for  i=0..numberofNodes-1 {
           toServer[i] <--> nodes[i].port;
       }

Yes, they would be connected from the inside. But the error message is complaining that they are not connected from outside. Trust me. DataCenter has the following gates:

     gates:
         input in;
         output out;
         inout toServer[numberofNodes];

 

and they must be connected BOTH from inside and from outside. The topology is definitely not correct. Just try to answer the following question: if a packet arrives at the DataCenter's "in" gate (from the outside). Where does it go?

(ii) The in and out gates of Datacenter are connected cfr.

A.in++ <-- {  delay = 1ms; } <-- F.out;
  A.out++ --> {  delay = 1ms; } --> F.in;

yes, but the toServers[] gate is not connected and that's what the runtime complains about... (if you get past this error it will also complain about the in and out gates not connected (inside DataCenter)

 

It seems that in the construction of the module Datacenter, the
submoduled are not generated as I don't see them appear in the
inspector. Could this be the problem?

No, this is a consequence. The internals of the datacenter are created only *after* the outer (Test) module is successfully created. But initialization stops on the first error (which occurred in test) so it will never even try to create the modules inside datacenter.

Rudolf

 

To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.

[Jens Buysse]

Mm ok,

so my ID was that external communication between modules could be done
by the in / out gates of the Data Center Module, while communication
between the parent module and the submodules could be done by sing the
toServer / Server.port gate.

So when a message arrives in the Data Center (in an in port), it could
be directed to one of the toServer gates.. So sending messages from
one to another is possible, right?

I find it a weird constraint that every gate should be connected to a
module outside AND inside the parent module - what's the reasoning for
this?

And more important, how can I solve this? using the annotations?

Kind regards

Jens

On 20 dec, 19:09, Rudolf Hornig <rudolf.hor...@gmail.com> wrote:

> > <omnetpp%2Bunsu...@googlegroups.com<omnetpp%252Bunsubscribe@googlegroup s.com>

[Rudolf Hornig]

On Tue, Dec 21, 2010 at 10:48 AM, Jens Buysse <bunzen...@hotmail.com> wrote:

Mm ok,

so my ID was that external communication between modules could be done
by the in / out gates of the Data Center Module, while communication
between the parent module and the submodules could be done by sing the
toServer / Server.port gate.

Here is the slip. There is no such thing as communication between the compound module and its submodules. The compound module does not have any code so it cannot provide any behavior. You can picture it as a simple box drawn around your submodules. Any connection that crosses the boundary of a compound module must go through a gate defined on the compound module. Because of this, the port must be connected on both inside and outside...

 

So when a message arrives in the Data Center (in an in port), it could
be directed to one of the toServer gates.. So sending messages from
one to another is possible, right?

I see your intention, however the next question: Once something arrives on the "in" port, how your model decide which Server should receive it? This is a routing problem and you have to have some C++ code somewhere in your model. And C++ should be put into a simple module.

 

I find it a weird constraint that every gate should be connected to a
module outside AND inside the parent module - what's the reasoning for
this?

 

See above. Compound modules are just boxes around a bunch of simple modules. They cannot process the messages, so obviously without any processing capability something that comes in, must go out on the other side...

 

And more important, how can I solve this? using the annotations?

Inside your Datacenter you will need a Routing submodule which contains the decision logic. It will have an "inout" gate that is connected to the compound modules input/output gate from inside. In addition it will have also a gate array connecting to the server modules. (i.e. it would have the same gate structure that your current compound module has). On the other hand the compound module needs ONLY an input/output gatepair, which is connected from the inside to the Router module. 

And one additional hint: If your connections are always symmetric, you should rather use "inout" (i.e. bidirectional gates). It simplifies the NED file because you do not have to duplicate all connection in both direction.

Rudolf

 

To unsubscribe from this group, send email to omnetpp+u...@googlegroups.com.

[Jens Buysse]

Ok now I see my problem,

I got the concept from Omnet wrong, as I thought that a compound
module could be implemented, and that it's submodules could be
returned in a sort of array or vector or something.

Ok I shall restructure the program than ! Thanks a lot for your
comments solution !

Kind regards

Jens Buysse

[iteb iteba]

I Have the same problem can you help me please

[iteb iteba]

This is my code 

netwk.ned:

//

// This program is free software: you can redistribute it and/or modify

// it under the terms of the GNU Lesser General Public License as published by

// the Free Software Foundation, either version 3 of the License, or

// (at your option) any later version.

// 

// This program is distributed in the hope that it will be useful,

// but WITHOUT ANY WARRANTY; without even the implied warranty of

// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

// GNU Lesser General Public License for more details.

// 

// You should have received a copy of the GNU Lesser General Public License

// along with this program.  If not, see http://www.gnu.org/licenses/.

// 

//

// TODO documentation

//

import inet.world.radio.ChannelControl;

//

// TODO documentation

//

simple ordinateur 

{ parameters:

    @display("i=block/routing");

    gates:

        inout gate[];

}

network netwk

{

    parameters:

     //   int hosts;

       // @display("bgb=659,213");

        //@display("bgb=909,238");

    types:

        channel Channel extends ned.DelayChannel

        {

            delay = 100ms;

        }

    submodules:

        channelControl: ChannelControl;

        ordinateur2: Ordinateur {

            @display("p=263,58");

        }

        ordinateur1: Ordinateur {

            @display("p=352,146");

        }

   

       // ordinateur1.port[1].in

      //YELZEM BOUCLE ordinateur[0].out --> ordinateur[hosts].in;

        

       connections allowunconnected:

       

       

}

ordinateur.ned

//

// This program is free software: you can redistribute it and/or modify

// it under the terms of the GNU Lesser General Public License as published by

// the Free Software Foundation, either version 3 of the License, or

// (at your option) any later version.

// 

// This program is distributed in the hope that it will be useful,

// but WITHOUT ANY WARRANTY; without even the implied warranty of

// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

// GNU Lesser General Public License for more details.

// 

// You should have received a copy of the GNU Lesser General Public License

// along with this program.  If not, see http://www.gnu.org/licenses/.

// 

//

// TODO auto-generated module

//

module Ordinateur

{

    

        

    parameters:

        //string protocol;       // protocol to use: "UDP" / "IP" / "ICMP" / ...

        //int destAddress;       // destination address

        //volatile double sendInterval @unit(s) = default(exponential(1s));

                               // time between generating packets

        //volatile int packetLength @unit(byte) = default(100B);

                               // length of one packet

      //  volatile int timeToLive = default(32);

                               // maximum number of network hops to survive

        //int adressMaC_ @prompt("5E:FF:56:A2:AF:15");

      //  int CPU_ @unit(Gbps) = default(2Gbps);

    //    volatile int debit_ @unit(Mbps) = default(1Mbps);

  //      volatile int charge_ @unit(min) = default(15min);

        volatile bool qualit_ @enum(false,true);

      //  volatile double vitesse_ @unit(Mbps)=default(80);

        @display("bgb=835,360");

gates:

    //inout port[];

input in[2];

output out[2];

    submodules:

       // ac_wlan: HostAutoConfigurator {

         //   @display("p=171,335");

        //}

ser1:Ser1;       

}