Versions Compared

Old Version 9

changes.mady.by.user Unknown User (tross)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (tross)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 0.1 - 1/13/2014
  • 0.2 - 4/21/2014
  • 0.3 - 1/16/2015
    • Theme: Management and Stability
    • Jiras Resolved
    • Management and Configuration Features
    • Stability Features and Fixes

Planned Releases

  • 0.4 - Planned for March, 4/9/2015
    • Theme: Link Routing and Broker Integration
    • Jiras Resolved
    • Planned Features
      • Link-Attach routing - Remote broker access
      • Major improvements to the routing protocol
  • 0.5
    - 9/14/2015
    • Jiras
    • Features
      • Compatibility with Proton 0.10
      Planned Features
      • SASL Integration for Connectors and Listeners
      • Per-Connection management access for
        • SSL/TLS/en-clair
        • Endpoint certificates for SSL/TLS
        • SASL mechanism in-effect
        • Authenticated identity of client
      • Tracing and troubleshooting support for networks of routers

...

        • clients

Planned Releases

  • 0.6 - March, 2016
    • What's New in 0.6.0
    • Jiras
    • Planned Features
      • Router core update
        • Remove lock contention issue around routing data structures
        • Improved end-to-end flow control, protects from filling up output FIFOs
      • Adaptive balancing of routed anycast messages
      • Improved waypoint implementation
  • 0.7 - June, 2016
  • 0.8 - September, 2016

Feature Details

Link Cost in Route Computation

...

  • Asymmetric connection cost.

Currently Dispatch performs routing on delivered messages based on the address in the message's metadata.  There is a second mode of routing in which routing is performed on the link-attach command.  In this case, an attached link causes another link to be established along the next-hop connection to the destination.  The process is repeated until a serially connected set of links is established from node-to-node across the network.  The result is like a Virtual Circuit for AMQP.

...

  • There must be a determination as to when a link-attach should be routed and when it should be simply terminated in the router.
  • There needs to be a way to identify an endpoint connection as being the path to a particular node (the destination).  This could possibly be done by creating a "pilot" subscription (receiving link) that's sole purpose is to associate a node destination address with a connection/container.  It could also be done through provisioning (like a waypoint).
  • Forwarding logic must be added to propagate flow commands from consumer to producer.
  • Logic must be added that propagates link-loss/detach outward in both directions from the site of a failure.
xxx
Roadmap Items Requiring Description
  • Input buffer for producer-endpoints and waypoints
  • Adaptive/balanced delivery of messages to anycast destinations
  • Websocket encapsulation option for listeners
  • SASL integration for listeners and connectors
  • Expose AMQP Session in the container.h API
  • Establish a separate inter-router session for router-control messages
  • Establish a single, separate inter-router session for routed links
    • Consider a policy for inter-router sessions (i.e. QoS for routed links)
  • Architecture for destination lookup (for high scale)
    • Router plugin for address lookup
    • Distributed service for address lookup
  • Multi-tennancy
    • Partition management entity space by application (open.hostname)
    • Address translation based on application
  • Access Control
    • Policy enforcement based on (application, authentic id, address, action)
    • Policy storage and distribution
  • Plugin for Exchange/Binding-style routing
  • Policy expression and enforcement
  • Distributed/central management and provisioning
  • Improved scale for mobile addresses
  • Other access protocols