Add support for ModuleAnnouncement in Backends

[TimVinkemeier]

Add support for the new NetIP message types ModuleAnnouncement and ModuleAcknowledge to the existing backends (e.g. Ryu).

[TimVinkemeier]

This is how it works:

• The backend is started with a module
• The backend sends a ModuleAnnouncement message containing the name of the module (as defined in the CompositionSpecification) to the core
• The core maps that name to an unused integer ID (e.g. increment)
• The core replies with a ModuleAcknowledge message containing the name of the module and the moduleId field in the header set to the selected ID
• The backend stores that mapping for future reference

[doriguzzi]

The backend sends a ModuleAnnouncement message containing the name of the module (as defined in the CompositionSpecification) to the core

Any example?

[TimVinkemeier]

Register a firewall module called "fw" in the composition specification ([Header][Body]): Backend to core: [NetIDE Header with moduleId=<any value>, type=ModuleAnnouncement]["fw"] Core to Backend: [NetIDE Header with moduleId=<generated ID>, type=ModuleAcknowledge]["fw"]

[doriguzzi]

Do you have already defined an initial "dictionary" for the applications? E.g. fw=firewall, ls= learning switch etc.? If yes, where is it defined? Is there any configuration file in your sources?

[TimVinkemeier]

No, as I said, it is the name from the composition specification. "fw" was just an example of how a user might have named a firewall application. There is no dictionary, since that is user-defined.

[doriguzzi]

Ok, let me reformulate the question: is there already any available sample specification that I can use as an example and that people can use to test the Backend+Core+Shim? Since we want to provide the firewall and the learning switch as applications that can be used to test our framework, can we produce a sample specification with at least these two applications?

[TimVinkemeier]

Yes, available here: https://github.com/fp7-netide/Engine/blob/CoreImplementation/core/specification/CompositionSpecification.xml

[doriguzzi]

Done for the Ryu backend. For now I will use the original app name that I can get from objects.

[doriguzzi]

@TimVinkemeier : when waiting for the ModuleAcknowledge we receive two messages, the first is empty and the second contains the actual Ack. This is the output @sergiotamu is obtaining in the Ryu backend: ack_message: ['', '\x02\x05\x00\x0c\x00\x00\x00\x00\x00\x00\x01i\x00\x00\x00\x00\x00\x00\x00\x00SimpleSwitch']

Is it done on purpose?

[doriguzzi]

This is the way I send the Ack from my simple Core: backend.send_multipart([identity,ack_message]) and this is what the backend receives: ['\x02\x05\x00\x0c\x00\n\\p\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x00SimpleSwitch']

[TimVinkemeier]

@doriguzzi It seems to be a problem between different ZeroMQ implementations. I use JeroMQ (the pure-Java implementation) and when I send a multipart message, it has to look like <destinationID>,'',<message>. The empty string '' in between is necessary in JeroMQ to delimit the destination and the actual message. I guess your Python implementation does not require that, therefore you see the empty part...