Wiki » History » Version 37
Version 36 (J. Wienke, 11/10/2010 11:27 AM) → Version 37/271 (J. Wienke, 11/10/2010 11:27 AM)
h1. Wiki
h2. Dependencies
* RSC, see RSC Project at Code.CoR-Lab
* boost::uuid (can be installed from GAR installer, contrib/boost.uuid or is contained in newer boost versions)
* boost::threadpool (can be installed from GAR installer, contrib/boost.threadpool, will probably be replaced by RSC threadpool implementation)
* spread for spread port (lucid ubuntu package does not work as it is still an old version, can be installed through GAR installer, contrib/spread)
* Google protocol buffers (lucid ubuntu package works, can also be installed from GAR installer, contrib/protobuf)
* Doxygen for documentation generation (ubuntu package)
* lcov for coverage report (ubuntu package)
h2. Meeting 2010-11-10
* Sequencing:
** Spread-specific: -> sequencing only in spread port, remove sequencing stuff from Notification.proto, add second message type only with sequencing information wrapped around serialized Notification
** Parallelization of sequencing to reduce send and receive times
* Quality-of-Service:
** Ordered notifications required
** Ports are responsible, because spread e.g. already can order notifications -> why order by hand here?
** Extract manual logic for ordering to be reusable
** Where is the desired service type specified?
*** Probably statically in a global system configuration... later
*** Simple solution right now: QoS-Objekt set at publisher with port observing the publisher, or pub sets the QoS in the port with error if not supported
**** Later maybe also QoS specification at subscriber
** Current QoS-Types:
*** Unordered
*** Ordered per Subscriber-Publisher pair
* Distributed Nameservice:
** Event-based telling what's going on on each logical message bus
** May be replaced with a static system model, but not required
* URL scheme:
** Hashing of URLs
** Service required to translate back between hashes to real URLs (nameservice)
** Hierarchy
* Performance testing:
** Throughput with spread
** Why jitter, how to avoid it? Is this only because of the hacked spread?
** Jitter would be bad for sequencing
* Tool support required
** Web-Server
** command-Line tools for introspection
** Implemented as MVC-Pattern with different views
* Type to data mapping in C++
** Use RTTI?
** Benchmark Performance
** Current steps:
*** Use RTTI to simplify generic interface
** later:
*** Maybe code generation from model with specific interfaces
*** Hierarchies of types currently ignored
h2. Dependencies
* RSC, see RSC Project at Code.CoR-Lab
* boost::uuid (can be installed from GAR installer, contrib/boost.uuid or is contained in newer boost versions)
* boost::threadpool (can be installed from GAR installer, contrib/boost.threadpool, will probably be replaced by RSC threadpool implementation)
* spread for spread port (lucid ubuntu package does not work as it is still an old version, can be installed through GAR installer, contrib/spread)
* Google protocol buffers (lucid ubuntu package works, can also be installed from GAR installer, contrib/protobuf)
* Doxygen for documentation generation (ubuntu package)
* lcov for coverage report (ubuntu package)
h2. Meeting 2010-11-10
* Sequencing:
** Spread-specific: -> sequencing only in spread port, remove sequencing stuff from Notification.proto, add second message type only with sequencing information wrapped around serialized Notification
** Parallelization of sequencing to reduce send and receive times
* Quality-of-Service:
** Ordered notifications required
** Ports are responsible, because spread e.g. already can order notifications -> why order by hand here?
** Extract manual logic for ordering to be reusable
** Where is the desired service type specified?
*** Probably statically in a global system configuration... later
*** Simple solution right now: QoS-Objekt set at publisher with port observing the publisher, or pub sets the QoS in the port with error if not supported
**** Later maybe also QoS specification at subscriber
** Current QoS-Types:
*** Unordered
*** Ordered per Subscriber-Publisher pair
* Distributed Nameservice:
** Event-based telling what's going on on each logical message bus
** May be replaced with a static system model, but not required
* URL scheme:
** Hashing of URLs
** Service required to translate back between hashes to real URLs (nameservice)
** Hierarchy
* Performance testing:
** Throughput with spread
** Why jitter, how to avoid it? Is this only because of the hacked spread?
** Jitter would be bad for sequencing
* Tool support required
** Web-Server
** command-Line tools for introspection
** Implemented as MVC-Pattern with different views
* Type to data mapping in C++
** Use RTTI?
** Benchmark Performance
** Current steps:
*** Use RTTI to simplify generic interface
** later:
*** Maybe code generation from model with specific interfaces
*** Hierarchies of types currently ignored