From 536c798699cadec5be2db9d055a9226c50b651f8 Mon Sep 17 00:00:00 2001 From: Enrico Faulhaber Date: Fri, 18 Oct 2019 14:09:06 +0200 Subject: [PATCH] Remove obsolete protocol specification The one at https://www.github.com/SampleEnvironment/SECoP is the correct version! Change-Id: I4f8a9c3b40ea4e1f3ecea8b7b491dd96cb04d009 Reviewed-on: https://forge.frm2.tum.de/review/c/sine2020/secop/playground/+/21437 Tested-by: JenkinsCodeReview Reviewed-by: Enrico Faulhaber Reviewed-by: Markus Zolliker --- doc/source/{playground => }/client/index.rst | 0 .../{playground => }/facility/demo/cryo.rst | 0 .../{playground => }/facility/demo/index.rst | 0 .../{playground => }/facility/demo/test.rst | 0 .../{playground => }/facility/ess/epics.rst | 0 .../{playground => }/facility/ess/index.rst | 0 .../{playground => }/facility/index.rst | 0 .../{playground => }/facility/mlz/amagnet.rst | 0 .../facility/mlz/entangle.rst | 0 .../{playground => }/facility/mlz/index.rst | 0 .../{playground => }/framework/datatypes.rst | 0 .../{playground => }/framework/errors.rst | 0 .../{playground => }/framework/index.rst | 0 doc/source/{playground => }/gui/index.rst | 0 doc/source/index.rst | 12 +- doc/source/playground/index.rst | 13 - .../playground/server/protocol/encoding.rst | 6 - .../server/protocol/framing/demo.rst | 7 - .../server/protocol/framing/eol.rst | 6 - .../server/protocol/framing/index.rst | 11 - .../server/protocol/framing/null.rst | 6 - .../server/protocol/framing/rle.rst | 6 - doc/source/protocol/commands.rst | 22 - doc/source/protocol/datatypes.rst | 173 ---- doc/source/protocol/descjson.rst | 11 - doc/source/protocol/descprop.rst | 48 - .../protocol/diagram/module_description.png | Bin 4467 -> 0 bytes .../protocol/diagram/module_property.png | Bin 8080 -> 0 bytes doc/source/protocol/diagram/properties.png | Bin 4362 -> 0 bytes doc/source/protocol/diagram/property.png | Bin 2053 -> 0 bytes .../protocol/diagram/sec_node_description.png | Bin 4529 -> 0 bytes .../protocol/diagram/sec_node_property.png | Bin 6507 -> 0 bytes doc/source/protocol/heartbeat.rst | 8 - doc/source/protocol/hierarchy.rst | 9 - doc/source/protocol/history.rst | 73 -- doc/source/protocol/index.rst | 22 - doc/source/protocol/issue_1.rst | 27 - doc/source/protocol/issue_10.rst | 45 - doc/source/protocol/issue_2.rst | 22 - doc/source/protocol/issue_3.rst | 47 - doc/source/protocol/issue_4.rst | 18 - doc/source/protocol/issue_5.rst | 34 - doc/source/protocol/issue_6.rst | 23 - doc/source/protocol/issue_7.rst | 24 - doc/source/protocol/issue_8.rst | 15 - doc/source/protocol/issue_9.rst | 39 - doc/source/protocol/jsonstruct.rst | 92 -- doc/source/protocol/meeting_2017_11_27.rst | 240 ----- doc/source/protocol/messages.rst | 232 ----- doc/source/protocol/modsubset.rst | 8 - doc/source/protocol/motivation.rst | 18 - doc/source/protocol/notes.rst | 42 - doc/source/protocol/outdated.rst | 20 - doc/source/protocol/secop_v2017-09-14.rst | 924 ------------------ doc/source/protocol/timeformat.rst | 7 - doc/source/protocol/todo.rst | 101 -- .../{playground => }/server/configuration.rst | 0 doc/source/{playground => }/server/index.rst | 0 .../{playground => }/server/modules.rst | 0 .../server/protocol/index.rst | 2 - .../server/protocol/interface/index.rst | 0 .../server/protocol/interface/tcp.rst | 0 .../server/protocol/interface/zmq.rst | 0 .../{playground => }/server/starting.rst | 0 64 files changed, 7 insertions(+), 2406 deletions(-) rename doc/source/{playground => }/client/index.rst (100%) rename doc/source/{playground => }/facility/demo/cryo.rst (100%) rename doc/source/{playground => }/facility/demo/index.rst (100%) rename doc/source/{playground => }/facility/demo/test.rst (100%) rename doc/source/{playground => }/facility/ess/epics.rst (100%) rename doc/source/{playground => }/facility/ess/index.rst (100%) rename doc/source/{playground => }/facility/index.rst (100%) rename doc/source/{playground => }/facility/mlz/amagnet.rst (100%) rename doc/source/{playground => }/facility/mlz/entangle.rst (100%) rename doc/source/{playground => }/facility/mlz/index.rst (100%) rename doc/source/{playground => }/framework/datatypes.rst (100%) rename doc/source/{playground => }/framework/errors.rst (100%) rename doc/source/{playground => }/framework/index.rst (100%) rename doc/source/{playground => }/gui/index.rst (100%) delete mode 100644 doc/source/playground/index.rst delete mode 100644 doc/source/playground/server/protocol/encoding.rst delete mode 100644 doc/source/playground/server/protocol/framing/demo.rst delete mode 100644 doc/source/playground/server/protocol/framing/eol.rst delete mode 100644 doc/source/playground/server/protocol/framing/index.rst delete mode 100644 doc/source/playground/server/protocol/framing/null.rst delete mode 100644 doc/source/playground/server/protocol/framing/rle.rst delete mode 100644 doc/source/protocol/commands.rst delete mode 100644 doc/source/protocol/datatypes.rst delete mode 100644 doc/source/protocol/descjson.rst delete mode 100644 doc/source/protocol/descprop.rst delete mode 100755 doc/source/protocol/diagram/module_description.png delete mode 100755 doc/source/protocol/diagram/module_property.png delete mode 100755 doc/source/protocol/diagram/properties.png delete mode 100755 doc/source/protocol/diagram/property.png delete mode 100755 doc/source/protocol/diagram/sec_node_description.png delete mode 100755 doc/source/protocol/diagram/sec_node_property.png delete mode 100644 doc/source/protocol/heartbeat.rst delete mode 100644 doc/source/protocol/hierarchy.rst delete mode 100644 doc/source/protocol/history.rst delete mode 100644 doc/source/protocol/index.rst delete mode 100644 doc/source/protocol/issue_1.rst delete mode 100644 doc/source/protocol/issue_10.rst delete mode 100644 doc/source/protocol/issue_2.rst delete mode 100644 doc/source/protocol/issue_3.rst delete mode 100644 doc/source/protocol/issue_4.rst delete mode 100644 doc/source/protocol/issue_5.rst delete mode 100644 doc/source/protocol/issue_6.rst delete mode 100644 doc/source/protocol/issue_7.rst delete mode 100644 doc/source/protocol/issue_8.rst delete mode 100644 doc/source/protocol/issue_9.rst delete mode 100644 doc/source/protocol/jsonstruct.rst delete mode 100644 doc/source/protocol/meeting_2017_11_27.rst delete mode 100644 doc/source/protocol/messages.rst delete mode 100644 doc/source/protocol/modsubset.rst delete mode 100644 doc/source/protocol/motivation.rst delete mode 100644 doc/source/protocol/notes.rst delete mode 100644 doc/source/protocol/outdated.rst delete mode 100644 doc/source/protocol/secop_v2017-09-14.rst delete mode 100644 doc/source/protocol/timeformat.rst delete mode 100644 doc/source/protocol/todo.rst rename doc/source/{playground => }/server/configuration.rst (100%) rename doc/source/{playground => }/server/index.rst (100%) rename doc/source/{playground => }/server/modules.rst (100%) rename doc/source/{playground => }/server/protocol/index.rst (73%) rename doc/source/{playground => }/server/protocol/interface/index.rst (100%) rename doc/source/{playground => }/server/protocol/interface/tcp.rst (100%) rename doc/source/{playground => }/server/protocol/interface/zmq.rst (100%) rename doc/source/{playground => }/server/starting.rst (100%) diff --git a/doc/source/playground/client/index.rst b/doc/source/client/index.rst similarity index 100% rename from doc/source/playground/client/index.rst rename to doc/source/client/index.rst diff --git a/doc/source/playground/facility/demo/cryo.rst b/doc/source/facility/demo/cryo.rst similarity index 100% rename from doc/source/playground/facility/demo/cryo.rst rename to doc/source/facility/demo/cryo.rst diff --git a/doc/source/playground/facility/demo/index.rst b/doc/source/facility/demo/index.rst similarity index 100% rename from doc/source/playground/facility/demo/index.rst rename to doc/source/facility/demo/index.rst diff --git a/doc/source/playground/facility/demo/test.rst b/doc/source/facility/demo/test.rst similarity index 100% rename from doc/source/playground/facility/demo/test.rst rename to doc/source/facility/demo/test.rst diff --git a/doc/source/playground/facility/ess/epics.rst b/doc/source/facility/ess/epics.rst similarity index 100% rename from doc/source/playground/facility/ess/epics.rst rename to doc/source/facility/ess/epics.rst diff --git a/doc/source/playground/facility/ess/index.rst b/doc/source/facility/ess/index.rst similarity index 100% rename from doc/source/playground/facility/ess/index.rst rename to doc/source/facility/ess/index.rst diff --git a/doc/source/playground/facility/index.rst b/doc/source/facility/index.rst similarity index 100% rename from doc/source/playground/facility/index.rst rename to doc/source/facility/index.rst diff --git a/doc/source/playground/facility/mlz/amagnet.rst b/doc/source/facility/mlz/amagnet.rst similarity index 100% rename from doc/source/playground/facility/mlz/amagnet.rst rename to doc/source/facility/mlz/amagnet.rst diff --git a/doc/source/playground/facility/mlz/entangle.rst b/doc/source/facility/mlz/entangle.rst similarity index 100% rename from doc/source/playground/facility/mlz/entangle.rst rename to doc/source/facility/mlz/entangle.rst diff --git a/doc/source/playground/facility/mlz/index.rst b/doc/source/facility/mlz/index.rst similarity index 100% rename from doc/source/playground/facility/mlz/index.rst rename to doc/source/facility/mlz/index.rst diff --git a/doc/source/playground/framework/datatypes.rst b/doc/source/framework/datatypes.rst similarity index 100% rename from doc/source/playground/framework/datatypes.rst rename to doc/source/framework/datatypes.rst diff --git a/doc/source/playground/framework/errors.rst b/doc/source/framework/errors.rst similarity index 100% rename from doc/source/playground/framework/errors.rst rename to doc/source/framework/errors.rst diff --git a/doc/source/playground/framework/index.rst b/doc/source/framework/index.rst similarity index 100% rename from doc/source/playground/framework/index.rst rename to doc/source/framework/index.rst diff --git a/doc/source/playground/gui/index.rst b/doc/source/gui/index.rst similarity index 100% rename from doc/source/playground/gui/index.rst rename to doc/source/gui/index.rst diff --git a/doc/source/index.rst b/doc/source/index.rst index 72ea416..46a1f63 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -1,12 +1,14 @@ -Welcome to SECoP's documentation! -================================= +Welcome to FRAPPY documentation! +================================ .. toctree:: :maxdepth: 2 - protocol/index - playground/index - + server/index + client/index + framework/index + gui/index + facility/index Indices and tables diff --git a/doc/source/playground/index.rst b/doc/source/playground/index.rst deleted file mode 100644 index b829df7..0000000 --- a/doc/source/playground/index.rst +++ /dev/null @@ -1,13 +0,0 @@ -Playground documentation -======================== - -.. toctree:: - :maxdepth: 2 - - server/index - client/index - framework/index - gui/index - facility/index - - diff --git a/doc/source/playground/server/protocol/encoding.rst b/doc/source/playground/server/protocol/encoding.rst deleted file mode 100644 index 642c681..0000000 --- a/doc/source/playground/server/protocol/encoding.rst +++ /dev/null @@ -1,6 +0,0 @@ -SECoP Encoding -============== - -.. automodule:: secop.protocol.encoding.secop - :members: - diff --git a/doc/source/playground/server/protocol/framing/demo.rst b/doc/source/playground/server/protocol/framing/demo.rst deleted file mode 100644 index 2f74dba..0000000 --- a/doc/source/playground/server/protocol/framing/demo.rst +++ /dev/null @@ -1,7 +0,0 @@ -Demo -==== - -.. automodule:: secop.protocol.framing.demo - :members: - - diff --git a/doc/source/playground/server/protocol/framing/eol.rst b/doc/source/playground/server/protocol/framing/eol.rst deleted file mode 100644 index 43f2933..0000000 --- a/doc/source/playground/server/protocol/framing/eol.rst +++ /dev/null @@ -1,6 +0,0 @@ -EOL -=== - -.. automodule:: secop.protocol.framing.eol - :members: - diff --git a/doc/source/playground/server/protocol/framing/index.rst b/doc/source/playground/server/protocol/framing/index.rst deleted file mode 100644 index 43c7659..0000000 --- a/doc/source/playground/server/protocol/framing/index.rst +++ /dev/null @@ -1,11 +0,0 @@ -Framings -======== - -.. toctree:: - :maxdepth: 3 - - demo - eol - null - rle - diff --git a/doc/source/playground/server/protocol/framing/null.rst b/doc/source/playground/server/protocol/framing/null.rst deleted file mode 100644 index 1816b44..0000000 --- a/doc/source/playground/server/protocol/framing/null.rst +++ /dev/null @@ -1,6 +0,0 @@ -Null -==== - -.. automodule:: secop.protocol.framing.null - :members: - diff --git a/doc/source/playground/server/protocol/framing/rle.rst b/doc/source/playground/server/protocol/framing/rle.rst deleted file mode 100644 index 6083b3e..0000000 --- a/doc/source/playground/server/protocol/framing/rle.rst +++ /dev/null @@ -1,6 +0,0 @@ -RLE -=== - -.. automodule:: secop.protocol.framing.rle - :members: - diff --git a/doc/source/protocol/commands.rst b/doc/source/protocol/commands.rst deleted file mode 100644 index 434bf1e..0000000 --- a/doc/source/protocol/commands.rst +++ /dev/null @@ -1,22 +0,0 @@ -Commands -======== - -The "done" message should be returned quickly, the time scale should -be in the order of the time needed for communications. Actions which have -to wait for physical changes, can be triggered with a command. -The information about the success of such an action has to be transferred -via parameters, namely the status parameter. - -A command has at least the following properties: - -:description: - tell what this command does - -:arguments: - a list of datatypes for the command arguments (may be empty) - -:resulttype: - the type of the result (may be null) - - - diff --git a/doc/source/protocol/datatypes.rst b/doc/source/protocol/datatypes.rst deleted file mode 100644 index f2bf134..0000000 --- a/doc/source/protocol/datatypes.rst +++ /dev/null @@ -1,173 +0,0 @@ -Datatypes -========= - -double ------- - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["double"] *or* - | ["double", ] *or* - | ["double", , ] - | - | if is not given or null, there is no upper limit - | if is null or not given, there is no lower limit - - * - Transport example - - | 3.14159265 - - * - Datatype in C/C++ - - | double - -int ---- - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["int"] *or* - | ["int", ] *or* - | ["int", , ] - | - | if is not given or null, there is no upper limit - | if is null or not given, there is no lower limit - - * - Transport example - - | -55 - - * - Datatype in C/C++ - - | int64_t - -bool ----- - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["bool"] - - * - Transport example - - | true - - * - Datatype in C/C++ - - | int64_t - - -enum ----- - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["enum", { : , ....}] - - * - Transport example - - | 2 - - * - Datatype in C/C++ - - | int64_t - - -string ------- - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["string"] *or* - | ["string", ] *or* - | ["string", , ] - | - | if is not given, it is assumed as 255. - | if is not given, it is assumed as 0. - | if the string is UTF-8 encoded, the length is counting the number of bytes, not characters - - * - Transport example - - | "hello!" - - * - Datatype in C/C++ API - - | char \* - -blob ----- - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["blob", ] *or* - | ["blob", , ] - | - | if is not given, it is assumed as 0. - - * - Transport example - - | "AA==" (base64 encoded) - - * - Datatype in C/C++ API - - | struct {int64_t len, char \*data} - -array ------ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["array", , ] *or* - | ["array", , , ] - | - | if is not given, it is assumed as 0. - | the length is the number of elements - - * - Transport example - - | [3,4,7,2,1] - - * - Datatype in C/C++ API - - | [] - -tuple ------ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["tuple", [, , ...]] - - * - Transport example - - | [0,"idle"] - - * - Datatype in C/C++ API - - | struct - -struct ------- - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["struct", { : , : , ....}] - - * - Transport example - - | {"x": 0, "y": 1} - - * - Datatype in C/C++ API - - | struct - | - | might be null diff --git a/doc/source/protocol/descjson.rst b/doc/source/protocol/descjson.rst deleted file mode 100644 index 792f89b..0000000 --- a/doc/source/protocol/descjson.rst +++ /dev/null @@ -1,11 +0,0 @@ -Structure of the descriptive json -================================= - -* json = {"modules": , "properties": , ...} -* module = {"name": , "parameters": , "commands": , "properties": } -* parameter = {"name": ..., "properties": } -* command = {"name": ..., "properties": } -* property = {"name":, "datatype": , "value": } - -note: property may also be [,,] - diff --git a/doc/source/protocol/descprop.rst b/doc/source/protocol/descprop.rst deleted file mode 100644 index befcf45..0000000 --- a/doc/source/protocol/descprop.rst +++ /dev/null @@ -1,48 +0,0 @@ -Descriptive properties -====================== - -Mandatory descriptive properties --------------------------------- - -parameter-properties -++++++++++++++++++++ - -* name (implicit) -* datatype -* readonly (bool) - -module-properties -+++++++++++++++++ - -* interface_class [list_of_strings] (MAY be empty) - -SEC-Node-properties -+++++++++++++++++++ - -* no mandatory properties - -Optional descriptive properties -------------------------------- - -parameter-properties -++++++++++++++++++++ - -* unit (string), SHOULD be given if meaningful (if not given: unitless) (empty string: unit is one) -* description (string), SHOULD be given -* visibility -* group (identifier) (MUST start with an uppercase letter) (if empty string: treat as not specified) - -module-properties -+++++++++++++++++ - -* description (string), SHOULD be given -* visibility -* group (identifier) (MUST start with an uppercase letter) (if empty string: treat as not specified) -* meaning ??? -* importance ??? - -SEC-Node-properties -+++++++++++++++++++ - -* description (string), SHOULD be given - diff --git a/doc/source/protocol/diagram/module_description.png b/doc/source/protocol/diagram/module_description.png deleted file mode 100755 index 53c5019f32965cd1e4b239fe820baa04cb501ac3..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 4467 zcmZu#cQl)C-&ea@grBWOsz$BSicQm?cFdZQDoSHk?AmJ8rZi}j#;g&wYqT|r7)1rK zH#KXP65~yu^SsY_-gDk_pYy%%^SwUjy8pSppK-l1glf{$anX^Hkr>m(>cKP?o`&|5*)S>a#*4Lm}xXMb)OCb-=j3y&vV%1iEVCs+F zo(Xj|U3u5NckC7I+Y1hls|(XgDb$OhLnxTcV*@K^za9zsS*jDJGsM&U?WaM=8fVHg z&B}|ah;Nx0Fh37jg7{)Ghuypmk`U@1(T7>=ABwBTGqKy0gKt}eq$7&A(N33ZhLe-N zAvsz1?tiI_j2uuHJO~QBd)}Y*^UOH5dhvL1l+NV#hKy;FO_8mkOH+mrO9H^N^dYb} z1KC8D8h9*OC@R}MZf5jEdEK|U)I89ooT~0!)-RoWyR8>h4_wxQ3~DbO3J9^Ci-hRt za`PGUiqD!~p0<9Nj1m!M#t9CV& zdDWk2Lz-?cSSjGC0eNF&h4sp$h2{I%kabS4v6+jhyBkXuyW~p8k<>IXhxdbyG|s}l z3(^6*Qoxc%5{WY3k4%FOV^EjQ13B?dPNM`ln_%Vr{>!y5n`+iCpBzn@VgPpJC_EJ{ zQH2(}P{_)+GrL~tQl5+Q2?cqHB4E-6JST@|!9Js7Jv(=PAk?xTu~)AbUjrNwLozl~ zbIU*E%vGP7O`W=028(TGyRc?#Y`=M!?Ye0}E3HG`NcpH~)a&cTXqRm6d_b zGDE*)>}?POx(bKG?6QMK%o}aIP%}>gd26Qp3tU|uHnDt! zFco?%aj&ky^hzG*1oyvI@;RaG{Bf_Tz3n#pE%+v?|^NVA8etuL0G= zQ^0JHSaP5jj;cIBp$-6^*tebLC(DoDtK~P3Zcqa7RtgWH1#MMf zIm`ugFhRYfcsXWUDpt(hrE(ufQKGBw5}7h4j(|&=!xi<(C!Rc{axtRhXnbri#)4J~ z1#;EoSN5Q{-_#W7q&#Gj61CX$2ChI!II9|3c^C80jyPMQ`R$x)bm}evb!A8@R*;<| zJ*DQ=G3I#+Wp&4OjYOfkcva&cY^x(+@sO26Kf=}qa%6o6D=h_}0YA`dQ<$P*N*Wq+ zDewoC;CQY^yiv%JX(X6QPM5B1+EQ&l2T{yA4-I3%`)0hQezr23vdLZ+L72-35!9K<3MKzUAS1= z-O3OD<-L;?#1o4d2P8aKW(Uy$9T*y2BNgT0GlR@5gA_k&F^r$+uIpEy0-l4a1{A37 zm>$>M8Ua2LSC{PJMRF?aOHj1(+9uD%n~Uicmf#KLd{wAstnh9Ykr7Nc2TaA(Pg22> zCa>}`KC)uMaOqJ12n+312VkTKfEfp&HR8XO5(U73|IdVmi$?;eF!KXy@1D0oR=hVw zIYzSG3s=aaxySxkRL=8~X1dYonJT^aek$IFCBnETF@knE5M|8z*50+OMCzS)v(0GP zXV6%L)u5hVp^>yr^LQS}`-|{o=-pwLv;Ks~++5XgpT~7aLRc*^T^+BT(&mfBLXbYZ zSeHrRP=k1hTs*)@ip+r}JExy3r+m*S=k{%8Xpk8=R{m1>#H_R-Mz2KcOaOV>yEV7H zbLK{3b0q(<=;3?*9FPl$Weng^w#|_ z0WA$S*ArbXf1miQyN`Ib^sVks9&9TA?Kzo!|Fct924kGGCnS!K zpzkJcEKC(L$k3-=}|2weZQg$|Ir8tAPVej2sH`|mV8$=#E;?Jb`A#{z4lzEh+jz+9x_(x7~r^N-5jA`&&VH%YewSeHOWtikFc5{)kVG`eH+$Z zvJXksk^n0!G4*JW8BVVWj|2o5F*Gh{@tgmf_%~q52jh-+?upsltB|MRqcq2M|AVnW zXe16FD%x~=_X6eid2#xx8)ehj#=c*;6W^y3Jfo(M8ix#tZUV{6L9Kcmu!r{s*YBza zm>Al#KIcd2x-YAwIQ>f%_GRDwM-^tN^T{jwI$!2qj9Yjky{KZ52f#zn9xbW~v`Haao9r>5W?p}Sk{9hn} z-0G}^x4Q3r2guA!D0FkMg6!@dTIbx46*uXKGJ(<=i+Y=cLwTD%nc;y%y?wjd3bn>3 z<$F~$B|tSYz0D)+ zGnDY8p~^Bq9qnTAbu1WDFM$rU=|zUCOt5e%rf;2Ta>5n3$UAwQcSy%~I3GdYV`YyrqtDh%1-_qlBT>3kglHsAKKFW-8 z=tKqg{tC-wlp`UmO%gBXzBgccs^v#~Q|<5or44Z8e)pl4uNj3lwiOP2yu4x?a>Te9lrk91SLmkT>nB+g<%+3{rH^({h#XXay zDAvQ%Z;cruT3^urZk5n`d|cw)-~kkiq=2s@OI96rT*Baax@zFm@gGB3{pwV=O9t7ujgz)(xI*F~h z8J%KnwB5to`K?~|1**UEPlZ;O*V3u+^m#S&@Ty*<%t~Lkz`wvKC8l^w> zA_?ZV>&c3lHdYSFQCelwgl~btUE3pzjgtmqm{rA*A%_1TSrWXJ)64MgYzj zt;{63CndCmzQNxAY_(sWX?5OPB28itRi2za3AS#DZu@Ek35O-5=~JXbS~J?csXppk zpS?DDIrSpijM;K^Inma48Cd++F7a#gj;dto$vO`*9;s;6gCICpTkQj+^R=_4%d|He zAMBwC)(Q425K^noQJdta^lgfAxF;e%<}{`zwame^+8PhoF;zi{e)UshHKQ_dVMc9M zN=mGl5f0XJ4W`y2#K6tL#Pk)Flo-~wqso0hzO8?osi%GLZOaNv2etc<^zv_Wv2Mra zlHt=@+Orgm68#^-EzWw^caWivcK^#yHM$ZYQ7-t+;Vz2@K?W1X}41vKB z?u2#r%iUS?;6~n`$2;n4$%*b3(X4H*MAK}zM7a33+S)Edy1oI`cm+A*6)pa`3yrfx z1Lz^_I=UsZMw(ps4zi^#=2J#y`!Fo^Z3(SW3rQbtTwSIB?8Gy;O@0xR-_=K*^ZCzt z|E@YOaAa*#M17AS{@s(#2HxPKrC!m7_^#6c@$v&hxv$QX^)o1Hc>+)2`N&gh zJ5Rf+Ki?a3nFtx39pO@L3g?1!{p{Pt6URrnXi2r@p;z^>ctQD6Q?HIaFg2})ye)Rb z33J{NL(K1}Nv3Y9`CPo?!yjj-Ce`k#!t&wX78&kAc7SsOGdvVF@mn=uEg5epNm zn-+;xS>{d(>LdF|Grsh{k#|I&0DaIf=FQFa-ZpaoLK2lXZ<5oV@2S3rk4r{l+q4VQ zxv5xj_JXp84_piEShkjFpMP7p8;L8k8%&JIss=z}k;4D-Xb^HsS|D8{C8<$y)`tRS5!KjL>Juq{nU7hje#IH(PSGYF5LGe}|AED6xo2zr zHF%&O{&bhSI39oj2wun@DcWdCr-28;ND?_*E*m`k(^~?El}2G=xl2lF9Yk<*wLgi}GV!3RsUH8)Bu2`P zpmlHkP91Uu-J(}9BG%#EoQ*S&!MB?ZaSEA8-XakVkd9G4C_bDmkK3Pzkq7}|7zkz~ zw^H0jNEynUO5%-UmGKBadrIu^NEzsJG)7ES9XwFpj Hv5oj2e@C&y diff --git a/doc/source/protocol/diagram/module_property.png b/doc/source/protocol/diagram/module_property.png deleted file mode 100755 index 64acb6452b738565537919770bbd25a319bb8b02..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 8080 zcma)B2Q*ymx)!2D7g2)IlJINMdy5uAlqk{bAbRgL2}YM7L>Gw?!svaJWH1=L4G}~y zBN(ENa<}~V+;!Hu=iGH?)*5E-+3&l*Z@=Yvo;OxUOO=e6ffxq|hwO=(vMvq|ZY1#k zXCeaNGw|^h5AcV;MnhE@=j!_Xp{*npI6~<2L{o)u@fHmcGoHkw3oqrvKQI-4 zf{$Slz4VMKEZ4s;@67XD2i(78KdG~NhA2+&vPpX?F02rpNlR<4V#VaM5)D7!3fo~3 z&amFd+{u%h85F8%Jo1DXi(Rwm zMV^k3O9OJhBJnP;O!>Vic6N55)VFAy!txy)KU<|An^Kg(MHqgXNZ<^+s1|+!;6^P` zPvI}%tM0NsWgPH*LgN2E-8Ax@-k^&E3c<74N)qn&aD8T_A9pIHp+}^k(vx|5q4xwg>MABZCkt0i}vmZ95uP+H|-G%$7 zM4$3m9XzDSU^HP_fzQ8qD2aP)y(>Kau%pRki>fuVA+se!Y*u@2ZE4?ZHun0yxuIIZ zu{7s&&Zq75W`qMQ;c43F;&KU=4Ebh-?6$%&m`flf2|OgqfGx^UaQ0nG+x2R16n`1- zH73#$s%M22el1@O1ZRkk?*}9V66DpVGn38=kkTVPoi{qib|>8>K;Y)KY1e%klUlAW zb-sDxnXvt5-#!vQMnVD-qBV$hfJOfhs-xFv73J+2Bi$BBpY>)+Yc15m>opl-^qTVN z{Ect@tVUp%9(psYTEx^SZk2>Oe%NLv(Rw64)V#qRp5s-A7Db51irg4{hzC5JWaBDj z0hb%lPOY4j3vc}C9MJ*H(pu6c@i*_z(vcIcWg7a+T_0pgj?lbZV3G2>M6s?$!Sni8 z{G7o7vk@8mRPJ`tcf#LQjpgKBif(Iw)~Nh%T(7$NwxC-*WC5o`*f>wUct+kgH-KkW z@cpEM9=dK=`>xWCUXR{7n+ze7AOx!?tDG7g7^P83G0=E^yH5l-@FQZimDa*Jz8dy& zp@U=KD8_oUBwj^X`M$?@8{WpftZJFOt;IaEZY%QfNk_533`1R6<;2CXpS@iz`Cq{2 z`ux;nW?`vn?W_1|hx>{$Jyz2-oXjP%X*P8kzuLscK^@I2EqF~CtuZ7satm?>I6xdu zKmu}tGvgPFk9zltHW_*wVLGME78Z=lc_XaH zxWhvYApQY;GtI{G3C3sr)!IPdmCD(_4X%YK5eDzyi5O_nYAqD#@=}@m%50J47$1U+ zx2~1ZjLBbWVkH&IeMk%ZKFHKH{mQ&I?!lBJ9SOW&4%sBE*>93wZv0r|!LhWlWL&8_ ztphg!u>LYsmR+3@GG$1lRDGxMBR-pzpiktMvEkyybtauye9rTwm-@V?B+qS5iJMcE zu0npq1EkuLGqvbgtom-_5`IC{tGA=~`>yj*FN$=KmVmo`L49|`h@kvWf+r)5G*cmdr{=aXlK$9{Vg`04`NOSqu4P+(tgft!csj}qac%v!@+*18faF)=eA_-i zIWmUtnj=_&5KSe)3 z+rGcmE575N%V^$WRXmC2yiAt!v!8#Hj}C>^VwZQj?qzD0!kIp+b+WV56gv~C6qZ$3 z(zNr8=^wX(W^eP!hq#2c+w9#QEg}gxt3FJ=KIWaZby?+R5a4}RiH6GaF;GeMD~{6Y zRI(I@cfz(Bni;84LoK<9vCe@ zK?n}M04@Wks$ycmKvWcRi;85acATY|t_9ESpmyVhO4wvLvloj7DUVu0si^3HN2NCD z2qbZ-Ak1nrF%K2N+vX{!scFqy2Ww0rlwEig6N7hcXlugwHjlgGLsM+EouLh>w<|;y z*+5N|Osso->xgfMD04u}udT2`jF zCD|jhDu_zbiCLZ!(&;@ihUe@*4v6LWt6YcXR*Ftc(Uh0r=e(nU1i7D_%G0^(f*Vp| zm^>hj~8T>_1z~n zh7_u1hzIkdnh)5QNH7wI)=1``1?sdB?7B_*{QNi+QGCHmo?GUKd-KnLU2nG{Xht!R z7X<~(`0}y~wdqsvo5I0k=Zr&>tx=pdeTh9Ry;eWjw-p=Wx zHhdaVoit>2DQWTk<$N~%CbgW^%SUwd3Hx1;j-_T{LDv~S0sIIG6vc~DXq z@yjTxnye~Ar>WT3VW|EMAR?B`dPiKiT*fvPeGWZr9VEQhrU}nISIsw4gn4x zoIoq6ojMt(N`R7kZ&P6@90-LjN#|R4m8Otls*qpQ9RZl!1B-@Rdk1u5X7raZR@;HM zzk^uV6|8vip5t3j{z<7#NTbj&%(Lps2T?GdS3l#qAwnpH?X%^4=v$XFx&mX@CA-c5 zgYS5m2N9qA-Di`Tf{p_=35geE!}46UIV9yJ#4ca2=G;0^?jwtjIk|>dr6!;`A2Q3{ z`Qy$;i$-iJ%V10HMcq0>0<5HjE-o!VcI5 ze)tp(jk~oO|{HSi0x|?Sb&!KjV=EEF)~C*ySYIuMlbv%C-Y1~vf`743s;UBIp?Ev^ z4ckv_=P~uOk5iQ5kSJPOEsNnt`Srh}Y6?>v$J{>BP?eHi*MM3MVp*DCcHIM?expC# z={h%n0^#|uIsV_x>t9c=vGI<*i*;c%L+Bw%6O1(St0$#BJ=jj4lU(SO*9(f#H_iDn zty0#&W=4^_Jk^z%`@<^p1_xLZuCxJ`j`5QqE}BUEre%&SNF|YLMI}XOZMC3GxNn_g zu(^h<7Fg-?yst~WOTc~UptA72Zw0>}ZIECFnny>sDHw+B{WWD`*{k9P8=Zbd>(V1Z zU)(O@IZ+KN=Fv-~jV)IZ5#j2)FZVAL_(iVFR?O?$E7Npi&oR=8mE(E}8LA=pXaoa1 zc-GJYblP)K;r&U2u8I7~WqH^V3lITo7bng02`Oxr zMawP6Z5#wToGhPYqXX=9heAknf$LU#gwd&hJ2&VO>4AuG|Y)0av3*3!vVnI(@! zh8-UsK^9Njf?|EQ(fkCxMb+=elMxDyzk5zaM5C%l_UF}^eL&g|(|Q|Of8(*qb$b<| z1)MY`5BMnqIUfj)Gimg2v+TuZ zsOlBn(vX8-c`HeLvvsKi6TO}DgV6aWrL>yon#V;rZz{FU>i1QNR8Q}v`*rFEEksp$ zT==3MGXRU4H>wj5x{R<^Filu>`_yb!v_H6e@hB#u(*$Kbk>$0Xzk8siZe3OPLiO|$ z`cX0U2xii_<2j6V8)%1uunrD&*ckSqj*_0z=bx%$^>w>NMWMTP@*0@_(f53YqBpGW zUNsnbMa*X#wA0MWhwVn|i|^viG(30n0%;_2abLx)9>Wf58BH!i(?d1iH3`BN0^fz9 zss~s-mcJmwe0{wU52=?}K)+1m^vR;2QIAPbtx0g63sCmP?zH}Izpx!b=aUktlPt7E zS8&*nw0y6@dFV7YAwrE<93vj`9xVYAne{wm=imQf*CEA4L_dZPyTn{IK+{YCoI1bnJ^uu=B-n1t`vth7HK|)$eb5_qv9)5{Q+nr< ztDso);==8UfhR`<;-wtn*%@bp?5Jn;A?T+TVV=g}h+>VfBb!#m<&5(dl;G1j=-YPQ z)!FQmS;o1L6r(+;AO*?=zD43j{$DG50KFJOr@DYk@j29a{7?oeA%w1OSvJt z=!sRj_p8B`8iQ%2fAi81$>$q#ZFk&P<$ea=h10d_CZyYOiuO`mY!$NJ+}K)FWADkG z+RF||800|e0mRC@TTd&Mq#*sMZJbuFIo&cOv_xTfCLs1yVJf)k#+9sU9<3)oLBNFmYXKxWWhnocFd5c|6j^fwE3cVK|f zf*l(n-9}ljas$OnJ=$+X{f5KSE`Mm+-ypquZHLf_0b!;e#5dB7^|+jgdf;ago|=uG zd*5+yKlT;d4K8h7iZ?@Eg>5(a_~Kkr!`+-ufj#Qr0{guGl833Eq0g$Y6C80Xpg6fj zbt#u=Q>FN9ZKaO&rdpzZr}nFSD8S2_@{U~6yL(1RMZk^?RdhfEN`^{zStQ_U(GpH;5?bnq|SZbHyph7sEJJq^c~Z9AA)ysK2o+=N%jXh zS|BI^&MtBCd=amfYe;>@zGZyC4m|x{YT%xQ==&JYFQVrJCvz_RfgUODr`W}mPabI} zKLQ8QVYxf+=3D~3B6}l3pbnS#eDk;8EfZM@s!EYaMVYNg=r|h4w4bF{=5xsy2n}B9 zQyg2JLZeV3qmHNgOAgl6u2{#d>;`%yAIzTjO-WEwiAiNRe&`PO*In-+^OeS7YaRWw z80(SAv6C&%b}2=p&j2Xx0+T|nQR#O*xsGwieH^JnNXiUpRqY%!3D;u9s>* zQ(y)3ECAb9CVFZ+ybXT!!WJ4C@_lgxge~Kv50kfx-n_Q5*O{BAb zAS>$8g1YK^Tk@;I_;GwaF94nQKlgpycb!r-lHHCL3f<{StXa!P<#*ULH#IBSYcGE> zeI=(zWJC%o2$~9<{P5p^x=hv+t(@OjTL?%6(FGBGsVwh4=$@{5$_HFFQ;YZKhFgSR z7PdHs`0{MvvvuBbHeN9RgCVxZ(s&l4oJogF7k6+-?%8U{XNe{|bE>MXXwYVvYPJf z)14)~oAv9&wj%Gda(mh*7TD#FSjN?X4zHD5eeuLfH~e;1k@OpA3`=pcHMWc2B4i!* z-c^0|;yg-(4kCZ`LC9V${d;kJWCEM1lXPmD^g{nA#p=nmjsAbO!5hsu-!F5}^YwBZ z6s^^I-RYM{9Lar-Qv0;b;%p?BQPI`!g%@5=P%J%`+}94|3@gCYdvFtZPyaJoZz8`# zFxZM1uKm?_f1MD~V_B6WY@O%9IQhFj&0PTv02A~zFv)ia;maZZ=IG-yE*ioXynwe5 zG`FK2wj#yEHFCM4>T)`T&gl>kJ6(O_zSV>BRtfl5RP*%1Iva1}zlZWarFi?;Lbpj< z{f$CETQwKGMxi@@P^hq;g3(L;ELjZA(ZyF1 za41{xn7D{+y+GPkzpGPk$qtbY2TFgIff zPYoMj<5=#Zu@fm-b0wn>6V~Jd9i6vH-`wD=Sd{UgrT1mZO6VYb!8xCrO3*G1&5T*HEKQd;wF0G$j(+K#MKr4&b>Bu+m5Ab*pvR%dgD28^A`K2VXYtk*3AAdp<7o3 z+-vd$qofQ2lMVI={gg^FDY{{<9G6~CO7GwYijL8zz#BBCi5vnLZ}P{x@LN{NXbI)Q zGTtnD)2&=euFr21}R$#P~71_xYjId~tnr1$3ZKy=!Gz4-c{#I39hM++uE=Ll!- z!8(8Jk{-Vghy(0j8#vT|(9iE)>mNo=X~f@T{*CI@>8n=%`QI@Rea+!y(huewUGlgT zP2|eTuU&0;XI6nt_)i>z^*?ZoiW;ggSKcqng6%6(v{bjC0EoMbbYfgYLBXYV+(ad# z?I{gvdK)uy+H+$5;3X5(V(*>*%`Z&esS9Qax)6lDb6B-NVPe$wx=foXPM-BtNv7FM z_{!8j#kVHUW|QI9y&4<(70cshAv5eNA(WU+H@qDD=KjDBwYeSNMvq2xfYUQTUm^YB zNcIK+KKBN|4@xjL=IX&mmjuMg3(_}tn`!}o2L+e;wm<};uk|$;*cCbX>r164C~jr6 z{fuF%(oqmQFLMY;Y)6$+Et_5-y^1GCdww!Q3vn)C~V%Ds3)${p;vs6-ke(@S)SM)$hgN zHL`EHQ0?UflD4N!X1@pxoI)O5aqW!*-RBl+JZ}(?zOqJdPO;6H;i*lZ>qI64t~yLptawx!9aiC^hMLp28q!|Tj`8Aimu zx-_^RFR3l!hLaVbw4Z*iz5jgvBOZeSwW;5O9s!hnK;1y=*wZs$Amoc{NooIwmGtCi z=m?RZEd5;zN8=j`y=eIo60WR_Mrgr-nSR1@sh59+^Xg#%p;+r?``_GSS^MeU=RQa= zMCa?9LTASX4Gru(G7Ku(eZI50Q41)8FEKAZPa5BTAf6FnKSoED>_l_&+T&X{Cx=>M z?TEwTnO9v!=5H0{LK6cOh0mNEy($C@M59Z-tyxbj0o~pB=dKV0!^u(CJd{|+z@ugj3piSdF|6qoJaSU<1Dr2$RHXv#LLEozPxKAiEXZV?eoy*w6z@cTJ( z0K#agqJd{5<@sq>WMB7ScX(=LZZ^zi-&t=q0~WG%rC}WIWj0+}Gr3CK9`efn9gFO&@FfeJJXZ)9cW~us{gLvo=YH=Q z?=tiyHIXaEjRQCbO$lf>xElD2cL=od&Kx|ZeVKG~s6(?jfQf@`gFdB}puL)3N2>p& z6DBk7Q$DVhb!7P(1t9crL5RO`wfqn0@P;ZSglY#8n`%MUkjrsl9PF@}Hj8j1}3 z=Bf|G=~rq$&`ZnQjrEB`!%TSPIU0K<8gzhLYddO&V(YsP2z{85PwqkzIXAGUNKW^i zMHX`Hup~?uATPucqr+CGt!WiD`!zuv=(zKQgvA)#~4aZEWxJS zK9>^wE+kqwyxrd8#|sW*xOQ=1w?V?SjpEl;k1#alh#Hj9nlYRSg(1TE)6k2^y*qsc z{&;aFBJruor}%U*Evh@r>hVRC9#1J@A>&h6dBU@w!p`)fd)2Q%2mBtpjH)Nvs8_%o z^=4)g<&f?_1~T6iQJ4u_ywIt!7rdpmS#{_DV9{mWSA;QwLxz(exD7B+$9bZnr3_WH Gdi`I3@V;^Y diff --git a/doc/source/protocol/diagram/properties.png b/doc/source/protocol/diagram/properties.png deleted file mode 100755 index aff8c4a9df32e764dd7ab029aff990ed464a8891..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 4362 zcmZ8l2T&7Aw+=oP7}1TzWHmkP6r00117`Z}5xLAY-- z&%7*Fa=UjAFfoI#B51+gw1S%HGW=r2D@GB`-&@8{#%Gr$6V|hvU+RLq6PxwCt&+me z*GDz1{^qWEx%GWOuO?Q*F*ZWH2XWqbQ8FQ3R$Kfl3<`ICM_YnCGAqT`V{%W6v{COg zTvgmw`;&LXA&@(3YC{K*LslQ z5}f4S<=N1L3Zs6RdMgWVlMuD4*J)=Sp1DJ+GfN6$dQ}iJD-?*Y)aA*3`Qf# zA)}blub4x*P}r#CM;&3Z0j?1zPq|a2{bqA5MeoN}^1v=%+deo2j;H5U z{v1Ht1vjJ73IrlvK1uz#eGA3HBnr*SoN|G>|MGtMTG+2G7t6qglLL+F+ICx$H#HA^6ZO1O7%AOk4 z{%i))+BbqF-SA8)*QrYvJv<|-5_92ot@&N5dzU-6V*quHo6uPQd*NvUk4vU}O-Nry z4!z&d-<9>R&3F?QeXm=tjG3cTKZ-GP$DhBD*u$Bb3A*6T@)R}>>CK_fh|FpW!`q6+V%KNxF5{>tG4&G|i@%g2%80Mh zHIe|Wpc?2ahq`1RoT?z)~}oX{93gAeo2PAsDZ*&ZqA(S?VYWL zV+ul<@?-N@)4_CvPpD8nfj6TU&jd>aU^30xJh&h+-;)QkBQa}IA1?*g%BR=hAAxD| z&7u>5R;q}5jsK{PNdN}Fj?U%_P9F!@Wh5Hw@8$FX+}FFswwTq1O3!wpqlC$PuA;By zHxR|y*mThwC!ikjGE%dvb!rDJ^l=i2Bn$w8fP<5>`YE43ql<$dM}OkKc>4t^semgT zkKVtrm*7J@4@kzNY5y$DaJR%Q0Gv!Y>zk7u3*=_(s1{LQ<@%shs!v!5am#W2qwdsK z7W{`#?^Y#WT6w&NVRR)|xv2JtYo0(RFI}CeM!S93nZja$^IoXvn6HGcZ(I-?1j#sSqFRdpSJau$bE# zgtCm9+b{?AW)RN%cBLFu3!c(da&>1d(YQ*w4dizRlvjjR9qbwh$PR~28ye_tvcJ1; z?RpmW;AAJ;Uh0lhNa|Ma5$R6Nm!V6^r+A7B*Q@iVCnkJ8aRhlfFR5;!cjo+V*ujW@ z-8libzlNWRBs~iaGcHvP;5vUfN!pVkeYaeI;E6t!XJI)({zOw8Os|Bzx|^Y<@&~VEf1#oR%gjcL*D=5n1DhJ#TZ7 z!{8*fo%J;9EXg!hl1mahGz!L-Dj%e`Ugl*?AJn|*x-LAlLZBGA57PbmN7F0992d|O zyZfq7sqaZRDpO;J?d^>Rr?<*?*-mw(o2leNIyTN}^FyXlTw)VN<&4Jwd8&v{LA@?G zWk1N9=3%r^&{liUQ{xvg=d)nDj9G;S))o~b***J7!AWRjJ zoCz2dzuw&{(9k$tvTS*m+X ztMxqDvS}Qh0(HBmT*!4TP3iZcQU_TPh=@M-SF>8q3PZiZ2%11_an;> zkCM(Us1v*oI+uDuQ$;hSM`6-C&qq_^z$2= ztX2HG@0#2W-VB))^S20bh1c0-N@Sl{St?vg&?vO^WSCHIR^6j?Q#ZVd{D|iM?QeA*G00HVTkK zdR~hxHQzuaqHdPD4ex)_*L^@K@Y1dXWv(w~ddQ9Prsp5oZn{~2+1BM8DqX5YsYD=n zrx_|oO_`^=J_fM&`JbzFF6bZis51g)?!JimTkv;+(Gty13@WlK!BO@$GamRQM<{G~ zNJ}9v>L%m3aq9O6hSD?Gp1ob#ZC>A5Zk6Y7?Bati``nG2#kSpSxDdzkMc?8iw;MK2 zBW8m?DxwzOg4MXOKP|E1{nwx74S=LHCdfWw;iK_Yxh?xkq1L!~RP zO-{>6_86B#E>M^HbK-BUF;B97$ply2B74IwRPP1FxzEr*sq4$VSB#&D`3psnM2>nL zqu;R-OO$TfagKbe4yeJeX6k4u$U)bg2>-I6aK;_CXdQ3Ng0NTca0ud6G&zM~m2YZH z{*>WBts!LZPM1vjWXtIqY+oslBXRQe+01dc{=DU+GG#L6RzW{@uT=lS_+;{8oUbZ1 z9=TB_(+9=_>)4@uDWip1vc?_K+J5IjtVZ=jxK1G-96V1WG}uA5hmAXx#kC`eE|ai7 zYlTCOWs7QFH(`9q=|Mr#D{vmLv%9OYs=x|a$KI%3?ZNvq*N+Te7v)*bl0eMWj#dU` z$z&_^t_du_drR>w^^=UXH+`1Sf!6-PZ~IfDpJHY2j9khBPmyy8_p_aJ`c?jtm+Z8j zKWHntbva5SFTz}GVe|u6-k5|3mh)XjPhz*NLV?SgQlHLjo?gNH^bzx}4(V8R3bi%L z&a3;W99f4?0zR~;=GA4&DMiIU#g*Kmdc1O`hA@2V8dd52q^({l%{A&gC@Orezx`IW>RY%THn(GAG2Eb30Ff(paaI+QTm1JeaocA%EAE@-YwVRDSr z#Mt*QKQ1U}1Vrb~wxwv0YCoh6ACeHUEU&1HwWw14FfS}kjf15+_@wH`Y|KhS1tEv- zFrz=$+@4Cd6E%tkhEwc&C4=4ft9T_9wqGmDCSX#&SSr{x;=F@r=kFbfw;w=)}zwt4!slsDKeW_0YxXNYD1d$P; zxgITQ2SRGa7XC-%F$WrYPWrSv*qIS(Lz5{tFUxSqI-{B_v!$}Yf(YR2TNkSn^}}86 z-5iWmOR=2r*4(TSk-0{b4)F{h`XVR2x2*u#&i^cDOZW7e&u<}?$%zjD4pb2dqTa6I zCuy!F`#*E3cOf&(kw3=rnX_`~VVNgqXHTV55l?;*JE(P=e1}&ZV3*b@ zzQ7H|SLt(+^7Ee5wNdW2L^5`mksdXbI*QPwi%>oq;s(e|EO)TN#a#R$>)8U0RZxJ1 zxNhB;1bucmY(9XvouuQtnl>gvO>*?8Nlv4f`+GU&(a+67E0NYTp9%6aF@-|PckhwV cwL|B0vqR2!Yuz?e>Q@FpUl*oRrGSPlP)(^ir%6OXRCt{2onLHQ)g8w_$98PTjoU(T z)2@J^Tk1Gjt57?n8)D>QH3=zH>NFuu<6%hj&kNmn80jiBZDT=+ZPTv`t9tB=*@u{@}Q_ukHKC*Y5d9k&^p6=l46gzu*1d zbI-lL7Ff*g5PJkXVRc+9a7aEK80CE{Vnu=kr64Q>%@W+%HUaZeGASgnXo7?lLh_s$>x@a5edL90WX%BA7|GWdC-7tBjw_d|G7>mAQEG&p|e@i_gv zg7;*$1bmGix1%AuU1~nFaCK^S?qcFw$Irs)>4k;NpFOuTuU@!J(yX!7YhLReE9y2M zmJ1I+_>myLefAgC2yGgFKl>hoLy0}%5J${7gM{1YTJ$*2ceZcx{idgNU2yw`V$BpdI^GVj@esM}&F;juZL z?R5COj?;awJihL+$mWXuJQmr^=~o_i`#g>}BO!VW9HK%|HcEJG%mHvV`5MlhI2u|1 z@cm7?{XKkt6Ms4u5$k-ezDIYk-+&=16cwR_$HrXQ={)q4-GNP=yY4g0XXmc_=z1g| zaEmuO+vzaOu|iP>N_cFH+aq55)h~DWjrRNO(?J^D&c;lda|gg_w10&{3ne@@r6WX( z*W=u<{Q<*uhwTse@p_#|2wZOGkl_Io3JsL-*c6u}(!S#!)BJ~iv=Jd#C)2!WS`dYz z07`gliiE9OHv2qg`Ts$)Z|N7ohK>*|X2nq`@}Y#szPP<^hg-W@Wd!c^0w7tMU6~a} zVI139>*uQ2u{*^6NE`bAk*|T4T~XUe@JQHN?Qz(ZdOFyRK&KvvNE`biA$lAFx}@ao zaEL@chgx<;Z6m;qgFv;%p{NZi)B_P|V_!H#LQ3A2@KYC(o6B8Wq~uIE#8n}9Av(gl zfYh{`%(m7;Tp2yJ=FD?t^wb?~vdOmRvsLQL&ICHo128qPx5^_a4XwQ9+E;8^xz<}N zx&3qdtl0DQD+R5-rPg1*n3eh}i}Lh9MA~>tN={127GUWXt>9+vheZ8=Kii?qtWmT( z>{bYnR(RWAYWcU z*F!jF?585s+ITC*?u*4$u4TjAy2EM7T z(3G-L3^@Y{F2qJSrpJZR`>80kHeMarYKD!D>=DDFloS&ymJlUg=9^ZIDb0Cok!CtWcDR5+0i~Fw9VDF7xy=&wnUCie9VO&qvW~9DM#mX66>N zH{W<@7<_r`nG2yGgJLkUy;N8_9c2h+)c&##~T^|6oLUXPRZ zmW^y}_R+k_yQb~rjU*G3vkZ^jB$-N+N~OPF(^=v>k>QzvI73E`u^#hU@0eY;g|Phn z$&psNrQk^kdqfSqMxi1Ey?S3WQHXFGT}aLgNs}!99XQ_svk3OaM(8(kTz5rY>m3v8 zHW$m+c%q|Rh{ZW7B>%KJc0CXqq2E8pg9wfT6H+h(+y)l%G+zL2FSnTx@CW}K4;n2x zpz^9HkE*Tl2>4XOiE70+6DfG#O#c@ylLSrzCnG_EQV00000NkvXXu0mjfvF++3 diff --git a/doc/source/protocol/diagram/sec_node_description.png b/doc/source/protocol/diagram/sec_node_description.png deleted file mode 100755 index 4272070bd3cc4b83fc83d18746dad4eeebdb3136..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 4529 zcmai22T+quw+2L-A`wCng&5$YDlH_^Q3xU(q$s_Klte)~0)kX&q5>i%gd(9s=u$!z z5a~n+y-E*FBvJzW@&E7Kxp(Hy+}W9D_q=;%-+A}lbDrmHw1J)mGZQxx6%`e;<^%Xc zDk^Fp%Gj2Hj)IIBvqzMU&R$ysPIdmbW#RG@DNpFVGE2r`PuO2sb_!bA%7%S(}(E;bozW{fh?pt$5FmLCzf6KVsC=3Pe&59&XdO5r{=9bM@+$HH!&d~xtp+T+(p*L}Pm9x5{XhX&mj<`JlIlryed|Tv zfCl?56ld9$uWXwg-Le_042gI6sI2g|R0NZGcfZT>OC4)})@>)>-C!yEm4i3D1RnpOCpqXHAKO^CG-gGUX z>d)xzb(-+gZTi7)Io}g}pR>rw+!+|CZ)r$1k&!@^UI~0j%8WGMT=V5ztIXB`!!x<` zIBydF%yiQ+=IZ@&4#JnQmvz23TcImRUjE0K-WF z<1_h1nC}HzI18T*w<7AhkmL26HcJfP%0~-c)HyOP1#~NNR#AY(?w@g1Pt@a+w!P?Mxp&R+opvW8r zDIM%7El!WXFDTe%{X~aNLJCHmK+Vh@8hNj7>~|i1_MuL%TLhu-_3u{;48D?=IS~Cb z_x~xypn2z^P1O+{Uo*;d$#+9>Z)nNW*$z$gUZSzVOzLt;E}*AuQ`vW&wqhm30Ho9iZ#<@z^QVZ#n{}>w^W> z9<~Ivr)<}27CSgpRCeCDPp>zGTPogW!f57cRB`$>y~`F4=V`ZUVpiN9CPH;ZjbH$O zp*Cw;<2d^2MQ7Re6FmYS9M*nymJpLG+I4|q35>^fay;8BG79UJiNmV>I^X5U-vqD{ z-&)j%zbrKy=lut1l%f`30+QR1JcHL(ghh?NWZTN`fhs~cp|Qj6It zR=F2fshHIs{|bpYe2?!r$G6}6yByFv?KiKomWD?7QrO-{isD`=p%z^Gye$pY z#TOTykRW)H40F)^G=0rjG9{8ejd5w&O-!sBShnnT`?hStPl9rEMaMNY0$V2!hZ5-z zvWMzRPUL{{-54R35fw@4v*k;%^8QMzd=UVDFrxFzxR8w?=^`09Squ3wR!J1BaZCiw zEt27wClq=8ln%KqKNeBoc#KPS_(l+)+@DZhgqTA+ISLXtMrY01- z7Aa8z`>AzUN~9c=ur=jr_YR^YC7)pPL^AUxuRd8aUwNab(odKxJ2y)u9KgrVN_4z= z!?Cnz}V|q0%bQMAWm`hnOTO2O(4nmUln7>Z<+N!lIgavK-NozPO+m8H->18#h z8_N)t14k8_GQ7XdNRm#zjAVQUwtRrG4+pe63XDhmzZkQvOuEjSQJCgxb5YG4pIfc? zz_VXe1;IYO?!}Yi#g(QXW)=9;i>I^o_K^{=?G=H~brBMOJ2|~lH-#Kr8|90(fdht;7^hKP>%6B(EtzUiarrT-bi)8+B ze&UIcRw^Lu-OlVR9xUD49_KDVn;PxS6{iGj*HsvUr-|aWQI5Np@-K-9+*wU)CLA>8yQ4xcGb_J|)4k5E$Q~AH3|g+>DyK z0CBUC>>!;{Ff1jLv0!~Rrgl_&!j_Vh-+VB+aPTk}a<;?7>Uu&=pc zzD$rFK`Pnf8#Xy*+B~aJajB~>q@(IzbK69A_2;__^sMXT!(76t2I?5ln0>7~EzL^}&fY`^8L zdV$gdXrzZzNvYbAQN{N`IyJk9w|nzX!bOX zkYI0n@^!V{#xjD?3~X4r@E8#B0)c<3kL59~_Hr`Aa1|FQplO_RuJ%D|ev}oQ|V!j{eXVM+-k3^<5$%rXB{deqVOV zEI5sSR`v{CfI{^N!e}J^0jlgUK#+*lWx=W@9?+WS>tTx^Ag7xpZ3#yK&s=uxhYp=e zE1Fr}Y&~U$!_=+UVHory*IU*Kz~vacH~V*E>ZA>}wkK0Un*o)C%2Ekbu+yXEYoej){Ttgy9nCDKgzY;hFGp62?L-bgkW*c7!VCT(!z!$Tn)d<@r9z>-gL6Lp`st zlz|EC4D~}I9#*)~i#f9lUh$etP(kQlBNxtr6w2m!LeABOG0+y7Q?fLw;aP6Mqcqdf z$03+2&9^tUwtx;BSD?7ccn5@?GrW! zV!D-GMbGrwg0dNGR_fa`aiyOeaM=J81oS_P z8_R!XJQwe;0As(vrr$a32RdP&|MF0g>+Sp{o~1!c&}3n4qn7aZZ1?bhVa4)=j-0?& z5smsxc0HM72aT5c2Tnu}`7nJ1H|AT-q05im>=82T#=y2Bp>x zu6$W}sbe(bXjG(=s8v?U*}0T0KI_|%+4TLEo3}Jkh0B+2?#)x5h{%q}#mpZ02Q@g$ zaQ>#2?}NDear7Z~GRnI3j4s}7Sa_%X=Cfzx6AY&Wc4Pim7I=zdS4!8 zC=;V(FoJU&ihiN};#Om+r7CXh7BYdgwy-yDUnoVg4iYSFxU1d@%#aHZ=aBf}mmh${ zX&dG;a3`14RvCf6evQ*I&1JC1%eY6c>Q6H968U2cRv$%JM5%Zz@=lIWD-+Y7$X(%D|<#yjXrZwq}Gld z7z}@YSsm5Y?Dj0es1uR8^)sqTkg3Lp$-h>Wu ztBKrFIJvd_*T3!6CTBE3MQ$WO+3$DYY!?Hs(%=Hgn$^_9RnJqCLxffJKg9Dt)!6fs z;1{oEW(LPN)qZ#1zi%^SX~=7h4Y~=2_lQLOr9SFVl-F1Kl6V#+e*+K`s;YEOE!z|M z^4HDN3;atq&Des(5!|XagPmC2Y69DziiD$|yridKB6x}n)1pc0ozTZ7;OV6M_?r_W+);2iUa`X)XdNgVr z;QTzJzllzQ+0zw+{6BOV^uKf&f4K_${ZY=oz%#eg&UI-xqwL64?*>|pdT8(s7M~FJ zB;1O0kSI*DGWaG;ddU_mvGhJ_HJ2Ag;rJIAhlC<4(Q8em(tI&mo4>b<#OkbCaF0h6OtblTnKNF1-!*txhQ)z zaDcTUrherM4~&<~?J|e8irYSFjnWs>$#WhWk~C4csAP_JcpR=~`2D2H@k6M-H@6MD z;8&>m-g`V$wnz8K$hb|}`WF>@=RHyNZ1F2p^f$!S-h43LI5Ltkl2T;=6Txlb;Q(>| z|Am?0JZ$yHB|$jYSsgV(x;iaqFtgycXnjr)<&mSEPOJdVV9NIK$T@iPlqn3JXCi$o#v&OQHM_IjclKp6I*- z3g*Y;Z0c?!+@7LGFfI}p_k5D(7hS>V7dO1D6s9#?siqWQltC!=;}li+zpS zxd)7#^IL|B#=>08BM^z_JA8~wH-Pit8*7T`8`kemxT{Z__ TwQYOKjSH2gx*oht)i(5B{ZQj# diff --git a/doc/source/protocol/diagram/sec_node_property.png b/doc/source/protocol/diagram/sec_node_property.png deleted file mode 100755 index a0e9091e2bc5c062dc4217289be232f659d279b4..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 6507 zcmaJ`2Ut_vvW_62QWQ{#bP+{?(0eh*Llp!RqzDO!NRwVdmtw(CgaZgj7pYQ0lK`QF zju^T?0O`Gl9!dgl zfhYoi-w_w6f$Pk*EK}f%`ni_63h4Cg^SLfJ7I;GA@jzRZX8Pi_3tZ=O_~>teK-cLX zsN8?zow7b2=)f_b+P+1UU_bpHbA?VS_%Ag{?Gl;b@7;y5yN_szM$x_;*f8JEnbCRq zW`cRBBDN-I_BywE|0M&ey#yUq`bUqh-LSpsO45g$e5BZON}*2Kla^fX`|BAUIA&_t z)ieG0rsqrcUp1?#i8h|ZofuxZw8X_j-*g*A?w++ywwGgVS54_)iX|x7IalqR6vS&Dvdl8jptP*Cl@#%7Fm@$#m~#j+s|{A1dOY& zy?vd2rtQt6O=du%-IYrLz$h>MpN(hBv+mzH2nB{EFZ|XQO+D@S&{fNqQ|6pC`kE#r z!3EamQ@P3n%;dYB-)VWfE;70Q?#4Eq13KP@eD!dIO{fBPrlqN(LD9N@wW>omx-#Ad zLi))oM9_A?44H5d^=s|uCObK1WP%{owQYbr8D~00`SplVcFL&kYJazpP6?MCM+x`C zKhf#cU31$bXu!^Bd84OX63YluL52UMi7;h++OaSJl2kgQ_iTB9+R@eI3#oV8gf1wX z;)&e3f*8mAaWlY*7h%=g;BxBvyVlfLJ9-v~F1R`7F#h;%JlMO_#0`wL087Vb4)umx z-N{RL5pHvXXaD+m=?U#c*kH&vH*~u1Q1O>%wj(pSRmJ%fs=$`nLOd;(OGDy}M}tz^ z+{T4$MsnuGg1*duv=~~W?&Ks1=)Jww=EB$;lHJwxQYbyi*q;I?On3AC?p{VceR#92 zjBTXzkS*0HjD-hq`A!L+m;;q?iw;batln=g$i_nB8ruqMB=BwKcx~trKyEcla*S?8<(yCj;hYmhdI*g zQevf4xqi%z$hdO?6F*&^Pfhe$BW0U?BI^-47Y|a;Gq5+qM>seWl}Sm5FU!YZ@G~Ti@1L7pK2zAvSqUbC%*}YJOK=;aoS8spn;+Vk$ zGTK~NUA&)<@36RTFhQ8<{ST}^=;3gGaZWvewrVt${UR=RSYI!Gas0W<>;1Zeb#45g=K6~9D7`3?&9l&hTCVpB%H8-!|g>*J*r@e4^_eEE4` z+s(>du|}-5XySqwC<^i|m8X;S%YupFI{gic-MfIG3S5MXdY_9+AWCJ)veC!E1k~a- z{e=viKId>foS;RxVnn;H3kT_CqVP@_5;^d}&oNpgq5OHAkApZ!?f7ZkE1$BVvV1@K z^~d`P2H=dlKX`I_fwQA`jKTLhK?;txUu3Sy^iRe+S}3=OSfh& zHzMT^&T*8-Ut>7BcIL5np+X))D*-nz2e5=FWxl@{4xGB#Z8}GmkedXV6^0L1!vbe# zO@p$Wr3W1Ln7BHlSA2G0Wk3Jl2iABF6U0;7ANUrI_3uVpFD*O$V*+sz*f*1e6gP>k z_TxJHaN;ui@bf8o{N97@Z7c7>9x6aP+fyryVdWthQQjhZA5SXTSmzEzpeZ4bb{F7fHHoCVcsyf8VmhdV8rkT~%cz=ykfro9YuylXl_V4ab+;^+WwJ#+Z!EBJZbuZmwG8 zcu7QEsYL6R%zHH*?#|18>D#pY?d{=ETe-*nF9?%hgh34w`9!@@H!JvHb=V($t2Eb! ze5<2)Y|!U^`-;_0(S+ny6e*gRKw8=gb|&s&ceJ5TtHk_}2{-Q=tEf<96AwZqkzIH` zCrz~Q(R!rg@;>*ylIkZ*$vKvL;#>jG+}+yI9>+67s@O>n?V0^6TGtq({{p-q8I-o? zam%!>-BW3|gBGQ2j+ycVu0JdsV2tUHP~hb;QbD8TiEUD$HPF&ha!eXM_r=04;A-LS zRg*D7Dzj072TKX@@@D95GJkdNf-IPtAB-7jy>TLHd3lyp$(2?aPbL1k!RT=e2va;0 zHWc^V(O&EM$VwD-+OaXYFZ&z%c1iC^<=z;lHw`dJ_G}XRdyHA2fvN3!?hx#)80;CX zzu-3=Ae==3JV10d%_qQ<94;1+ui;`B>qUiDHA|%n1At*LFuYe(T`^)WTsPYE&3x=q z(EQj)YsnE1DbJQ-6;!fbvX}(n;P@Lrg8O+L2!*6zYsJyO@Adx;atK?@Um3^kZFMF4 z^uHBKhLolCJr}~igX4YT&k&7wRab?=0@9o|ZEKM-QI7|^!K2=4HR|%U`KR;UbfBuI z5UT85_2H<9pLRowu(7;1ot7+mWX5wX`e0Mh&=jX_#;g<&c7Lj!ZzQfudqb@iLd*sJ(|0NF(Ru0lg>gVIHu(`0T3LWzk3cp0C>ZjM>d)0E4l zA>iRiNt8pRP0{q{>(dPQ3Jn(kwr3X2Oy?|&Qdh-`kq?s&;2y=R@_e$un-J@-3-Ppn zI+(!E{wUT)t>Rv+@qudxW>PLsKv9Fwdxj z3#qG8t?jj~y>vVE-Zz?Pc^k1^Uu_3BIP$zQ;9|8xD=HVEy!~!AadM#WYIGoNjNiHv zNGK&Ej|Lky@YRwTo1Db}#CZ$S#n`U>kXr8N(a&+MEb{fbZW2lZP#;c3-B@p zo`tTH%vGHa5tC((>ejo(>IKj(B0e*Bc>h_5{!N>nSIutydg*F z+H_b6Bof}d{>8N#!W$hSJ_gM$4$X8skM59M2j zjyME$K+>^tOondXi(32PI@Mbfp;KGz+;mZ-5mJ*Oibn${jvKIyo-cOR z6`LtKdYoICelSB0v~_ZPP!h1N3aeM_*w!-1EmAn>zSB;lz62$4Wm;0TwOu;()}55& z{=}P3=yK)h=l)Ygh2Syt+>MxV!J%S`4c%4Xe>`3r)j?5OxV4Glonx zM#hWpCuaHkgUa4}`z+fTT6lwGo#=Cem>Uj+3Zf|aZx6{iO(|&UmJ9f4Waz474J}0g zNqO{GMlF~?IjQT_Ye8QxCRADCzv4?xU1ZfO7}GV^QS;SMMdkGwIz2ou|4tqtWw}~) z0RH?(^7tR1BJX(dpvzm-v3%9{WpJ>>khrabKi9Bnw`^Of6J9#!H-I7DHkQ{8C^Qhh zEZNr|E7YrAkKn>txd}0SOs+UFV;%oBXW*CQ|0?{ zn=7+RUz|e6_8KC;wA0_0Ht8b$tc?X%r(M}Ulb87ob1^_^by*Yb8@2Ac6w3-rt{*_i zAr?n>vlaJy`IBQI6U6|9zf_R^xm_$DlYQ^J)TtyvFIKsnYMInX~GLz|uNb?U@Z-2M27H zO|v>IL67Jw?f?%-mCB?x$I%oxJY5~ z7L<hhO|M zrDH3Y25X`eP~{7Ur)()u7hcG(Q;pv}Dxknc>*Wk2g^PyJIs`jY^_e}H1$&GKm)Bl| zEu2Z%Cxw%1nG+|&LM^?71~<2wJ674q*RifA$ZQ(X``>J)w{gPS=<|K?ADvsb=c+~M za2UP9B6M9|o7fVDaG}j93J)C@0}=LR5n-7=s$T~D6*7ZL!L1N2`!$C=A-Yi$VOhn<}~6t^BkbXl&vTo zlm}ev%~#tK1A&bll!=i?eBgXR41$$+ZNGWxr)t;y%0`1s2>#g2@;d^ulUF_a9)}+s zgx5uZql)EMOetPuv^LG7j<{FqqBADg1t+=@<2$7xr)KBPJ>c)pi*)bkuxxw?R>zrn zq5m@K*ngZXYY3geMDjp(tHkai$;0!jD|`nde7e_h)X>&0;iH5pux(rBID#`S%zYdZ zl5P?e_-mlU0A(Njtkq{Cv~w=EYQ$K2m`}GFbxS9IJPM9Q>D()jNw%sLY+b*2FzLY` zE1=`e{P4;nw%M8Yz@&dkXOE_6SHF7lb8>FmEzrr8&>AqIUA$;d)trX9 zdg{j0KAm?||7FK%0_^QE`ZP4r=B9O8=_iao+KSdu>oxOkRi~Gon;S#iky-VtIK35d zyKE>9w&SyXEJ2L!C|)$V=l*MCH1+W4WB%8H1FA*<_^14+ngQGw=klhZ7hotZh@GNw z0n~Veu@_F;L0i{zzAGmx9>WGD4E%c1cBY-J!6`85>WR6sj?)AaGe>ybE`NpK&mQOg zyTY0cv;kq<-&hW}>J|Ajm;BIgdIwGu)2L-A?A&JQM*jg9<>v4`*M#jOD=x!=_cj(IqyN@vh~}dq1oJk zu=ziV#W*S!(;W4;52bB?T8@gkXTXqimtmzzw%9xf)MK6#(@tvl1h%-HoD|cff zfyx%mg3>|IWiw^JFQIAAqvP6o)vjOm6$Xf&*^ACj#DWXD{3D}X_K){&3T*9qh)N5) z@)9;&?(KRnpzMCAqJXlxGHjPI@&>{(M8T@Ru*%uC$~MP|JXc|0zf(N4LLY~#@z1P! z!A3dXS!pqq_s*=jg}W-Ag(pcp`)LdqO~Lw{zbRJjAYnvxoKrT! zJh@0YN!}J|1uxiv^19bJklf9>w1A=G5NMuQyRlK6bCG}67_(t#GuWM;FXKPj;F!o! z90Ic#d>sIPQ`<>%j?>oO@nq1X?uPp-PoYAsoYKeBgzCIAYI;_?!DTAi;3FVuNJrk>Z-qt?&puAlZZDpOMs+O zu~}Q{uaG=DR8`x9ooHQ&FfU5iG43cAFI%ml;RG#?%WGRixD8>ip12xQ4-RzwR8rBm8WkS!;9AwGOg@<9}*gCFR^f z=(juE&wo;tZ|##!hDa{m#iS9VGE9`0LoZAQ}7i=925z zoVw48e@H=be>(N&d2-*iA#2*BTFKx4QN!zGh`hWMp!XAYuc?j22OO3D2&nje6P9<{t+X3Z-c*qA&GDwbu6lxqMx4-Vptp9K-N^wvqJI$C9x? zhMvMeLd=RoweL#{^wIjAP}O0P1LD9v*f;U0H(p?1X{$Lg>2iP#ec}l;!N0rwyby8J z4`eK>TzXUvfBeC+7eU!xXr&5TM=D$NV6QBsYIG$Xr1}69`{lvGv`QBZmQs!(D)QO{ zbepJguS+xNW+1d<$@UzG(vmvT=$G}?S+LqT&`8i9Z}x7j6J0b1@91R3`-DiFw(+~i z6&OZwqXzspDP<+BvBx{+~604xlGC<_i#X0GUcB^`64sF9K{t z_j8Z%1z(QLeA5->M?1PZI()wJ0UvX@(q_FT!i!nb9^?-DPIh;qPzcs!zsj5?pbuj{Gafz5B3&0d>&DqEl&Sp|@;9*-*r-oIQ(Ur0ro0>TW98ZYzw z{~R5jV8l#4d42w1>H_)wq@_n;!?5u*H^EVMky3wdr%sOHtwHmjZDI_F_C7(f`tTlZ z5thK1N2b}%K$~}v+@%OBuCQBR3j()m?rb|LVwIw4rr1&F0^qQF1)uL%?+TYFNv`1jiw|hrMa;JYLd(n#l1o8?o z>Rs3h(R%DG6uSIK)<3vr=CgC3zMDQbRV9@|p#z$Y)GD|&+YlOx->3>E2q|^t-{C){ zXz%kGca6UO%vrkK)6!=G0jbDqI%FNG{aF?EF=w`YZDl`V^5HUrd|{(Z$UI9tU?vL~ z{O#|KPRq>beYsh%)wnBkR>p3dE_zkI>6z001|jM;s7vM)wkEQt2$*(<80A)dRCm2{ z_C0cd2iVhzJQqM1kQzn31ntU|{l6Pu5C3zg`s-`4t3`tWe7t(X_O=r77I=iD0B4Cx z{-bYn?6&T|C5iSLKG}3v1L~toZ7y`i(-;QEXtuKFGhVr84K=-YGqQm#{mPU|ba0id zOVnDrt|?HAaMoj>tbdY0kP3;I-rHdC$5#MtGq@K`y;$u8kxdz8Z}$W!-3I+yy!{6e zjJ&+AGFvsR|5J7e>-J5v|6M9oziH)oYIM>LF(AINGnQyphoc^pN8~CpT^gvZd1@-5%*Z&0*p!;P2 diff --git a/doc/source/protocol/heartbeat.rst b/doc/source/protocol/heartbeat.rst deleted file mode 100644 index 3df64c6..0000000 --- a/doc/source/protocol/heartbeat.rst +++ /dev/null @@ -1,8 +0,0 @@ -Heartbeat -========= -* ping gets an 'intended looptime' argument (as number in seconds or null to disable) -* server replys as usual -* if the server received no new message within twice the indended looptime, it may close the connection. -* if the client receives no pong within 3s it may close the connection -* later discussions showed, that the ping/pong should stay untouched and the keepalive time should be (de-)activated by a special message instead. Also the 'connection specific settings' from earlier drafts may be resurrected for this.... - diff --git a/doc/source/protocol/hierarchy.rst b/doc/source/protocol/hierarchy.rst deleted file mode 100644 index bb48f80..0000000 --- a/doc/source/protocol/hierarchy.rst +++ /dev/null @@ -1,9 +0,0 @@ -Hirarchy -======== - -* group property (currently a identifier like string, may be extended to tree like substrucutres by allowing ':') -* visibility (enum(3:expert, 2:advanced, 1:user)) (default to 1 if not given) - if visibility is set to user: everybody should see it - if visibility is set to advanced: advanced users should see it - if visibility is set to expert: only 'experts' should see it - diff --git a/doc/source/protocol/history.rst b/doc/source/protocol/history.rst deleted file mode 100644 index c89a066..0000000 --- a/doc/source/protocol/history.rst +++ /dev/null @@ -1,73 +0,0 @@ -History -======= - -Meeting 29.5.2017 ------------------ - -* for api: float is 'double' -* everything countable is int64_t -* description is string (UTF-8 without embedded \0) (zero terminated for API) -* names / identifiers are: [_a-z][_a-z0-9]{0,63} -* BLOB is [length, string_encoding (base64 or json_string) ] ??? -* enum is transferred by value (api: int64_t) -* basic data types: string, BLOB(maxsize), int, double, bool, enum(mapping) -* encode as ["string"] ["blob"] ["int"] ["double"] ["bool"] ["enum", {:}] -* send as json_string [length, json_string] number number 0_or_1 number_value -* complex data types: array, tuple, struct -* encode as: ["array", ] ["tuple", [] ["struct", {"name_of_subcomponent":}] -* send as [array] [array} {mapping} -* forbid: structs in structs, nesting level > 3, arrays may only contain basic types + tuple -* essential features should not rely on complex data types -* fallback: if ECS can not handle a non-basic datatype: handle as string containing the JSON-representation. -* mandatory for all ECS: enum, int, double, string, bool, tuple(enum,string) - -Merge datatype and validator -++++++++++++++++++++++++++++ - -* ["enum", {:}] -* ["int"] or ["int", , ] -* ["double"] or ["double", , ] -* ["bool"] -* ["blob", ] or ["blob", , ] -* ["string", ] or ["string", , ] -* ["array", , ] or ["array", , , ] -* ["tuple", [ :}] - -Examples -++++++++ - -* status: ["tuple", [ ["enum", {0:"init", 100:"idle", 200:"warn", 300:"busy"}], ["string", 255] ] ] -* p/pi/pid-triple: ["array", ["double", 0, 100], 1, 3] - - -Meeting 30.5.2017 ------------------ - -* data values can be transferred as json_null, meaning: no value yet -* json_null can not be used inside structured data types -* property name for datatype is "datatype" - -Meeting 11.9.2017 ------------------ - -Merge datatype and validator -++++++++++++++++++++++++++++ - - * enum, int, double, bool, tuple, struct as before - * ["blob", ] or ["blob", , ] - * ["string", ] or ["string", , ] - * ["array", , ] or ["array", , , ] - - -Interface_class -+++++++++++++++ - - * Drivable, Writable, Readable, Module (first character uppercase, no middle 'e') - - -transfer_of_blob -++++++++++++++++ - - * transport-encoding as base64-encoded string (no prefixed number of bytes....) - diff --git a/doc/source/protocol/index.rst b/doc/source/protocol/index.rst deleted file mode 100644 index a3227a3..0000000 --- a/doc/source/protocol/index.rst +++ /dev/null @@ -1,22 +0,0 @@ -Protocol documentation -====================== - -.. toctree:: - :maxdepth: 1 - - motivation - secop_v2017-09-14 - issue_1 - issue_2 - issue_3 - issue_4 - issue_5 - issue_6 - issue_7 - issue_8 - issue_9 - issue_10 - outdated - history - meeting_2017_11_27 - diff --git a/doc/source/protocol/issue_1.rst b/doc/source/protocol/issue_1.rst deleted file mode 100644 index e1ac595..0000000 --- a/doc/source/protocol/issue_1.rst +++ /dev/null @@ -1,27 +0,0 @@ -SECoP Issue 1: About SECoP Issues -================================= - -The idea behind SECoP Issues is to document properly what was proposed, -what was discussed, what was decided and why it was decided. - -An issue might take different states: - -proposed --------- - -A proposal should contain the motivation. As long as nobody else -joins into a discussion, the state remains *proposed* - -under discussion ----------------- - -This state is kept until there is a decision taken. - -closed ------- - -After a decision the state is *closed*. The issue is not deleted, -even if the decision was to not follow further the proposal. -This is helpful if somebody later rises a similar issue. -However, it should be possible to reopen an issue, if new -arguments arise. diff --git a/doc/source/protocol/issue_10.rst b/doc/source/protocol/issue_10.rst deleted file mode 100644 index e15a721..0000000 --- a/doc/source/protocol/issue_10.rst +++ /dev/null @@ -1,45 +0,0 @@ -SECoP Issue 10: Character set for Names (under discussion) -========================================================== - -Uppercase Characters in Identifiers ------------------------------------ - -Actually (V2017-09-14), the following is specified; - -The identifiers are composed by -lowercase ascii letters, digits and underscore, where a digit may not -appear as the first character. Identifiers starting with underscore are -reserved for special purposes like internal use for debugging. The -identifier length is limited (<=63 characters). - -In the outdated part of the documentation (`outdated Messages`_) it is not -explicitly stated, that identifiers have to be lower case, and also -in some of the running examples contain uppercase identifiers. - -.. _`outdated Messages`: messages.html - -Discussion -~~~~~~~~~~ - -Markus: - For me, it is not that important, if uppercase characters are allowed or not, but, - identifiers must be unique independent of case, i.e. it is not allowed to have two - different modules "t" and "T", on a SEC node. And we should take a decision soon. - -Default parameters 'value' and 'target' ---------------------------------------- - -In the implementation, in the "read" and "update" messages ":value" can be just -replaced by "", and in "change" and "changed" message ":target" can -be replaced by "". - -Discussion -~~~~~~~~~~ - -Markus: - I prefer not to allow these shortcuts. We also have to distinguish module properties - from properties of the module parameter 'value'. - - - - diff --git a/doc/source/protocol/issue_2.rst b/doc/source/protocol/issue_2.rst deleted file mode 100644 index 5737564..0000000 --- a/doc/source/protocol/issue_2.rst +++ /dev/null @@ -1,22 +0,0 @@ -SECoP Issue 2: Equipment ID in Describing Message (under discussion) -==================================================================== - -The equipment ID is a SEC node property, and it is therefore redundant -to put it as the second item of the describe message. - -However as the describe/describing message might be extended later, for -example to get the description of single modules only, we should specify -a fixed word for the second item of the describe message, for example the -keyword "ALL" or "All". - -At the meeting in Berlin (2017-05-30) this was discussed, but it was not -yet decided the the keyword should be exactly. Until a final decision, -SECoP clients should ignore the second item. - -Opinions --------- - -We should use key keyword ALL (Markus Zolliker) - -Decision --------- diff --git a/doc/source/protocol/issue_3.rst b/doc/source/protocol/issue_3.rst deleted file mode 100644 index 13bae59..0000000 --- a/doc/source/protocol/issue_3.rst +++ /dev/null @@ -1,47 +0,0 @@ -SECoP Issue 3: SECoP Timestamp Format (closed) -============================================== - -Proposals for the timestamp format are: - -ISO time format ---------------- - -A date+time string in ISO format like "2017-06-21T13:30:01.123456+02:00" - -The fractional seconds are optional, but the timezone has to be given. Z is allowed instead of +00:00. - -Advantages: - - * human readable - -Disadvantages: - - * needs more conversion efforts, as the time is internally already stored as numbers on mosts systems (supporting math operations). - * although the ISO standard is clearly defined, there is a risk that time zones and daylight saving time is not handled properly - -Fractional Unix Time --------------------- - -Seconds since 1970-01-01T00:00:00+00:00, represented as a number. When converted to a IEEE double, a resolution of 1 usec can be kept for dates up to 2112. - -Advantages: - - * if a double is used as an internal representation, no conversion is needed. using a double as an internal time representation has the advantage, that math operations can be done for free. - * relative times for systems with no synchronized clock can be represented easily - -Disadvantages: - - * not human readable (or at least not easily: time differences in seconds are still visible) - - -Discussion ----------- - -1) Human readibility was judged less important than easy implementaion by the majority. - -2) Implementing relative times is also easier. - -Decision --------- - -At the meeting in Berlin (2017-05-30) the attendes decided for "Fractional Unix Time". diff --git a/doc/source/protocol/issue_4.rst b/doc/source/protocol/issue_4.rst deleted file mode 100644 index b307822..0000000 --- a/doc/source/protocol/issue_4.rst +++ /dev/null @@ -1,18 +0,0 @@ -SECoP Issue 4: Timeout (under discussion) -========================================= - -For a SECoP client, in order to detect that a connection to a SECoP server is dead, -'ping' messages can be sent. When no 'pong' message is received within a specified -time, then the client can consider the connection as dead. - -If the server does not specify a the SEC node property 'timeout', the timeout -is assumed to be 3s. - -Opinions --------- - -On the meeting in Garching (2017-09-14) it was proposed to fix this a standard. - - -Decision --------- diff --git a/doc/source/protocol/issue_5.rst b/doc/source/protocol/issue_5.rst deleted file mode 100644 index 377f146..0000000 --- a/doc/source/protocol/issue_5.rst +++ /dev/null @@ -1,34 +0,0 @@ -SECoP Issue 5: Definition of the term 'Property' (under discussion) -=================================================================== - -The definition as in SECoP V2016-11-30 draft is not very consistent. - -As decriptive data we have: - -- SEC node properties -- module properties -- parameters properties -- command properties - -Live data may be: -- value -- timestamp 't' -- sigma 'e' - -It is confusing to use the same term 'property' for live data and for -descriptive data. - -The section with the definition of properties has to be rewritten. - -Opinions --------- - -Enrico proposed to name live data like timestamps and sigma 'qualifiers'. - -Markus supports this. He would be happy also with an other term than -'qualifiers', but definitely does not like the terms 'live properties' and -'descriptive properties', as two different things share the same name. - - -Decision --------- diff --git a/doc/source/protocol/issue_6.rst b/doc/source/protocol/issue_6.rst deleted file mode 100644 index 7f87ca8..0000000 --- a/doc/source/protocol/issue_6.rst +++ /dev/null @@ -1,23 +0,0 @@ -SECoP Issue 6: Keep Alive (under discussion) -============================================ - -For a SECoP server, in order to detect that a client connection is dead, -it might close a connection with no messages within a defined period of time. - -The discussed mechanism is: - -The SECoP client has to set the connection parameter 'keepalive' to a value -representing the number of seconds it will send 'ping' (or other) messages. -The SECoP server can close connections with no messages for a time period -well above this value (more than 10% higher). - -Opinions --------- - -Markus proposes to mention the 10 % in the specification. -It should also be mentioned, that for keeping the connection alive -any message might be sent instead of the ping message. - - -Decision --------- diff --git a/doc/source/protocol/issue_7.rst b/doc/source/protocol/issue_7.rst deleted file mode 100644 index 8e995b5..0000000 --- a/doc/source/protocol/issue_7.rst +++ /dev/null @@ -1,24 +0,0 @@ -SECoP Issue 7: Time Synchronization (under discussion) -====================================================== - -As a SECoP server and a SECoP client might not run with a common clock, -the SECoP client should be able to correct for time slips. - -The recommended mechanism is (proposal by Markus): - -After connecting to a server, the client records its internal time before sending -a ping request. - -If the pong request does not contain a timestamp, -the client knows, that the SEC node does not provide timestamps and -therefore it has to create timestamps on the time of reception of messages. - -If the returned timestamp lies between the time the ping message was sent and the -time the pong message was received, it does not need to correct the timestamps. - -If not, the average of the 'ping' time and the 'pong' time is calculated and -the difference to the received timestamp is used for correcting further -timestamps. - -On the meetings in Berlin and Garching in 2017 it was proposed to put this into -the standard, the exact wording has to be decided. diff --git a/doc/source/protocol/issue_8.rst b/doc/source/protocol/issue_8.rst deleted file mode 100644 index ebe09b9..0000000 --- a/doc/source/protocol/issue_8.rst +++ /dev/null @@ -1,15 +0,0 @@ -SECoP Issue 8: Groups (under discussion) -======================================== - -Proposal --------- - -Modules as well as parameters may have a property "group". -If the client has the possibility to group modules and/or -parameters, it should use this information for grouping. - -Groups must start with uppercase letters. - -The "group" property may contain colons (':') as separator, -in order to construct a hierarchy of more than one level. - diff --git a/doc/source/protocol/issue_9.rst b/doc/source/protocol/issue_9.rst deleted file mode 100644 index cde2c83..0000000 --- a/doc/source/protocol/issue_9.rst +++ /dev/null @@ -1,39 +0,0 @@ -SECoP Issue 9: Module Meaning (under discussion) -================================================ - -meaning -------- - -For the ECS an automatic detection of the main modules would be desirable. - -For example a SEC Node could tell which sensor would be the closest one to -the sample, which should be registered in the ECS as the sample temperature. - -For this, a module property "meaning" is proposed. This can get one of the -following values: - -* sample_temperature -* magnetic_field - -importance ----------- - -But what to do, if several modules claim to be the sample temperature? -There might be a SEC node controlling cryostat, which has a sample temperature sensor, -but another SEC node controlling an insert with a sample sensor. As the insert -is put into the cryostat, we declare the cryostat to have importance=1 and -the insert an importance=2. To resolve the ambiguity, the ECS chooses the -module with the highest importance to be labelled as the read sample temperature. - -Proposal: - -predefined importance: - - * importance=1 for a device which can not be inserted or added to another one - * importance=2 for a device which can be inserted into an other one - -Higher values are to be used when an additional device may be inserted into an insert -and the like. - -We should allow importance to be a floating point number, in case later a value -between 1 and 2 has to be used. diff --git a/doc/source/protocol/jsonstruct.rst b/doc/source/protocol/jsonstruct.rst deleted file mode 100644 index 8fa7f8c..0000000 --- a/doc/source/protocol/jsonstruct.rst +++ /dev/null @@ -1,92 +0,0 @@ -JSON structure -============== - -> Mit JSON Freeze meine ich nur Arrays von Objekten also: -> -Node hat ein Array von Properties und ein Array von Modulen -> -Module haben ein Array von Properties, ein Array von Parametern und ein Array von Commands -> -Parameter und Commands haben jeweils ein Array von Properties - -node = { 'properties' : [], - 'modules' : [] } - -module = { 'properties' : [], - 'parameter' : [], - 'commands' : [] } - -parameter = { 'properties' : [] } - -commands = { 'properties' : [] } - -property = { 'property-name' : 'property-value' } - - -ODER ----- - -node = [ , ] - -array_of_modules = [ , ... ] - -module = , , -#OR# -module = [, , ] - -array_of_params = [ , ...] - -param = - -array_of_commands = [ , ...] - -command = < array_of_properties> - -array_of_properties = [ , ...] - -property = 'name', 'value' -#OR# -property = ['name', 'value'] -#OR# -property = {'name' : 'value'} - -Oder ganz anders? - -Siehe auch diskussion im HZB-wiki hierzu.... - -verwirrend.... - -vorerst folgende Festlegung: - -.. code-block:: json - - {"equipment_id": "cryo_7", - "firmware": "The SECoP playground", - "modules": ["cryo", {"commands": ["stop", {"resulttype": "None", - "arguments": "[]", - "description": "Testing command implementation\\n\\nwait a second" - }, - "start", {"resulttype": "None", - "arguments": "[]", - "description": "normally does nothing,\\n\\nbut there may be modules which _start_ the action here\\n" - } - ], - "group": "very important/stuff", - "implementation": "secop.devices.cryo.Cryostat", - "interfaces": ["Drivable", "Readable", "Device"], - "parameters": ["status", {"readonly": true, - "datatype": ["tuple", ["enum", {"unknown":-1,"idle":100, "warn":200, "unstable":250, "busy":300,"error":400}], "string"], - "description": "current status of the device" - }, - "value", {"readonly": true, - "datatype": ["double",0,null], - "description": "regulation temperature", - "unit": "K" - }, - "target", {"readonly": false, - "datatype": ["double",0,null], - "description": "target temperature", - "unit": "K" - } - ] - } - ], - "version": "2017.01" - } diff --git a/doc/source/protocol/meeting_2017_11_27.rst b/doc/source/protocol/meeting_2017_11_27.rst deleted file mode 100644 index 3826970..0000000 --- a/doc/source/protocol/meeting_2017_11_27.rst +++ /dev/null @@ -1,240 +0,0 @@ -Meeting at PSI 2017.11.27 - 2017.11.29 -====================================== - -participants: - * Eddy Lelievre-Berna - * Klaus Kiefer - * Markus Zolliker - * Anders Petterson - * Niklas Ekström - * Lutz Rossa - * Frank Wutzler - * Enrico Faulhaber - -.. contents:: Inhaltsverzeichnis - :local: - :depth: 2 - -27.11.2017 -++++++++++ - -Agenda topic: general remarks ------------------------------ - -perception of SECoP seems suboptimal therefore we want to - - * create an forum on the ISSE webpage (+linking to the documentation) - * update/rewrite the documentation first - * provide a SHORT overview of SECoP (max 2 pages, no details) - * provide a readonly copy of SECoP on github (or other PUBLIC site) - - * Eddy mentions some critisism (by others), that information about SECoP was difficult or not at all to be found. - -.. todo:: - An new, short overview shall be created by HZB (i.e. Frank) - - -SECoP from our point of view: - - * self describing protocol to control hardware - * flexible, modular - * unifying the big number of existing, incompatible (proprietary) protocols, for which often not even an API is provided - * provides an api - * wants to achieve interoperability between facilities - -.. todo:: - All committee members should be contributors to the SECoP github project - - -Agenda topic: discussion about issues -------------------------------------- - - * Markus created the Issues, everybody likes the approach - * a discussion about the different ways to handle tickets/issues with redmone/github/in a repo ensures. - * the discussion broadens about documentation/issue change tracking, rights for modification/merge - -.. todo:: - result is: we try to use the github workflow for documentation (as wiki) and issues (as topics) - -Agenda topic: HZB SECoP dll: current status -------------------------------------------- - - * programmatic creation of SEC-nodes via CreateNode, AddModule, AddParameter, AddCommand, AddProperty - * finalise with NodeComplete (also enable access from outside) - * builds a multithreaded server for each Node, each Module is handled by it's own thread - * building keeps an internal state and should be singlethreaded! - * Variant data type (with unit tests) implemented in a C compliant way - * LabVIEW test case (calling the DLL from LabVIEW) working - * view issues left: (note: still prototype!) - * closedown with non-QT application sometimes crashes - * validation not yet 100% complete - * refactoring - * live demo of a needle valve controller controlled by a small LabVIEW demo programm emebdding the dll, beeing controlled by a simple network client (entering secop protocol messages by hand) - * accesscontrol can be done via multiple nodes exporting a (posible readonly) subset of modules/parameters - -New problems found: - 1) not all json libraries accept plain json-values like '1.234', but only json-documents - 2) concentrate on the 'working' ones - 3) open an issue for this (for documenting this) - 4) a way out could be to jsonify the whole message, if we would ever need it - 5) Lutz found a (workaround) way to handle this: - * while reading a SECoP value (JSON value), the code surrounds the value with brackets ('[' value ']'), reads it with its library and takes the first element - * when writing a SECoP value, you generate a JSON array of one element, convert it with the JSON library to a string and remove the surrounding brackets. - -.. todo:: - create an Issue to document this. - -Discussion about access control: - - * currently SECoP itself does not provide access control (except read/write property) - * we rely on existing network solutions (bind to local port, use SSL Server, use multiple 'view' nodes) - * agreement, that access control is not part of SECoP - -.. todo:: - open an closed issue documenting this discussion - - -Agenda Topic: Issues inside the playground-protocol-documentation ------------------------------------------------------------------ - - * overview of the current Issues - -.. note:: - * a lengthy discussion about how to proceed ensures - * followed by a discussion about delayed change/commit of parameters, changing multiple parameters 'at once' - * discussing commons and differences between start, pause, continue and stop - * discussion is postponed without result - -.. todo:: - create an Issue for starting or synchronizing disjunct hw-modules (possible delegated to other SEC-Nodes) - -.. todo:: - create an Issue to collect uses case for: - * different kinds of HW (different parameter setting with respect to starting) - -.. todo:: - create an Issue (to be discussed) for: - * reading the (RO) target parameter gives you the HW value - * if there is no start command available, writing to the (RW) wanted_target starts the action - else you need to call start() after writing to wanted_target. - In any case, the target parameter reflects the value used by the hw. - - Lutz thinks that looking at the status (and predefining a view values for it) may be sufficient and - to have an additional parameter 'wanted_target' can be avoided. - - - -28.11.2017 -++++++++++ - -Agenda Topic: discussion about the definition of pause/stop/start/shutdown --------------------------------------------------------------------------- - -.. todo:: make an issue about the start/stop/pause/shutdown commands - not all commands must always be implemented, but if they are implemented, they have a predefined meaning to it - AND - if somebody want to implement something with the predefined meaning, it must be with the predefined name - -Agenda Topic: timestamps: mandatory or optional ------------------------------------------------ - - * providing timestamp is highly recommend, but stays optional - * timestamps are (still) fractional unix time with a resolution of at least seconds - * SEC-node implementor decides about implemented resolution - -.. todo:: document this in an Issue - -Agenda Topic: Interfaceclasses ------------------------------- - - * discussion about custom vs. predefined parameters and properties - * proposal to introduce 'features' in addition to base interface_class - * features are listed by name in an additional module property called 'features' - * explicit listing of 'features' seems better than guessing them from the existence of parameters - * features have predefined 'dependencies', excludes, set of parameters with predefined meanings - * Open question: how to figure out the difference of an unknown base class to a known base class? - * Markus proposes to use just Features then. - - -.. todo:: create an Issue for documenting this and for discussing it later in more detail - -Agenda Topic: discussing existing Issues ----------------------------------------- - - 1) Issues: agreement to use Issues for documenting, closed - 2) Equipment_id is stored as a node property and is no longer part of the describing reply: agreement, closed - 3) already closed - 4) default timeout: change default to 10s, agreement, closed - 5) name change: live properties -> qualifiers to avoid misunderstands: agreement, closed - 6) keep alive: leave as to be discussed - 7) time synchronisation: leave to be discussed - SEC-Nodes have its correct timestamp (provided by other means), have their own invented time, or no timestamps at all. - agreement: the kind of SEC-node clock shall be noted as node property in the descriptive data. (this part closed) - to be discussed: name of the node property (proposal: clock, datatype: Enum(None=0, relative=1, absolute=2) - 8) groups+hierarchy: leave as to discussed - 9) meaning/importance: leave as to be discussed - 10) Names and upper/lowercase: names can be uppercased as long as the lowercase version is still unique. agreement, close - 11) giving only module name for read/update/event request are extended with :value or :target: agreement on not specifying this. - Clients are not allowed to use it, servers may support it but it is non-standard behaviour. - -.. todo:: Issue 11 is still coded as second part of Issue 10 -> split it (Markus) - -.. todo:: create an Issue about providing a mean to set the SEC-nodes clock from the ECS side. - -.. note:: Klaus and Eddy leaving at this point - - -Agenda Topic: Grouping/Hierachy (Issue 8) ------------------------------------------ - - * discussion about namespaces and use cases for groups - * grouping is 'giving modules or parameters a name to allow guis to group them together' - * the (lowercase) name of a (parameter)group is not allowed to clash with (lowercased) names of parameters of the same module - * the (lowercase) name of a (module)group is not allowed to clash with (lowercased) names of modules of the same node - * agreement, closing this issue - - -.. todo:: create an Issue for PID tables - - -Topic: handling of driver generated timestamps in the HZB-DLL -------------------------------------------------------------- - - 1) initiate the timestamp with NAN before calling the HW-read_a_value callback, which may provide an timestamp - 2) if configured to do so, a NAN timestamp is replaced after the callback with the current time - 3) if the timestamp is still NAN (or not expressable by digits), it is NOT send - -.. todo:: @Frank: document this ! - - -Discussion about activate/deactivate ------------------------------------- - - * normally values for all values are send before the activated reply is sent - * there are very rare cases where a value can (not yet) be determined. In this case it is acceptable to send a null value. - * a null value is also accepted when setting parameters of a complex datatype and not all members shall be updated. - -.. todo:: create an issue about the usage of null - -.. note:: tour around PSI - -.. note:: presentation of the SEA and SICS concept by Markus Zolliker - -.. note:: detailed showcase of the HZB-DLL source - -.. note:: we need more use cases and sequencediagrams - - -29.11.2017 -++++++++++ - - * detailed presentation of the playground - * discussion about implementation details - * structure of config files - * introduction to writing secop modules + how to configure them - * live demo - - * fixing the amagnet - * discussing error propagation (bugs in hw-driver) - -.. note:: meeting was closed around 14:30 diff --git a/doc/source/protocol/messages.rst b/doc/source/protocol/messages.rst deleted file mode 100644 index 06fbd67..0000000 --- a/doc/source/protocol/messages.rst +++ /dev/null @@ -1,232 +0,0 @@ -SECoP Messages -============== - -All Messages are formatted in the same way: - [[]] - -where [] enclose optional parts. This basically results in 3 different possible -formattings: - - * type A: "keyword\\n" - * type B: "keyword specifier\\n" - * type C: "keyword specifier JSON_data\\n" - -Note: numerical values and strings appear 'naturally' formatted in JSON, i.e. 5.0 or "a string" - - is one of a fixed list of defined keywords, is either the -name of the module optionally followed by ':' + the name of a command or parameter, -or one of a fixed list of predefined keywords, depending on the message keyword. - -At the moment it is considered syntactic sugar to omit the parametername in a request. -In replies the SEC-node (in the playground) will always use the correct parameter. -On change-requests the parameter is assumed to be 'target', on trigger-requests it is -assumed to be 'value'. Clients should not rely on this and explicitly state the parametername! - -All names and keywords are defined to be identifiers in the sense, that they are not longer -than 63 characters and consist only of letters, digits and underscore and do not start -with a digit. (i.e. T_9 is ok, whereas t{9} is not!) -No rule is without exception, there is exactly ONE special case: the identify request -consists of the literal string '\*IDN?\\n' and its answer is formatted like an valid SCPI -response for \*IDN?. - -We rely on the underlying transport to not split messages, i.e. all messages are -transported as a whole and no message interrupts another. - -Also: each client MUST at any time correctly handle incoming event messages, even -if it didn't activate them! - -Implementation node: -Both SEC-node and ECS-client can close the connection at any time! - - -List of Intents/Actions: ------------------------- - - * Identify -> Ident - * Describe -> Description - * Activate Events -> initial data transfer -> end-of-transfer-marker - * Deactivate Async Events -> confirmation - * Command : -> confirmation -> result_event - * Heartbeat -> Heartbeat_reply - * Change [:] JSON_VALUE -> confirmation -> readback_event - * TRIGGER [:] -> read_event - -At any time an Event may be replied. Each request may also trigger an Error. - -Line-ending is \lf. -\cr is ignored and never send. -Warning: One Message per line: Description line can be looooong!!! - - -Allowed combinations as examples: -(replace <..> with sensible stuff) - - -Identify --------- - - * Request: type A: '\*IDN?' - * Reply: special: 'SECoP, SECoPTCP, V2016-11-30, rc1' - * queries if SECoP protocol is supported and which version it is - - The format is intentionally choosen to be compatible to SCPI (for this query only). - It is NOT intended to transport information about the manufacturer of the hardware, but to identify this as a SECoP device and transfer the protocol version! - - -Describe --------- - - * Request: type A: 'describe' - * Reply: type C: 'describing {"modules":{"T1":{"baseclass":"Readable", ....' - * request the 'descriptive data'. The format needs to be better defined and - may possibly just follow the reference implementation. - - identifies the equipment. It should be unique. Our suggestion is to use something along _, i.e. MLZ_ccr12 or PSI_oven4. - - -Activate Async Events ---------------------- - - * Request: type A: 'activate' - * Reply: several EVENT lines (initial value transfer) followed by: type A: 'active' - * Activates sending of Async Events after transferring all live quantities once - and an 'end-of-initial-transfer' marker. After this events are enabled. - - -Deactivate Async Events ------------------------ - - * Request: type A: 'deactivate' - * Reply: type A: 'inactive' - * Deactivate sending of async Events. A few events may still be on their way until the 'inactive' message arrives. - - -Execute Command ---------------- - - * Request: type B: 'do :' for commands without arguments - * Request: type C: 'do : JSON_argument' for commands with arguments - * Reply: type C: 'done : JSON_result' after the command finished - * start executing a command. When it is finished, the reply is send. - The JSON_result is the a list of all return values (if any), appended with qualifiers (timestamp) - - -Write ------ - - * Request: type C: 'change [:] JSON_value' - * Reply: type C: 'changed : JSON_read_back_value' - * initiate setting a new value for the module or a parameter of it. - - Once this is done, the read_back value is confirmed by the reply. - - -Trigger -------- - - * Request: type B: 'read [:]' - * Reply: None directly. However, one Event with the read value will be send. - * Read the requested quantity and sends it as an event (even if events are disabled or the value is not different to the last value). - - -Heartbeat ---------- - - * Request: type A: 'ping' - * Request: type B: 'ping ' - * Reply: type A: 'pong' - * Reply: type B: 'pong ' - * Replies the given argument to check the round-trip-time or to confirm that the connection is still working. - - may not contain . It is suggested to limit to a string of up to 63 chars consisting of letters, digits and underscore not beginning with a digit. If is not given (Type A), reply without it. - - -EVENT ------ - -Events can be emitted any time from the SEC-node (except if they would interrupt another message). - - * Request: None. Events can be requested by Trigger or by Activating Async Mode. - * Reply: type C: 'event : JSON_VALUE' - * Informs the client that a parameter got changed its value. - - In any case the JSON_value contain the available qualifiers as well: - * "t" for the timestamp of the event. - * "e" for the error of the value. - * "u" for the unit of the value, if deviating from the descriptive data - * further qualifiers, if needed, may be specified. - - The qualifiers are a dictionary at position 2 of a list, where the value occupies position 1. - This holds true also for complex datatypes (of value)! - - examples: - - * 'update T1:value [3.479, {"t":"149128925.914882", "e":0.01924}] - * 'update T1:p [12, {"t":"149128927.193725"}]' - * 'update Vector:value [[0.01, 12.49, 3.92], {"t":"149128925.914882"}]' - - -ERROR ------ - - * Request: None. can only be a reply if some request fails. - * Reply: type C: 'ERROR JSON_additional_stuff' - * Following are defined so far: - - NoSuchDevice: The action can not be performed as the specified device is non-existent. - - NoSuchParameter: The action can not be performed as the specified parameter is non-existent. - - NoSuchCommand: The specified command does not exist. - - CommandFailed: The command failed to execute. - - CommandRunning: The command is already executing. - - ReadOnly: The requested write can not be performed on a readonly value.. - - BadValue: The requested write or Command can not be performed as the value is malformed or of wrong type. - - CommunicationFailed: Some communication (with hardware controlled by this SEC-Node) failed. - - IsBusy: The reequested write can not be performed while the Module is Busy - - IsError: The requested action can not be performed while the module is in error state. - - Disabled: The requested action can not be performed at the moment. (Interlocks?) - - SyntaxError: A malformed Request was send - - InternalError: Something that should never happen just happened. - - The JSON part should reference the offending request and give an explanatory string. - - examples: - - * 'ERROR Disabled ["change", "V15", "on", "Air pressure too low to actuate the valve.", {"exception":"RuntimeException","file":"devices/blub/valve.py", "line":13127, "frames":[...]}]' - * 'ERROR NoSuchDevice ["read","v19", "v19 is not configured on this SEC-node"]' - * 'ERROR SyntaxError "meas:Volt?" - - -Examples --------- - -:: - - (client connects): - (client) '\*IDN?' - (SEC-node) 'Sine2020WP7.1&ISSE, SECoP, V2016-11-30, rc1' - (client) 'describe' - (SEC-node) 'describing SECoP_Testing {"modules":{"T1":{"baseclass":"Readable", ... - (client) 'activate' - (SEC-node) 'update T1 [3.45,{"t":"149128925.914882","e":0.01924}]' - ... - (SEC-node) 'active' - (SEC-node) 'update T1 [3.46,{"t":"149128935.914882","e":0.01912}]' - (client) 'ping fancy_nonce_37' - (SEC-node) 'pong fancy_nonce_37' - (SEC-node) 'update T1 [3.49,{"t":"149128945.921397","e":0.01897}]' - ... - -merge datatype and validator: ------------------------------ - * enum, int, double, bool, tuple, struct as before - * ["blob", ] or ["blob", , ] - * ["string", ] or ["string", , ] - * ["array", , ] or ["array", , , ] - -interface_class ---------------- - * Drivable, Writable, Readable, Module (first character uppercase, no middle 'e') - -transfer_of_blob ----------------- - * transport-encoding as base64-encoded string (no prefixed number of bytes....) - diff --git a/doc/source/protocol/modsubset.rst b/doc/source/protocol/modsubset.rst deleted file mode 100644 index 5a6bd33..0000000 --- a/doc/source/protocol/modsubset.rst +++ /dev/null @@ -1,8 +0,0 @@ -Activate subset of modules -========================== - -* activate/deactivate may get an optional 2nd argument and work only on this. -* add equipment_id [_0-9a-zA-A]{4,} as SEC-node property (mandatory) (prefixed with ficility/manufacturer) -* change response to 'describe' to 'describing ALL ' -* '(de-)activate samething' -> '(de-)activated something' - diff --git a/doc/source/protocol/motivation.rst b/doc/source/protocol/motivation.rst deleted file mode 100644 index bbd9ce0..0000000 --- a/doc/source/protocol/motivation.rst +++ /dev/null @@ -1,18 +0,0 @@ -Motivation -========== - - * SECoP motivation proposal - * simple, inclusive and self describing - * write drivers only once - * different institutes wrote their own driver collection which fulfils all their needs and it works reliable - * as secondary effect the standard drivers still can be used so their are well tested and may become more reliable - -SECoP ------ - -The SECoP (Sample Environment Communication Protocol) is an Inclusive, Simple and Self Explaining (ISSE) communication protocol. -Inclusive means, that facilities can use this protocol and don't have to change their work flow (rewrite drivers completely or organize and handle hardware in a specific way to fulfil SECoP requirements). -Simple means it should be easy to integrate and to use. -Self Explaining means that with SECoP, not only the pure data is transported. It also transports meta data, which allows environment control software to configure by itself. -The benefit of SECoP will be to circulate expensive devices between different facilities with minimised effort for configuration and integration. -This should result in an increased utilisation of expensive equipment. \ No newline at end of file diff --git a/doc/source/protocol/notes.rst b/doc/source/protocol/notes.rst deleted file mode 100644 index 3ec21ef..0000000 --- a/doc/source/protocol/notes.rst +++ /dev/null @@ -1,42 +0,0 @@ -Notes -===== - -No installation required or recommended ---------------------------------------- - -everything runs directly from the checkout. - -you need: - - python2.7.* - - pip - - linux OS (Mac may work as well) - -install requirements with pip: -$ sudo pip install -r requirements.txt - -to execute a program, prefix its name with bin/, e.g.: -$ bin/make_doc.py -$ bin/server.py start test - -a testsuite is planned but nothing is there yet. - -Structure ---------- - -* bin contains the executables (make_doc.py, server.py) -* doc is the root node of the docu (see index.md) -* etc contains the configurations for the server(s) and devices -* html contains the docu after make_doc.py was run -* log contains some (hopefully) log output from the servers -* pid contains pidfiles if a server is running -* src contains the python source - - * src/client: client specific stuff (proxy) - * src/devices: devices to be used by the server (and exported via SECoP) - * src/lib: helper stuff (startup, pidfiles, etc) - * src/protocol: protocol specific stuff - * src/errors.py: internal errors - * src/server.py: device-managing part of the server (transport is in src/protocol/transport) - * src/validators.py: validators used by the devices. may be moved to src/protocol - - diff --git a/doc/source/protocol/outdated.rst b/doc/source/protocol/outdated.rst deleted file mode 100644 index 6535e47..0000000 --- a/doc/source/protocol/outdated.rst +++ /dev/null @@ -1,20 +0,0 @@ -Outdated documentation -====================== - -.. toctree:: - :maxdepth: 0 - - messages - descprop - hierarchy - descjson - timeformat - modsubset - heartbeat - jsonstruct - datatypes - commands - todo - notes - - diff --git a/doc/source/protocol/secop_v2017-09-14.rst b/doc/source/protocol/secop_v2017-09-14.rst deleted file mode 100644 index a05d093..0000000 --- a/doc/source/protocol/secop_v2017-09-14.rst +++ /dev/null @@ -1,924 +0,0 @@ -SECoP: Sample Environment Communication Protocol -################################################ - -V2017-09-14 - -Goal -==== - -The main goal of the "committee for the standardization of sample -environment communication" is to establish a common standard protocol -SECoP for interfacing sample environment equipment to experiment control -software. - - Definition: Experiment Control Software ECS - Software controlling the hardware for carrying out an experiment. Includes the user - interface. Usually speaks several protocols with different parts of the instrument. - Often also called instrument control. - -There is a task (7.1) within the European framework SINE2020 also -dealing with this subject. In its description we read: - - ... The standard should be defined in a way that it is compatible - with a broad variety of soft- and hardware operated at the different - large scale facilities. … The adoption of this standard will greatly - facilitate the installation of new equipment and the share of - equipment between the facilities. ... - -This does also cover the aims of the committee. - -The idea is, that a sample environment apparatus can easily be moved -between facilities and instruments/beamlines. As long as the facilities -have implemented a SECoP client within its ECS, and on the apparatus a -SECoP server is implemented as the SEC node, using the apparatus for an -experiment should be straightforward. An ECS can be built in a way, that -the configuration of a SEC node may be as short as entering a network -address, as the description can be loaded over the protocol (in -addition, the electronic communication link, electricity and may be -cooling water or pressurized air etc. have to be connected, but that is -out of scope …) - - Definition: Sample Environment Control Node (SEC node) - Computing unit or process or task, connected to all control units (temperature controller, flow controller, pressure sensor ...) of a sample environment, bridge to the ECS. SECoP specifies how ECS speaks with the SEC node. - The SEC node allows the ECS to access a set of modules (and their parameters) via the SECoP. It also provides a list of accessible modules and parameters. - -Other requirements ------------------- - -- the protocol should be easy to use - -- it should be easy to implement in connection with existing ECSs and - sample environment control software - -- it should be possible to be implemented on the most common platforms - (operating systems and programming languages) - -- the protocol should be defined in way that allows a maximum - **compatibility**: Newer and older versions of the syntax should - be compatible - -- the protocol should be defined in a way, which allows a maximum - **flexibility**: A simple (= with minimal features) ECS - implementation should be able to communicate with a complex SEC - node (with a lot of features), and an ECS with a rich number of - features should be able to cope with a simple SEC node, - implementing only a minimum number of features - -Hardware Abstraction -==================== - -Modules -------- - - Definition: Module - One logical component of an abstract view of the sample environment. Can at least be read. - May be ’driven' (set new setpoint). May have parameters influencing how it achieves - its function (e.g. PID parameters). May have some additional diagnostics (read-only) parameters. - May provide some additional status information (temperature stable?, setpoint reached?) - Reading a module returns the result of the corresponding physical measurement. - -In earlier discussion we used the term "device" for module, which might -be misleading, as "device" is often used for an entire apparatus, like a -cryomagnet or humidity cell. In the context of SECoP, an apparatus in -general is composed of several modules. For example different -temperature sensors in one apparatus can be seen as different modules. - -An SEC node controls several (or one or no) modules. Modules also have -some descriptive data (name, type, list\_of\_parameters, -list-of\_commands,...). - -Parameters ----------- - -A module has several parameters associated with it. A parameter is -addressed by the combination of module and parameter name. Module names -have to be unique within an SEC node, parameter names have to be unique -within a module. - -Module and parameter names should be in english (incl. acronyms), using -only ascii letters and some additional characters (see section "Message -Syntax"). A maximum name length might be imposed. - - Definition: Parameter - The main parameter of a module is its value. Writable parameters may influence the - measurement (like PIDs). Additional parameters may give more information about its - state (running, target reached), or details about its functioning (heater power) for - diagnostics purposes. Parameters with a predefined meaning are listed in the standard, - they must always be used in the same way. Custom parameters are defined by the - implementation of the SEC node, the ECS can use them only in a general way, as their - meaning is not known. - - -The following parameters are predefined (extensible): - -- **value** - -- **status** (consists of two elements: a status with predefined values - as "idle","busy","error", and a describing text). - *Remark: it is proposed to add additional states (starting, - started, pausing, paused, stopping, warning). It has to be - discussed, if this (and therefore a start and pause command) - makes sense. Generally we want to keep the number of states as - small as possible here.* - -- **target** (not present, if the module is not writable) - -- **pollinterval** (double, a hint for the module for the polling interval in seconds) - -The following parameters were discussed at the meeting in - -- **ramp** (writable parameter, desired ramp. Units: main units/min) - -- **use\_ramp** (writable, 1 means: use given ramp, 0 means: go as fast as possible) - -- **setpoint** (ramping setpoint, read only) - -- **time\_to\_target** (read only, expected time to reach target) - - -Commands --------- - -A module may also have commands associated with it. A command is -addressed by the combination of module and parameter name. Like -parameters, command names have to be unique within a module, and should -be in english (incl. acronyms), using only ascii letters and some -additional characters (see section "Message Syntax"). A maximum name -length might be imposed. - - Definition: Command - Commands are provided to initiate specified actions of the module. - They should return immediately after that action is initiated, i.e. - should not wait until some other state is reached. Commands may get - an argument list and may return a result list. - Commands with a predefined meaning are listed in the standard, - they must always be used in the same way. - -Custom commands are defined by the implementation of the SEC node, the -ECS can use them only in a general way, as their meaning is not known. - -So far the only command defined (for driveable modules) is ‘stop’ (no -arguments, no result). When a modules target is changed, it is 'driving' -to a new value until the target is reached or until its stop command -is sent. -It is still to be discussed, what this exactly means for temperature -devices (heater off vs. ‘stay at current temp’). - -The following commands are predefined (extensible): - -- stop (stop a running action) - -proposed further commands: - -- start, pause (proposed from ILL) - -- shutdown (go to safe state) - - -Properties ----------- - -*definition of properties to be rewitten, see* `SECoP issue 5`_ - - Definition: Properties - Parameters have a value, live properties and descriptive properties. All properties have a predefined name and meaning. - - Live Properties - Properties which change their value during an experiment. - - Descriptive Properties - Properties that do not change during an experiment. They describe the usage of the parameter. - - -Live Properties (or *qualifiers* ?) are optional. - -There are currently only 2 live properties: - -- timestamp (named ‘t’ in the proposed syntax). The time when the - parameter has changed or was verified/measured (when no timestamp - is given, the ECS should use the time of the update message as - the timestamp) - -- sigma (named ‘e’ in the proposed syntax). The uncertainty of a - measurement (default: unspecified) - -other live properties might be added later to the standard. - -For a list of descriptive properties see chapter "Descriptive Data". - -Classes -------- - -The idea is, that the ECS can determine the functionality of a module -from its class. - -Base classes (recommended): - -- Readable - -- Writable (must have a target parameter) - -- Drivable (a Writable, must have a stop command, the status parameter will indicate - busy for a longer-lasting operation) - -Examples of classes: - -- CryomagnetSupply (a Drivable, with ramp and optional a persistent - switch) - -- TemperatureLoop (a Drivable, with PIDs, optional with ramp) - -The standard contains a list of classes, and a specification of the -functionality for each of them. The list might be extended over time. -Already specified base classes may be extended in later releases of the -specification, but earlier definitions will stay intact, i.e. no -removals or redefinitions will occur. - -The module class is in fact a list of classes (highest level class -first). The ECS chooses the first class from the list which is known to -it. - -Protocol -======== - -The basic element of the protocol are messages. - -Message Syntax --------------- - -A message is one line of text, coded in ASCII (may be extended to UTF-8 -later if needed). - -A message ends with a line feed character (ASCII 10), it may be preceded -by a carriage return character (ASCII 13), which must be ignored. A -message starts with a keyword, followed optionally by one space and a qualified name -or another item not containing spaces, followed optionally by one space and a JSON -formatted value. Note: numerical values and strings appear 'naturally' formatted -in JSON, i.e. 5.0 or "a string". - -A qualified name consists of a module identifier, a colon as separator -and a parameter or command identifier. The identifiers are composed by -lowercase ascii letters, digits and underscore, where a digit may not -appear as the first character. Identifiers starting with underscore are -reserved for special purposes like internal use for debugging. The -identifier length is limited (<=63 characters). - -A SEC node might implement custom messages for debugging purposes, which are not -part of the standard. Custom messages start with an underscore or might just be -an empty line. The latter might be used as a request for a help text, when logged -in from a command line client like telnet or netcat. Messages not starting with -an underscore and not defined in the following list are reserved for future extensions. - -Message Summary -~~~~~~~~~~~~~~~ - -.. list-table:: - :widths: 20 20 60 - :header-rows: 1 - - * - message - - message kind - - syntax - - * - identification - - request - - **\*IDN?** - - * - - - reply - - ISSE&SINE2020\ **,SECoP,**\ *version,add.info* - - * - description - - request - - **describe** - - * - - - reply - - **describing ALL** *description* - - * - activate updates - - request - - **activate** *[module]* - - * - - - reply (after first updates) - - **active** *[module]* - - * - update - - - - - - * - - - asynchronous msg. - - **update** *module*\ **:**\ *parameter value* - - * - deactivate updates - - request - - **deactivate** *[module]* - - * - - - reply - - **inactive** *[module]* - - * - change value - - request - - **change** *module*\ **:**\ *parameter value* - - * - - - reply - - **changed** *module*\ **:**\ *parameter value* - - * - read request - - request - - **read** *module*\ **:**\ *parameter* - - * - - - reply - - **update** *module*\ **:**\ *parameter value* - - * - execute command - - request - - **do** *module*\ **:**\ *command [argument]* - - * - - - reply - - **done** *module*\ **:**\ *command [result]* - - * - error - - - - - - * - - - reply (on any message) - - **error** *errortype* *info* - - * - heartbeat - - request - - **ping** *[id]* - - * - - - reply - - **pong** *[id]* [\ **{"t":** *localtime* **}**\ ] - -Identification -~~~~~~~~~~~~~~ - -The syntax of the identification message differs a little bit from other -messages, as it should be compatible with IEEE 488.2. The identification -request "\ **\*IDN?**\ " is meant to be sent as the first message after -establishing a connection. The reply consists of 4 comma separated -fields, where the second and third field determine the used protocol. - -In this and in the following examples, messages sent to the server are marked with "> ", -and messages sent to the client are marked with "< " - -Example: - -.. code:: - - > *IDN? - < ISSE&SINE2020,SECoP,V2017-05-30,rc1 - -Description -~~~~~~~~~~~ - -The next messages normally exchanged are the description request and -reply. The reply is a structured JSON value describing the name of -modules exported and their parameters, together with the corresponding -properties. - -Example: - -.. code:: - - > describe - < describing PSI\_MP03 {"modules":["t1",["class":[ "temperature\_sensor","readable"],"parameters":["value", ... - -It is not yet clear what the second item in the reply message should be. -In this example it is the equipment ID, but this is redundant, as -"equipment_id" is also a SEC node property. -See `SECoP Issue 2`_ (Equipment ID in Describing Message) - -Remark: -this reply might be a very long line, no line breaks are allowed in the -JSON value. - -Activate Updates -~~~~~~~~~~~~~~~~ - -The parameterless "activate" request triggers the SEC node to send the -values of all its modules and parameters as update messages. When this -is finished, the SEC node must send an "active" reply. - -A SEC node might accept a module name as second item of the -message, activating only updates on the parameters of the module. -In this case, the "active" reply also contains the module names. - -A SEC Node not implementing module-wise activation must not sent the module -name in its reply, and must activate all modules. - -Update -~~~~~~ - -When activated, update messages are delivered without explicit request -from the client. The value is a JSON array with the value as its first -element, and an JSON object containing the qualifiers (live properties) -as its second element: - -"t": the timestamp (recommended, when the system has a synchronized -time, the format is fractional seconds since 1970-01-01T00:00:00+00:00) - -See also `SECoP Issue 3`_ (Timestamps) - -"e": the error of the quantity (optional) - -Example: - -.. code:: - - > activate - < update t1:value [295.13,{"t":1505396348.188388,"e":0.01}] - < update t1:status [[400,"heater broken or disconnected"],{"t":1505396348.288388}] - < active - -Deactivate Updates -~~~~~~~~~~~~~~~~~~ - -A parameterless message. After the "inactive" reply no more updates are -delivered if not triggered by a read message. - -Example: - -.. code:: - - > deactivate - < update t1:value [295.13,{"t":1505396348.188388}] - < inactive - -remark: the update message in the second line was sent before the deactivate message -was treated. After the "inactive" message, the client can expect that no more untriggered -update message are sent. - -The deactivate message might optionally accept a module name as second item -of the message for module-wise deactivation. If module-wise deactivation is not -supported, it should ignore a deactivate message which contains a module name. - -Remark: it is not clear, if module-wise deactivation is really useful. A SEC Node -supporting module-wise activation does not necessarily need to support module-wise -deactivation. - -Change Value -~~~~~~~~~~~~ - -the change value message contains the name of the module or parameter -and the value to be set. The value is JSON formatted, but note that for -a floating point value this is a simple decimal coded ASCII number. As -soon as the set-value is read back from the hardware, a "changed" -message is sent (in case updates are activated). If the value is not -stored in hardware, the "changed" message can be sent immediately. - -Example on a connection with activated updates. Live properties are replaced by {...} for brevity here. - -.. code:: - - > read mf:status - < update mf:status [[100,"OK"],{...}] - < change mf:target 12 - < update mf:status [[300,"ramping field"],{...}] - < changed mf:target [12,{...}] - -The status changes from "idle" to "busy". The ECS will be informed with a further update message on mf:status, when the module has finished ramping. - -Read Request -~~~~~~~~~~~~ - -With the read request message the ECS may ask the SEC node to update a -value as soon as possible, without waiting for the next regular update. -The reply is an update message. If updates are not activated, the -message can be treated like a read message in a request-reply scheme as -in the previous SECoP proposal. - -Example: - -.. code:: - - > read t1:value - < update t1:value [295.13,{"t":1505396348.188}] - > read t1:status - > update t1:status [[100,"OK"],{"t":1505396348.548}] - -Command -~~~~~~~ - -A command may have arguments. Multiple arguments can be given as a JSON list. -A command may also have a return value. The "done" reply always contains the -JSON part with at least the timestamp, if supported. If no value is returned, -the data part is set to "null". -The "done" message should be returned quickly, the time scale should be in the -order of the time needed for communications. Actions which have to wait for physical -changes, can be triggered with a command. The information about the success of -such an action has to be transferred via parameters, namely the status parameter. - -Example: - -.. code:: - - > do t1:stop - < done t1:stop [null, {"t": 1505396348.876}] - -Error Reply -~~~~~~~~~~~ - -Contains an error class from the list below as its second item. -The third item of the message is a JSON list, -containing the related request message as its first element, a human readable text -as its second element. The third element is a JSON-Object, containing possibly -implementation specific information about the error (stack dump etc.). - -Example: - -.. code:: - - > read tx:target - < error NoSuchModule ["read tx:target", "tx is not configured on this SEC node", {}] - > read ts:target - < error NoSuchParameter ["read ts:target", "ts has no parameter target", {}] - > meas:volt? - < error SyntaxError ["meas:volt?", "unknown keyword", {}] - -Error Classes - -.. list-table:: - :widths: 20 80 - - * - NoSuchModule - - The action can not be performed as the specified module is non-existent. - - * - NoSuchParameter - - The action can not be performed as the specified parameter is non-existent. - - * - NoSuchCommand - - The specified command does not exist. - - * - CommandFailed - - The command failed to execute. - - * - CommandRunning - - The command is already executing. - - * - ReadOnly - - The requested write can not be performed on a readonly value.. - - * - BadValue - - The requested write or Command can not be performed as the value is malformed or of wrong type. - - * - CommunicationFailed - - Some communication (with hardware controlled by this SEC-Node) failed. - - * - IsBusy - - The reequested write can not be performed while the Module is Busy - - * - IsError - - The requested action can not be performed while the module is in error state. - - * - Disabled - - The requested action can not be performed at the moment. (Interlocks?) - - * - SyntaxError - - A malformed Request was send - - * - InternalError - - Something that should never happen just happened. - - -Timeout Issues / Heartbeat -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to detect that the other end of the communication is not dead, -a heartbeat may be sent. The second part of the message (the id) may -not contain a space and should be short. It may be omitted. The reply -will contain exactly the same id. - -A SEC node might also decide to close a connection when it gets no -messages for a certain time. The mechanism is under discussion. - -Generally speaking: both -ECS and SEC side needs to be aware that the other side may close the -connection at any time! - -Example: - -.. code:: - - > ping 123 - < pong 123 {"t": 1505396348.543} - -The "pong" message has an additional function: it sends back the time -on the server, if it supports timestamps. This can be used to -synchronize the time. - -See also `SECoP Issue 4`_ (Timeout), `SECoP Issue 6`_ (Keep Alive), -`SECoP Issue 3`_ (Timestamps) or `SECoP Issue 7`_ (Time Synchronization) - -Multiple Connections --------------------- - -A SEC node may accept only a limited number of connections, downto 1. -However, each SEC node should support as many connections as technically -feasible. - -Details about how to multiplex multiple connections onto one are to be -discussed. - - -Descriptive Data ----------------- - -Format of Descriptive Data -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The format of the descriptive data is JSON, as all other data in SECoP. - - -.. for creating the railroad diagrams see: http://bottlecaps.de/rr/ui -.. source EBNF: -.. SEC_node_description ::= '{' (SEC_node_property ( ',' SEC_node_property)* )? '}' -.. SEC_node_property ::= property | ( '"modules":' '[' (name ',' module_description (',' name ',' module_description)*)? ']') -.. module_description ::= '{' (module_property ( ',' module_property)* )? '}' -.. module_property ::= property | ( '"parameters":' '[' (name ',' properties (',' name ',' properties)*)? ']') | ( '"commands":' '[' (name ',' properties (',' name ',' properties)*)? ']') -.. properties ::= '{' (property ( ',' property)* )? '}' -.. property ::= (name ':' property_value) - -SEC node description -^^^^^^^^^^^^^^^^^^^^ - - .. image:: diagram/sec_node_description.png - :alt: SEC_node_description ::= '{' (SEC_node_property ( ',' SEC_node_property)* )? '}' - -SEC node property -^^^^^^^^^^^^^^^^^ - - .. image:: diagram/sec_node_property.png - :alt: SEC_node_property ::= property | ( '"modules":' '[' (name ',' module_description (',' name ',' module_description)*)? ']') - -module description -^^^^^^^^^^^^^^^^^^ - - .. image:: diagram/module_description.png - :alt: module_description ::= '{' (module_property ( ',' module_property)* )? '}' - -module property -^^^^^^^^^^^^^^^ - - .. image:: diagram/module_property.png - :alt: module_property ::= property | ( '"parameters":' '[' (name ',' properties (',' name ',' properties)*)? ']') | ( '"commands":' '[' (name ',' properties (',' name ',' properties)*)? ']') - -properties -^^^^^^^^^^ - - .. image:: diagram/properties.png - :alt: properties ::= '{' (property ( ',' property)* )? '}' - -property -^^^^^^^^ - - .. image:: diagram/property.png - :alt: property ::= (name ':' property_value) - - -SEC Node Properties -~~~~~~~~~~~~~~~~~~~ - -there might be properties such as a timeout which are relevant for the -communication of a SEC node. - -- **equipment_id** - -- **description** (mandatory, a text describing the node, in general, the first - line is a short description (line break \\n)) - -- **firmware** (optional, a string describing the version of the SEC node software) - -- **timeout** (optional value in seconds, a SEC node should be able to respond within - a time well below this value. Default: 3 sec, see `SECoP issue 4`_ ) - - -Module Properties -~~~~~~~~~~~~~~~~~ - -- **description** (mandatory, a text describing the parameter) - -- **visibility** (1=expert, 2=advanced, 3=user (default)), Note: this - does not imply that the access is controlled. It may just be a - hint to the UI for the amount of exposed modules. (optional) - -- **interface\_class** (a list of classes for the module, for example - ["Temperature", "DrivableWithRamp", "Drivable", "Readable"]), - mandatory - -- **group** (optional, identifier, may contain ':' which may be interpreted as path separator) - (*see* `SECoP issue 8`_) - -- **meaning**, **importance** (*see* `SECoP issue 9`_) - - -Parameter Properties -~~~~~~~~~~~~~~~~~~~~ - -- **description** (mandatory, a text describing the parameter, mandatory) - -- **readonly** (mandatory) - -- **datatype** (mandatory, see `Data Types`_) - -- **unit** (default: unitless, should be given, if meaningfull, empty string: unit is one) - -- **visibility** (3=expert, 2=advanced, 1=user (default)), Note: this - does not imply that the access is controlled. It may just be a - hint to the UI for the amount of exposed parameters. (optional) - -- **group** (optional, identifier, may contain ':' which may be interpreted as path separator) - (*see* `SECoP issue 8`_) - -Data Types ----------- - -double -~~~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["double"] *or* - | ["double", ] *or* - | ["double", , ] - | - | if is not given or null, there is no upper limit - | if is null or not given, there is no lower limit - - * - Transport example - - | 3.14159265 - - * - Datatype in C/C++ - - | double - -int -~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["int"] *or* - | ["int", ] *or* - | ["int", , ] - | - | if is not given or null, there is no upper limit - | if is null or not given, there is no lower limit - - * - Transport example - - | -55 - - * - Datatype in C/C++ - - | int64_t - -bool -~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["bool"] - - * - Transport example - - | true - - * - Datatype in C/C++ - - | int64_t - - -enum -~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["enum", { : , ....}] - - * - Transport example - - | 2 - - * - Datatype in C/C++ - - | int64_t - - -string -~~~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["string"] *or* - | ["string", ] *or* - | ["string", , ] - | - | if is not given, it is assumed as 255. - | if is not given, it is assumed as 0. - | if the string is UTF-8 encoded, the length is counting the number of bytes, not characters - - * - Transport example - - | "hello!" - - * - Datatype in C/C++ API - - | char \* - -blob -~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["blob", ] *or* - | ["blob", , ] - | - | if is not given, it is assumed as 0. - - * - Transport example - - | "AA==" (base64 encoded) - - * - Datatype in C/C++ API - - | struct {int64_t len, char \*data} - -array -~~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["array", , ] *or* - | ["array", , , ] - | - | if is not given, it is assumed as 0. - | the length is the number of elements - - * - Transport example - - | [3,4,7,2,1] - - * - Datatype in C/C++ API - - | [] - -tuple -~~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["tuple", [, , ...]] - - * - Transport example - - | [0,"idle"] - - * - Datatype in C/C++ API - - | struct - -struct -~~~~~~ - -.. list-table:: - :widths: 20 80 - :stub-columns: 1 - - * - Datatype - - | ["struct", { : , : , ....}] - - * - Transport example - - | {"x": 0, "y": 1} - - * - Datatype in C/C++ API - - | struct - | - | might be null - -.. _`SECoP Issue 2`: SECoP_Issues/issue_2.html -.. _`SECoP Issue 3`: SECoP_Issues/issue_3.html -.. _`SECoP Issue 4`: SECoP_Issues/issue_4.html -.. _`SECoP issue 5`: SECoP_issues/issue_5.html -.. _`SECoP Issue 6`: SECoP_Issues/issue_6.html -.. _`SECoP Issue 7`: SECoP_Issues/issue_7.html -.. _`SECoP issue 8`: SECoP_issues/issue_8.html -.. _`SECoP issue 9`: SECoP_issues/issue_9.html diff --git a/doc/source/protocol/timeformat.rst b/doc/source/protocol/timeformat.rst deleted file mode 100644 index 409ca35..0000000 --- a/doc/source/protocol/timeformat.rst +++ /dev/null @@ -1,7 +0,0 @@ -Timeformat -========== - -* format goes to 'timestamp since epoch as double with a resolution of at least 1ms' -* SEC-node-property: timestamp is accurate or relative -* Or: extend pong response contains the localtime (formatted as a timestamp) - diff --git a/doc/source/protocol/todo.rst b/doc/source/protocol/todo.rst deleted file mode 100644 index 2bee8ab..0000000 --- a/doc/source/protocol/todo.rst +++ /dev/null @@ -1,101 +0,0 @@ -========= -Todo List -========= - -Open questions -============== - -* Datatype for a mapping (like the calibration for the amagnet) -* How to set a Mapping or an enum (with all the name-value mappings) in the configfile? -* use toml vs. ini parser? -* error handling should be more consistent -* error-info stuff should be consistent -* dynamic device creation / modification (i.e. how to set the mapping of an enum during runtime?) -* propagation of units from main value to params -* switch params+cmds to 'accessibles'/attributes and keep in orderdDict? - -> needs Datatype for a function -* datatype for funcion: is argin a list anyway, or just one (structured) argument? - (so far we use a list and argout is a single datatype (which may be stuctured)) -* polling: vendor specific or do we propose a common way to handle it? - (playground uses a per-device pollinterval. params may be polled less often) -* interface classes !!! (maybe with feature mixins like WindowTimeout?) -* hardware access: unify? how? -* demo-hardware? -* If more than one connection exists: shall all events be relayed to all listeners? -* how about WRITE/COMMAND replies? Shall they go to all connected clients? -* structure of descriptive data needs to be specified -* same for JSON_stuff for Error Messages -* 'changed' may be 'readback' -* 'change' may be 'write' -* 'read' may be 'poll' -* the whole message may be json object (bigger, uglier to read) -* which events are broadcast or unicast? -* do we need a way to correlate a reply with a request? - - -Todos -===== - -Structure ---------- - - * stronger structure insides src - - * src/server for everything server related - * src/client for everything client related (ProxyDevice!) - * src/protocol for protocol specific things - - * need subtree for different implementations to play with - - * src/lib for helpers and other stuff - - * possibly a parallel src tree for cpp version - - -Client ------- - - * maybe start with a python shell and some import magic - * later a GUI may be a good idea - * client: one connection for each device? - * another connection for async data? - - -Server ------- - - * rewrite MessageHandler to be agnostic of server - * move encoding to interface - * allow multiple interfaces per server - * fix error handling an make it consistent - -Device framework ----------------- - - * supply properties for PARAMS to auto-generate async data units - * self-polling support - * generic devicethreads - * proxydevice - * make get_device uri-aware - - -Testsuite ---------- - - * need a testsuite (pytest) - * embedded tests inside the actual files grow difficult to maintain - - -Documentation -------------- - - * transfer build docu into wiki via automated jobfile - - - - -Transfer of blobs via json --------------------------- - - * use base64 - diff --git a/doc/source/playground/server/configuration.rst b/doc/source/server/configuration.rst similarity index 100% rename from doc/source/playground/server/configuration.rst rename to doc/source/server/configuration.rst diff --git a/doc/source/playground/server/index.rst b/doc/source/server/index.rst similarity index 100% rename from doc/source/playground/server/index.rst rename to doc/source/server/index.rst diff --git a/doc/source/playground/server/modules.rst b/doc/source/server/modules.rst similarity index 100% rename from doc/source/playground/server/modules.rst rename to doc/source/server/modules.rst diff --git a/doc/source/playground/server/protocol/index.rst b/doc/source/server/protocol/index.rst similarity index 73% rename from doc/source/playground/server/protocol/index.rst rename to doc/source/server/protocol/index.rst index fa819cc..2b01466 100644 --- a/doc/source/playground/server/protocol/index.rst +++ b/doc/source/server/protocol/index.rst @@ -4,7 +4,5 @@ protocol stack .. toctree:: :maxdepth: 3 - encoding - framing/index interface/index diff --git a/doc/source/playground/server/protocol/interface/index.rst b/doc/source/server/protocol/interface/index.rst similarity index 100% rename from doc/source/playground/server/protocol/interface/index.rst rename to doc/source/server/protocol/interface/index.rst diff --git a/doc/source/playground/server/protocol/interface/tcp.rst b/doc/source/server/protocol/interface/tcp.rst similarity index 100% rename from doc/source/playground/server/protocol/interface/tcp.rst rename to doc/source/server/protocol/interface/tcp.rst diff --git a/doc/source/playground/server/protocol/interface/zmq.rst b/doc/source/server/protocol/interface/zmq.rst similarity index 100% rename from doc/source/playground/server/protocol/interface/zmq.rst rename to doc/source/server/protocol/interface/zmq.rst diff --git a/doc/source/playground/server/starting.rst b/doc/source/server/starting.rst similarity index 100% rename from doc/source/playground/server/starting.rst rename to doc/source/server/starting.rst