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
Loading...