# Presentation: 329898

## Message Names

- 4/8/99

## SmartSockets Scenario

- Messages have a “type” and a “subject”
- The type refers to the format - list of types of each field
- The subject is a name for the message
- Messages can be of the same type but have different subjects
- Messages with the same subject must have the same type
- Filtering can be done on both type and subject
- Default is no restrictions on number of publishers/subscribers of/to a subject
- Can declare to rtserver that a subject should only be published by one source
- Also, one declares “project” names when connecting to the server.
- No inter-project communcation can occur
- Probably mainly useful for limiting random external access?

## Message Names

- Names are hierarchical, of the form/field1/field2/field3/field4...
- Must begin with a /
- If they don’t, a configurable default is automatically prepended.
- Two types of matching are allowed:
- Wild card within a field:
- /field1/fie*ld*/field4
- More complicated regexp matching not supported
- Wild card matches do not span fields
- the above does **not** match/field1/fie**ld2**/**fie**ld3/field4
- A * at the start or end does not add fields
- Multiple fields:
- /field1/.../field4
- the ... matches any number of intermediate fields
- /... can appear at the end and will match any number of trailing fields
- So this does match the top expression

## Message Usage

- Status messages
- Back to run control in reply to state change or other commands
- To DAQ status monitors
- Sometimes desirable to identify exact source
- But would like to conveniently filter on higher level description
- For example, receive information from all front-end crates, without necessarily separately subscribing to each one
- Command messages
- From run control to DAQ components
- Would like to pseudo-multicast to a subsystem
- For example send to all the front-end crates, without separately sending to each one

## General Filter Criteria

- Partition ID
- Partition_1 - 8
- Note that some things will have to be explicitly told their partition and adjust their subscriptions accordingly
- SubSystem
- FrontEnd (Sub-SubSystem)
- CentralCalorimeter (Sub-Sub-Subsystem etc.)
- Central_East_0 (crate name in database)
- EventBuilder
- ?
- Level 3
- ConsumerServer
- DataLogger
- Monitor programs
- Status
- Error messages
- Other types of status
- Commands
- Types of commands (?)

## Examples

- /Partition_2/FrontEnd/Command/StateChange
- /Partition_2/FrontEnd/CentralCalorimeter/Central_East_0/Status/ErrorMessage
- /Partition_2/FrontEnd/Central_East_0/Status/General

## SmartSockets Message Formats

- Messages are effectively containers of fields
- Fields may be int4, int8, real8 etc.
- Can also be arrays, and even nested messages, and even arrays of nested messages
- Can specify repeated set of fields at the end of a format
- To parse, set the “cursor” to the beginning, then iterate getting the next fieldmsg.setCurrent(0);msg.nextInt4();msg.nextString();
- Constructing a message is just the inverse
- It is up to the user to know what type of data each field is
- This is NOT contained in the message (only an ID #)

## Message Format cont.

- Formats have to be defined for machine-independent translation
- Several “canned” formats exist. Most common are:
- INFO - just a string
- NUMERIC_DATA - alternating strings and double (8 byte floating point)
- HISTORY_ENUM_DATA - time followed by NUMERIC_DATA
- Possible to create custom types
- TipcSvc.createMt(“MessageName”, // convenience only		MESSAGE_NUMBER, // used as real ID		“int4 int8 string etc”)     // format
- Must ensure that message numbers are unique - harder than for names

## DIM Scenario

- Names are also hierarchical, of the formClient/field1/field2/field3/...
- The first field is a “client” or “domain” name
- Names must not begin with a /
- There is no wild card matching
- There are “data” and “command” services
- A data service with some name can only be published by one task
- Task must declare up front what it is going to publish
- A command service with some name can only be subscribed by one task
- The above formats can almost work.
- However as there is no wildcard matching then every data subscription and command sent must use the full name.
- For example to subscribe to error messages, a message logger must subscribe separately to everything in the system that can produce them.

## DIM message formats

- Currently supports a mix of int, float, and string
- for example: l:3;d:1;s:3;f:1;c:20;l
- The last single type is assumed to be repeated
- No nested formats
- No separate registering of message types
- Format is associated with the name when subject is initially declared

## Run Configuration Database

- Run Type
- Number of events (or unbounded)
- Trigger (Trigger table or external trigger input channel)
- Max event size in readout controller (more for calibrations)
- Readout controller buffer configuration (fewer larger buffers for calibrations)
- For internal calibrations, number of triggers per read out event
- Trigger Supervisor timeouts (not actually varied much)
- Clock configuration (not much to vary in Run II)
- Data correction mode (apply gain/offset correction or not)
- Readout controller program (due to limited memory had different ones for different run types/detector components)
- List of components to be enabled for readout
- Calibration controller parameters
- Interpreted on run type specific basis - no standard format
- List of consumers to be automatically started
- Commands sent to consumers kept in a different file