TASTE bugtrack - Taste
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000082Taste[All Projects] PolyORB-HI-Allpublic2011-01-12 10:452011-02-07 19:32
Reportermaxime 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Summary0000082: Add runtime configuration for communication drivers
DescriptionAdd a mean to configure network configuration from the user code. For example, the IP address and port number could be determined dynamically rather than being fixed in the AADL code. Expected benefit: allow users to build native client-server applications with minimal effort Specifying the possibility for a driver to be reconfigured at runtime should be a feature of the ASN.1 model of the driver configuration. Eg. Available-devices ::= ENUMERATED { eth0, eth1 } Ethernet ::= SEQUENCE { default-device Available-devices, port INTEGER (0..65535), ip IA5String (SIZE (3..11)), reconfigurable BOOLEAN } Then when the user sets the Ethernet values in the Deployment view he would write: { default-device eth0, port 80, ip "192.168.1.1", reconfigurable true } In addition to Send and Receive, the driver should in turn contain some form of reconfiguration API, of course.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-01-12 10:45maximeNew Issue
2011-01-12 11:13huguesNote Added: 0000229
2011-02-07 16:56user2Note Added: 0000294
2011-02-07 19:32maximeNote Added: 0000295

Notes
(0000229)
hugues   
2011-01-12 11:13   
Reconfiguration is a complex best: if you change parameters for node B, then all nodes connected to B shall be aware of that, and be also reconfigured. This is costly to support and requires application-wide consensus. Hence, I'm not favorable to support dynamic reconfiguration: we should clearly specify what we can support at a decent cost. I agree it would be nice to set configuration parameters when starting the application, but once it is started, we should not allow for it, except in error handlers for instance: if connection to B crash with one connection, give the possibility to use another channel, but even in this case, stability of the system is complex to preserve
(0000294)
user2   
2011-02-07 16:56   
I think we can close this issue since the driver configuration using ASN.1 would be the reference configuration directive.
(0000295)
maxime   
2011-02-07 19:32   
We should keep the discussion open. The points from Jerome have to be investigated. Reconfiguration at runtime is something we will need because this is something which happens in embedded systems: we loose a communication line, we switch to another. At the moment we have no possibility to define protocols for the establishment of communication between two nodes, so as soon as one dies, the others die too and the system becomes unrecoverable. It is likely that we will use the new ASN.1 configuration mechanism to specify some additional properties for a given interface, but that does not solve everything - not the protocol specification.