History

Meetings2011-03-17

Topics:
  • Michael ;)
  • Jan ;)
  • URIs...

Message Fragmentation

  • Only c++ right now
    • missing:
      • Python
      • Java
      • Common LISP
  • blocks of size 100k
  • recombination missing
  • Notification contains total number of blocks and number of current block
  • spread UNSAFE_MESS does not guarantee sequencing of messages -> recombination with ordering and waiting required in input port
  • What to do with missing messages (e.g. directly when starting a subscription there could be only the last half of a message received)
    • simple strategy: Timeout for finalization of a message to dispatch
  • Configuration of block size as a simple hack in current class...

Jan's Question Collection

Names

  • Event Payload: User data in an event
  • Wire Type: data type of serialized representation, e.g. bytes, has a language mapping
  • Wire Schema: schema of serialized data, descriptor, IDL?
    • dependent of wire type
  • Converter:
    • Currently only for event payload
    • serializes payload to wire type according to wire schema
    • and vice versa

Why Ports Bidirectional?

  • Sebastian: one implementation is enough based on common ground
  • Jan: Current scheme restricts usage cardinalities
  • Still could be useful in future

Should (Spread) Ports Know Who Is Receiving Data

  • Spread: group members
  • no sending would be required if there is no receiver
  • Sebastian: not important as usecase
  • Naming: requires a more global strategy to provide kind of membership information

How Much Functionality and Dynamics in Subscriptions?

  • updates of filters etc.
  • which changes of a subscription can or have to trigger naming events?
  • First iteration: subscriptions are immutable

Filter Whitelisting

  • Ports should mark which filter was already filtered in the port -> avoid filtering twice
  • two possibilities:
    1. filter knows which event to not filter by id
    2. external component knows which filters not to use
  • relevant: multiple in-ports for subscriber

Grundannahmen

Kern-Domänenobjekte:
  • 1 Bus: (m:n Kommunikation) über alle Transportmöglichkeiten in RSB, nur logisches Konstrukt, realisiert über Kombination mehrer Ports
  • Channel: Topic auf Bus mit m:n Kommunikation, Ist kein Pattern da er den Bus über Aggregation von Ports realisiert. Ports müssen vom Nutzer angegeben werden wenn noch kein Modell vorhanden ist. Hat einen global einschränkenden Scope-Filter. Besitzt n Listener.
  • Topic: Inhaltliche Einschränkung des Broadcast
  • Listener: Teilnehmer an einem Channel mit Filter Chain, entweder synchrones oder asynchrones empfangen (aktuell: Subscription), eindeutig identifizierbar im System
  • Informer: Schreibende Komponente auf Channel, eindeutig identifizierbar im System.
Pattern-Domänenobjekte:
  • Publisher: 1:n Kommunikation, könnte evtl. Garantie anbieten, dass er zuerst existiert
  • Subscriber: 1:n Empfänger