controllers:rtd_dsxll_tng:multisite

Manages multi-site access to various RTD DSX LinkLayer connections.

This controller also allows the dynamic creation and management of different drivers which will typically be instances of rtd_dsxll_tng .

controllers:
  rtd_dsxll_tng.multisite:   [sites]

controller:
  rtd_dsxll_tng.multisite:
    sites:
      storage_ctx: /var/vertex/sites.db
      driver_name:   rtd_dsxll_tng
      dump_events:   True
      default_driver_conf:
        socket_timeout:          1
        manage_delay:            1
        on_demand:               True
        dump_events:             False
        LinkLayer:
          verbose:               False
        abstracts:
          0x01:                  [rtd.Ten,{debug: True, debug_tasks: True}]
 

The typical <controller_name> is just „sites“.

A <site_id> is a 8-char string which contains a hexadecimal presentation of the site-id like this „01020304“.

• /<controller_name>/
  • <site_id>/
    • con_setup - returns connection setup for selected site
    • con_state - connection runtime details
      • state - created | unconfirmed | connected | closed | waiting_for_connection
      • state_reason - contains possible error messages
      • t_first_connect - the very first connection time
      • t_confirmed - when did the site-ids fit?
      • t_last_sitecheck - when was the last site-id checking? (active mode only)
      • t_last_connect - last connection time
      • peer_address - contains a list of <ip>,<port> (passive mode only)
  • con_states - returns states of all sites (like <site_id>/con_state/state)

• /<controller_name>/
  • <site_id>/
    • con_setup - fallowing fields can be supplied as a dict
      • mode - „client“ | „server“
      • host - DSX IP address
      • port - DSX port
      • dsx_password - DSX password

• /<controller_name>/
  • add | data= {„site_id“:<site_id>,„port“:<int>,„host“:„“,„mode“:„client“|„server“,„dsx_password“:„12345“}
  • del | data= {„site_id“:<site_id>}
  • <site_id>/
    • del

• /<controller_name> - returns a list of all configured site-id's

read /sites/con_states
(None, {'6a000000': 'unknown', '67000000': 'connected', '98000000': 'connected'})

write /sites/02000000/con_setup {"dsx_password":"new-pass"}
(None, 1)

write /sites/02000000/con_setup {"host":"1.2.3.4"}
(None, 1)

Whenever a new site has been added, the controller first tries to check if the site-id fits and/or connection works. The site will be listed in /sites (you can do a list @ /sites) and will have the state „unknown“ at this point.

If the connection was successfull and the id fit's the site will be listed via read /sites/con_states and also the coresponding driver will be started.

It might be possible that site-id's change or somehow do not fit. In this case the site moves from confirmed state to unconfirmed.

The easiest way to check if the site-id has been confirmed is to check if (t_confirmed==0). If a site has been confirmed before but then becomes unconfirmed t_confirmed is resetted to 0.

read /sites/02030405/con_state/t_confirmed
(None, None)

read /sites/67000000/con_state/t_confirmed
(None, 1380892584)

The mode is related to the sites view.

In server mode, the site waits for an incomming connection, thus the server has to know about it's IP or hostname.

It is called client-mode when sites connect to the SDO. In this case, no hostname is required.