From b35323264144a93f0e24036d9d0b02b5a6ebcbe1 Mon Sep 17 00:00:00 2001 From: Christopher Faulet Date: Fri, 12 Jul 2024 16:38:47 +0200 Subject: [PATCH] DOC: spoe: Update SPOE documentation to reflect recent refactoring The SPOE was refactored. Several parameters were deprecated. Fragmentation and async capabilities support were removed. The default log-format was updated too. So, the SPOE documentation was updated accordingly. The related issue is #2502. --- doc/SPOE.txt | 319 +++++++++++++++++++-------------------------------- 1 file changed, 117 insertions(+), 202 deletions(-) diff --git a/doc/SPOE.txt b/doc/SPOE.txt index cc6d8dd3d..6b3de69f0 100644 --- a/doc/SPOE.txt +++ b/doc/SPOE.txt @@ -1,7 +1,7 @@ ----------------------------------------------- Stream Processing Offload Engine (SPOE) Version 1.2 - ( Last update: 2020-06-13 ) + ( Last update: 2024-07-12 ) ----------------------------------------------- Author : Christopher Faulet Contact : cfaulet at haproxy dot com @@ -69,13 +69,10 @@ systems (often at least the connect() is blocking). So, it is hard to properly implement Single Sign On solution (SSO) in HAProxy. The SPOE will ease this kind of processing, or we hope so. -Now, the aim of SPOE is to allow any kind of offloading on the streams. First -releases won't do lot of things. As we will see, there are few handled events -and even less actions supported. Actually, for now, the SPOE can offload the -processing before "tcp-request content", "tcp-response content", "http-request" -and "http-response" rules. And it only supports variables definition. But, in -spite of these limited features, we can easily imagine to implement SSO -solution, ip reputation or ip geolocation services. +The aim of SPOE is to allow any kind of offloading on the streams. It can +offload the processing before "tcp-request content", "tcp-response content", +"http-request" and "http-response" rules. It is also possible to offload the +processing via an TCP/HTTP rule. Some example implementations in various languages are linked to from the HAProxy Wiki page dedicated to this mechanism: @@ -85,8 +82,8 @@ HAProxy Wiki page dedicated to this mechanism: 2. SPOE configuration ---------------------- -Because SPOE is implemented as a filter, To use it, you must declare a "filter -spoe" line in a proxy section (frontend/backend/listen) : +Because SPOE is implemented as a filter, To use it, a "filter spoe" line must +be declared xin a proxy section (frontend/backend/listen) : frontend my-front ... @@ -99,9 +96,10 @@ the SPOE configuration. So it is possible to use the same SPOE configuration for several engines. If no name is provided, the SPOE configuration must not contain any scope directive. -We use a separate configuration file on purpose. By commenting SPOE filter -line, you completely disable the feature, including the parsing of sections -reserved to SPOE. This is also a way to keep the HAProxy configuration clean. +Using a separate configuration file makes possible to disable completely an +engine by only commenting the SPOE filter line, including the parsing of +sections reserved to SPOE. This is also a way to keep the HAProxy configuration +clean. A SPOE configuration file must contains, at least, the SPOA configuration ("spoe-agent" section) and SPOE messages/groups ("spoe-message" or "spoe-group" @@ -114,12 +112,13 @@ file. 2.1. SPOE scope ------------------------- -If you specify an engine name on the SPOE filter line, then you need to define -scope in the SPOE configuration with the same name. You can have several SPOE -scope in the same file. In each scope, you must define one and only one -"spoe-agent" section to configure the SPOA linked to your SPOE and several -"spoe-message" and "spoe-group" sections to describe, respectively, messages and -group of messages sent to servers managed by your SPOA. +If an engine name is specified on the SPOE filter line, then the corresponding +scope must be defined in the SPOE configuration with the same name. It is +possible to have several SPOE scopes in the same file. In each scope, one and +only one "spoe-agent" section must be defined, to configure the SPOA linked to +the defined engine and several "spoe-message" and "spoe-group" sections to +describe, respectively, messages and group of messages sent to servers managed +the SPOA. A SPOE scope starts with this kind of line : @@ -148,15 +147,15 @@ If no engine name is provided on the SPOE filter line, no SPOE scope must be found in the SPOE configuration file. All the file is considered to be in the same anonymous and implicit scope. -The engine name must be uniq for a proxy. If no engine name is provided on the -SPOE filter line, the SPOE agent name is used by default. +The engine name must be unique for a proxy. If no engine name is provided on +the SPOE filter line, the SPOE agent name is used by default. 2.2. "spoe-agent" section -------------------------- -For each engine, you must define one and only one "spoe-agent" section. In this -section, you will declare SPOE messages and the backend you will use. You will -also set timeouts and options to customize your agent's behaviour. +For each engine, exactly one "spoe-agent" section must be defined. Enabled SPOE +messages are declared in this section, and all the parameters (timeout, +options, ...) used to customize the agent behavior. spoe-agent @@ -169,15 +168,10 @@ spoe-agent following keywords are supported : - groups - log - - maxconnrate - - maxerrrate - max-frame-size - - max-waiting-frames - messages - - [no] option async - [no] option dontlog-normal - [no] option pipelining - - [no] option send-frag-payload - option continue-on-error - option force-set-var - option set-on-error @@ -185,9 +179,16 @@ spoe-agent - option set-total-time - option var-prefix - register-var-names - - timeout hello|idle|processing + - timeout processing - use-backend + following keywords are deprecated and ignored: + - maxconnrate + - maxerrrate + - max-waiting-frames + - [no] option async + - [no] option send-frag-payload + - timeout hello|idle groups ... Declare the list of SPOE groups that an agent will handle. @@ -196,11 +197,11 @@ groups ... is the name of a SPOE group. Groups declared here must be found in the same engine scope, else an error is - triggered during the configuration parsing. You can have many "groups" lines. + triggered during the configuration parsing. Several "groups" lines can be + defined. See also: "spoe-group" section. - log global log
[len ] [format ] [ []] no log @@ -211,28 +212,35 @@ no log See the HAProxy Configuration Manual for details about this option. -maxconnrate +maxconnrate [DEPRECATED] Set the maximum number of connections per second to . The SPOE will stop to open new connections if the maximum is reached and will wait to acquire an existing one. So it is important to set "timeout hello" to a relatively small value. + This parameter is now deprecated and ignored. It will be removed in future + versions. -maxerrrate +maxerrrate [DEPRECATED] Set the maximum number of errors per second to . The SPOE will stop its processing if the maximum is reached. + This parameter is now deprecated and ignored. It will be removed in future + versions. max-frame-size Set the maximum allowed size for frames exchanged between HAProxy and SPOA. It must be in the range [256, tune.bufsize-4] (4 bytes are reserved for the frame length). By default, it is set to (tune.bufsize-4). -max-waiting-frames +max-waiting-frames [DEPRECATED] Set the maximum number of frames waiting for an acknowledgement on the same connection. This value is only used when the pipelinied or asynchronous exchanges between HAProxy and SPOA are enabled. By default, it is set to 20. + This parameter is now deprecated and ignored. It will be removed in future + versions. + messages ... Declare the list of SPOE messages that an agent will handle. @@ -240,23 +248,24 @@ messages ... is the name of a SPOE message. Messages declared here must be found in the same engine scope, else an error - is triggered during the configuration parsing. You can have many "messages" - lines. + is triggered during the configuration parsing. Several "messages" lines can + be defined. See also: "spoe-message" section. - -option async +option async [DEPRECATED] no option async Enable or disable the support of asynchronous exchanges between HAProxy and SPOA. By default, this option is enabled. + This parameter is now deprecated and ignored. It will be removed in future + versions. option continue-on-error Do not stop the events processing when an error occurred on a stream. By default, for a specific stream, when an abnormal/unexpected error occurs, - the SPOE is disabled for all the transaction. So if you have several events + the SPOE is disabled for all the transaction. if several events are configured, such error on an event will disabled all following. For TCP streams, this will disable the SPOE for the whole session. For HTTP streams, this will disable it for the transaction (request and response). @@ -264,7 +273,6 @@ option continue-on-error When set, this option bypass this behaviour and only the current event will be ignored. - option dontlog-normal no option dontlog-normal Enable or disable logging of normal, successful processing. @@ -273,29 +281,27 @@ no option dontlog-normal See also: "log" and section 4 about logging. - option force-set-var By default, SPOE filter only register already known variables (mainly from parsing of the configuration), and process-wide variables (those of scope - "proc") cannot be created. If you want that haproxy trusts the agent and - registers all variables (ex: can be useful for LUA workload), activate this - option. + "proc") cannot be created. If HAProxy trusts the agent and registers all + variables (ex: can be useful for LUA workload), this option can be sets. Caution : this option opens to a variety of attacks such as a rogue SPOA that asks to register too many variables. - option pipelining no option pipelining Enable or disable the support of pipelined exchanges between HAProxy and SPOA. By default, this option is enabled. - -option send-frag-payload +option send-frag-payload [DEPRECATED] no option send-frag-payload Enable or disable the sending of fragmented payload to SPOA. By default, this option is enabled. + This parameter is now deprecated and ignored. It will be removed in future + versions. option set-on-error Define the variable to set when an error occurred during an event processing. @@ -307,13 +313,13 @@ option set-on-error This variable will only be set when an error occurred in the scope of the transaction. As for all other variables define by the SPOE, it will be - prefixed. So, if your variable name is "error" and your prefix is + prefixed. So, if the variable name is "error" and the prefix is "my_spoe_pfx", the variable will be "txn.my_spoe_pfx.error". When set, the variable is an integer representing the error reason. For values under 256, it represents an error coming from the engine. Below 256, it reports a SPOP error. In this case, to retrieve the right SPOP status code, - you must remove 256 to this value. Here are possible values: + 256 must be removed from this value. Here are possible values: * 1 a timeout occurred during the event processing. @@ -347,8 +353,8 @@ option set-process-time contain characters 'a-z', 'A-Z', '0-9', '.' and '_'. This variable will be set in the scope of the transaction. As for all other - variables define by the SPOE, it will be prefixed. So, if your variable name - is "process_time" and your prefix is "my_spoe_pfx", the variable will be + variables define by the SPOE, it will be prefixed. So, if the variable name + is "process_time" and the prefix is "my_spoe_pfx", the variable will be "txn.my_spoe_pfx.process_time". When set, the variable is an integer representing the delay to process the @@ -360,7 +366,6 @@ option set-process-time See also: "option set-total-time". - option set-total-time Define the variable to set to report the total processing time SPOE for a stream. @@ -371,8 +376,8 @@ option set-total-time contain characters 'a-z', 'A-Z', '0-9', '.' and '_'. This variable will be set in the scope of the transaction. As for all other - variables define by the SPOE, it will be prefixed. So, if your variable name - is "total_time" and your prefix is "my_spoe_pfx", the variable will be + variables define by the SPOE, it will be prefixed. So, if the variable name + is "total_time" and the prefix is "my_spoe_pfx", the variable will be "txn.my_spoe_pfx.total_time". When set, the variable is an integer representing the sum of processing times @@ -384,7 +389,6 @@ option set-total-time See also: "option set-process-time". - option var-prefix Define the prefix used when variables are set by an agent. @@ -399,19 +403,19 @@ option var-prefix The prefix will be added between the variable scope and its name, separated by a '.'. It may only contain characters 'a-z', 'A-Z', '0-9', '.' and '_', as - for variables name. In HAProxy configuration, you need to use this prefix as - a part of the variables name. For example, if an agent define the variable - "myvar" in the "txn" scope, with the prefix "my_spoe_pfx", then you should - use "txn.my_spoe_pfx.myvar" name in your HAProxy configuration. + for variables name. In HAProxy configuration, this prefix must be used as a + part of the variables name. For example, if an agent define the variable + "myvar" in the "txn" scope, with the prefix "my_spoe_pfx", then + "txn.my_spoe_pfx.myvar" name must be used in HAProxy configuration. By default, an agent will never set new variables at runtime: It can only set - new value for existing ones. If you want a different behaviour, see - force-set-var option and register-var-names directive. + new value for existing ones. To change this behaviour, see "force-set-var" + option and "register-var-names" directive. register-var-names ... Register some variable names. By default, an agent will not be allowed to set new variables at runtime. This rule can be totally relaxed by setting the - option "force-set-var". If you know all the variables you will need, this + option "force-set-var". If all the required variables are known, this directive is a good way to register them without letting an agent doing what it want. This is only required if these variables are not referenced anywhere in the HAProxy configuration or the SPOE one. @@ -420,12 +424,12 @@ register-var-names ... is a variable name without the scope. The name may only contain characters 'a-z', 'A-Z', '0-9', '.' and '_'. - The prefix will be automatically added during the registration. You can have - many "register-var-names" lines. + The prefix will be automatically added during the registration. Several + "register-var-names" lines can be used. See also: "option force-set-var", "option var-prefix". -timeout hello +timeout hello [DEPRECATED] Set the maximum time to wait for an agent to receive the AGENT-HELLO frame. It is applied on the stream that handle the connection with the agent. @@ -437,8 +441,10 @@ timeout hello This timeout is an applicative timeout. It differ from "timeout connect" defined on backends. + This parameter is now deprecated and ignored. It will be removed in future + versions. -timeout idle +timeout idle [DEPRECATED] Set the maximum time to wait for an agent to close an idle connection. It is applied on the stream that handle the connection with the agent. @@ -447,6 +453,8 @@ timeout idle can be in any other unit if the number is suffixed by the unit, as explained at the top of this document. + This parameter is now deprecated and ignored. It will be removed in future + versions. timeout processing Set the maximum time to wait for a stream to process an event, i.e to acquire @@ -482,21 +490,19 @@ spoe-message Arguments : is the name of the SPOE message. - Here you define a message that can be referenced in a "spoe-agent" - section. Following keywords are supported : + Here a message that can be referenced in a "spoe-agent" section is + defined. Following keywords are supported : - acl - args - event See also: "spoe-agent" section. - acl [flags] [operator] ... Declare or complete an access list. See section 7 about ACL usage in the HAProxy Configuration Manual. - args [name=] ... Define arguments passed into the SPOE message. @@ -510,7 +516,6 @@ args [name=] ... For example: args frontend=fe_id src dst - event [ { if | unless } ] Set the event that triggers sending of the message. It may optionally be followed by an ACL-based condition, in which case it will only be evaluated @@ -552,13 +557,12 @@ spoe-group Arguments : is the name of the SPOE group. - Here you define a group of SPOE messages that can be referenced in a + Here a group of SPOE messages is defined. It can be referenced in a "spoe-agent" section. Following keywords are supported : - - messages + - messages See also: "spoe-agent" and "spoe-message" sections. - messages ... Declare the list of SPOE messages belonging to the group. @@ -567,7 +571,7 @@ messages ... Messages declared here must be found in the same engine scope, else an error is triggered during the configuration parsing. Furthermore, a message belongs - at most to a group. You can have many "messages" lines. + at most to a group. Several "messages" lines can be defined. See also: "spoe-message" section. @@ -598,7 +602,7 @@ and 0 a blacklisted IP with no doubt). server http A.B.C.D:80 backend iprep-servers - mode tcp + mode spop balance roundrobin timeout connect 5s # greater than hello timeout @@ -616,8 +620,6 @@ and 0 a blacklisted IP with no doubt). option var-prefix iprep - timeout hello 2s - timeout idle 2m timeout processing 10ms use-backend iprep-servers @@ -714,62 +716,37 @@ actions. +---+---+----------+ FIN: Indicates that this is the final payload fragment. The first fragment - may also be the final fragment. + may also be the final fragment. The payload fragmentation was removed + and is now deprecated. It means the FIN flag must be set on all + frames. ABORT: Indicates that the processing of the current frame must be - cancelled. This bit should be set on frames with a fragmented - payload. It can be ignore for frames with an unfragemnted - payload. When it is set, the FIN bit must also be set. + cancelled. Frames cannot exceed a maximum size negotiated between HAProxy and agents during the HELLO handshake. Most of time, payload will be small enough to send -it in one frame. But when supported by the peer, it will be possible to -fragment huge payload on many frames. This ability is announced during the -HELLO handshake and it can be asynmetric (supported by agents but not by -HAProxy or the opposite). The following rules apply to fragmentation: - - * An unfragemnted payload consists of a single frame with the FIN bit set. - - * A fragemented payload consists of several frames with the FIN bit clear and - terminated by a single frame with the FIN bit set. All these frames must - share the same STREAM-ID and FRAME-ID. The first frame must set the right - FRAME-TYPE (e.g, NOTIFY). The following frames must have an unset type (0). - -Beside the support of fragmented payload by a peer, some payload must not be -fragmented. See below for details. +it in one frame. IMPORTANT : The maximum size supported by peers for a frame must be greater -than or equal to 256 bytes. + than or equal to 256 bytes. A good common value is the HAProxy + buffer size minus 4 bytes, reserved for the frame length + (tune.bufsize - 4). It is the default value announced by HAproxy. 3.2.1. Frame capabilities -------------------------- Here are the list of official capabilities that HAProxy and agents can support: - * fragmentation: This is the ability for a peer to support fragmented - payload in received frames. This is an asymmectical - capability, it only concerns the peer that announces - it. This is the responsibility to the other peer to use it - or not. - * pipelining: This is the ability for a peer to decouple NOTIFY and ACK frames. This is a symmectical capability. To be used, it must be supported by HAProxy and agents. Unlike HTTP pipelining, the ACK frames can be send in any order, but always on the same TCP connection used for the corresponding NOTIFY frame. - * async: This ability is similar to the pipelining, but here any TCP - connection established between HAProxy and the agent can be used to - send ACK frames. if an agent accepts connections from multiple - HAProxy, it can use the "engine-id" value to group TCP - connections. See details about HAPROXY-HELLO frame. - Unsupported or unknown capabilities are silently ignored, when possible. -NOTE: HAProxy does not support the fragmentation for now. This means it is not - able to handle fragmented frames. However, if an agent announces the - fragmentation support, HAProxy may choose to send fragemented frames. +NOTE: Fragmentation and async capabilities were deprecated and are now ignored. 3.2.2. Frame types overview ---------------------------- @@ -778,9 +755,6 @@ Here are types of frame supported by SPOE. Frames sent by HAProxy come first, then frames sent by agents : TYPE | ID | DESCRIPTION - -----------------------------+-----+------------------------------------- - UNSET | 0 | Used for all frames but the first when a - | | payload is fragmented. -----------------------------+-----+------------------------------------- HAPROXY-HELLO | 1 | Sent by HAProxy when it opens a | | connection on an agent. @@ -801,7 +775,8 @@ then frames sent by agents : ACK | 103 | Sent to acknowledge a NOTIFY frame -----------------------------+-----+------------------------------------- -Unknown frames may be silently skipped. +Unknown frames may be silently skipped or trigger an error, depending on the +implementation. 3.2.3. Workflow ---------------- @@ -865,37 +840,6 @@ Unknown frames may be silently skipped. | <-------------------------- | | | - * Notify / Ack exchange (fragmented payload): - - HAPROXY AGENT SRV - | NOTIFY (frag 1) | - | --------------------------> | - | | - | UNSET (frag 2) | - | --------------------------> | - | ... | - | UNSET (frag N) | - | --------------------------> | - | | - | ACK | - | <-------------------------- | - | | - - * Aborted fragmentation of a NOTIFY frame: - - HAPROXY AGENT SRV - | ... | - | UNSET (frag X) | - | --------------------------> | - | | - | ACK/ABORT | - | <-------------------------- | - | | - | UNSET (frag X+1) | - | -----------X | - | | - | | - * Connection closed by haproxy: HAPROXY AGENT SRV @@ -917,8 +861,8 @@ Unknown frames may be silently skipped. ---------------------------- This frame is the first one exchanged between HAProxy and an agent, when the -connection is established. The payload of this frame is a KV-LIST. It cannot be -fragmented. STREAM-ID and FRAME-ID are must be set 0. +connection is established. The payload of this frame is a KV-LIST. STREAM-ID +and FRAME-ID are must be set 0. Following items are mandatory in the KV-LIST: @@ -963,7 +907,7 @@ AGENT-DISCONNECT frame must be returned. This frame is sent in reply to a HAPROXY-HELLO frame to finish a HELLO handshake. As for HAPROXY-HELLO frame, STREAM-ID and FRAME-ID are also set -0. The payload of this frame is a KV-LIST and it cannot be fragmented. +0. The payload of this frame is a KV-LIST. Following items are mandatory in the KV-LIST: @@ -997,8 +941,7 @@ will close the connection at the end of the health check. Information are sent to the agents inside NOTIFY frames. These frames are attached to a stream, so STREAM-ID and FRAME-ID must be set. The payload of -NOTIFY frames is a LIST-OF-MESSAGES and, if supported by agents, it can be -fragmented. +NOTIFY frames is a LIST-OF-MESSAGES. NOTIFY frames must be acknowledge by agents sending an ACK frame, repeating right STREAM-ID and FRAME-ID. @@ -1008,8 +951,7 @@ right STREAM-ID and FRAME-ID. ACK frames must be sent by agents to reply to NOTIFY frames. STREAM-ID and FRAME-ID found in a NOTIFY frame must be reuse in the corresponding ACK -frame. The payload of ACK frames is a LIST-OF-ACTIONS and, if supported by -HAProxy, it can be fragmented. +frame. The payload of ACK frames is a LIST-OF-ACTIONS. 3.2.8. Frame: HAPROXY-DISCONNECT --------------------------------- @@ -1019,8 +961,8 @@ frame is sent with information describing the error. HAProxy will wait an AGENT-DISCONNECT frame in reply. All other frames will be ignored. The agent must then close the socket. -The payload of this frame is a KV-LIST. It cannot be fragmented. STREAM-ID and -FRAME-ID are must be set 0. +The payload of this frame is a KV-LIST. STREAM-ID and FRAME-ID are must be set +0. Following items are mandatory in the KV-LIST: @@ -1042,8 +984,8 @@ is sent, with information describing the error. such frame is also sent in reply to a HAPROXY-DISCONNECT. The agent must close the socket just after sending this frame. -The payload of this frame is a KV-LIST. It cannot be fragmented. STREAM-ID and -FRAME-ID are must be set 0. +The payload of this frame is a KV-LIST. STREAM-ID and FRAME-ID are must be set +0. Following items are mandatory in the KV-LIST: @@ -1060,10 +1002,10 @@ For more information about known errors, see section "Errors & timeouts" 3.3. Events & Messages ----------------------- -Information about streams are sent in NOTIFY frames. You can specify which kind -of information to send by defining "spoe-message" sections in your SPOE -configuration file. for each "spoe-message" there will be a message in a NOTIFY -frame when the right event is triggered. +Information about streams are sent in NOTIFY frames. It is possible to specify +which kind of information to send by defining "spoe-message" sections in the +SPOE configuration file. for each "spoe-message" there will be a message in a +NOTIFY frame when the right event is triggered. A NOTIFY frame is sent for an specific event when there is at least one "spoe-message" attached to this event. All messages for an event will be added @@ -1185,21 +1127,15 @@ An agent can define its own errors using a not yet assigned status code. IMPORTANT NOTE: By default, for a specific stream, when an abnormal/unexpected error occurs, the SPOE is disabled for all the transaction. So - if you have several events configured, such error on an event - will disabled all following. For TCP streams, this will - disable the SPOE for the whole session. For HTTP streams, this - will disable it for the transaction (request and response). - See 'option continue-on-error' to bypass this limitation. + if several events are configured, such error on an event will + disabled all following. For TCP streams, this will disable the + SPOE for the whole session. For HTTP streams, this will disable + it for the transaction (request and response). See 'option + continue-on-error' to bypass this limitation. -To avoid a stream to wait undefinetly, you must carefully choose the -acknowledgement timeout. In most of cases, it will be quiet low. But it depends -on the responsivness of your service. - -You must also choose idle timeout carefully. Because connection with your -service depends on the backend configuration used by the SPOA, it is important -to use a lower value for idle timeout than the server timeout. Else the -connection will be closed by HAProxy. The same is true for hello timeout. You -should choose a lower value than the connect timeout. +To avoid a stream to wait undefinetly, A processing timeout should be carefully +defined. Most of time, it will be quiet low. But it depends on the SPOA +responsivness. 4. Logging ----------- @@ -1214,40 +1150,19 @@ LOG_NOTICE. Otherwise, the message is logged with the level LOG_WARNING. The messages are logged using the agent's logger, if defined, and use the following format: - SPOE: [AGENT] sid=STREAM-ID st=STATUS-CODE reqT/qT/wT/resT/pT \ - / / / + SPOE: [AGENT] sid=STREAM-ID st=STATUS-CODE pT / AGENT is the agent name TYPE is EVENT of GROUP NAME is the event or the group name STREAM-ID is an integer, the unique id of the stream STATUS_CODE is the processing's status code - reqT/qT/wT/resT/pT are the following time events: - - * reqT : the encoding time. It includes ACLs processing, if any. For - fragmented frames, it is the sum of all fragments. - * qT : the delay before the request gets out the sending queue. For - fragmented frames, it is the sum of all fragments. - * wT : the delay before the response is received. No fragmentation - supported here. - * resT : the delay to process the response. No fragmentation supported - here. - * pT : the delay to process the event or the group. From the stream - point of view, it is the latency added by the SPOE processing. - It is more or less the sum of values above. - - is the numbers of idle SPOE applets - is the numbers of SPOE applets - is the numbers of streams waiting to send data - is the numbers of streams waiting for a ack + pT is the delay to process the event or the group. + From the stream point of view, it is the latency added + by the SPOE processing. is the numbers of processing errors is the numbers of events/groups processed - -For all these time events, -1 means the processing was interrupted before the -end. So -1 for the queue time means the request was never dequeued. For -fragmented frames it is harder to know when the interruption happened. - /* * Local variables: * fill-column: 79