CWIIP key terms

A messaging pattern where clients send messages to named topics through a broker, and other clients receive them by subscribing to topic filters; senders and receivers never address each other directly.

The central server in MQTT that accepts client connections, authenticates them, receives published messages, and forwards each message to the clients whose subscriptions match the topic.

A per-message delivery guarantee level: QoS 0 sends once with no acknowledgement, QoS 1 delivers at least once and may duplicate, QoS 2 delivers exactly once through a four-part handshake.

A subscription string that may contain the single-level wildcard plus (+) or the multi-level wildcard hash (#), matching a set of topic names; wildcards are allowed in subscriptions but not in published topic names.

A message the broker stores on a topic so that every new subscriber immediately receives the most recent value, which is how devices publish current state without waiting for a subscriber to appear.

A message a client registers at connect time that the broker publishes on the client's behalf if the connection drops abnormally, giving other systems a fast signal that the device went offline.

The maximum period in seconds a client may stay silent before the broker expects a PINGREQ; exceeding roughly one and a half times this interval causes the broker to close the connection.

A REST-style exchange over UDP in which a client sends a confirmable or non-confirmable request with a method code and the server answers with a response code and optional payload.

A CoAP message type that requires an acknowledgement from the peer; if none arrives the sender retransmits with exponential backoff, trading reliability for extra traffic on constrained links.

An extension that lets a client register interest in a resource so the server pushes a new notification whenever the representation changes, avoiding repeated polling by constrained devices.

A mechanism that splits a large CoAP payload into numbered blocks so it can be carried over links with small maximum transmission units, with the receiver requesting each subsequent block.

A data-centric middleware model in which writers publish typed samples on a topic and readers receive them, with no broker required and matching driven by topic name and data type.

A named set of configurable contracts, such as reliability, durability, deadline, and history depth, that both publisher and subscriber must satisfy before the middleware connects them.

The entry point object a DDS application creates to join a domain; from it the application creates publishers, subscribers, topics, data writers, and data readers.

The routing entity in AMQP that receives published messages and forwards copies to bound queues according to its type, such as direct, topic, fanout, or headers.

A declared rule linking an exchange to a queue, optionally with a routing key or header arguments, that determines which messages the exchange places on that queue.

A consumer's confirmation to the broker that a delivered message was processed, after which the broker deletes it; unacknowledged messages are redelivered when the channel closes.

A TLS configuration in which both the client and the server present certificates that the other side validates, so a device cannot connect unless it holds a certificate the broker or gateway trusts.

A signed digital document binding a device's public key to its identity, issued by a certificate authority and used during TLS handshakes to prove which device is connecting.

The process of invalidating a previously issued certificate before its expiry, typically through a revocation list or an online status protocol, so a compromised device loses access promptly.

A tamper-resistant component that generates and stores private keys and performs cryptographic operations internally, so key material never leaves the chip in readable form.

A startup chain in which each stage verifies a cryptographic signature over the next stage before running it, preventing modified firmware from executing on a device.

Delivering firmware to fielded devices remotely, normally with a signed image, a version check, and a rollback path so a failed update does not leave the device unusable.

An authorization model in which permissions are assigned to roles and users or devices are granted roles, so access policy changes are made in one place rather than per identity.

Granting each user, service, or device only the permissions it needs for its task, which limits the damage an attacker can cause after compromising one credential.

A store optimized for timestamped measurements, using time-based partitioning and compression so that high-rate sensor writes and range queries over recent windows stay fast.

A rule that automatically deletes or archives records older than a defined age or count, controlling storage growth for streams of device telemetry that lose value over time.

Reducing the resolution of stored measurements by aggregating them into coarser intervals, such as hourly averages, so long-range queries stay cheap while raw detail ages out.

A group of reads and writes executed as one unit that either commits entirely or rolls back entirely, preserving consistency when several records must change together.

The four guarantees of a transactional database: atomicity, so partial changes never persist; consistency, so constraints hold; isolation, so concurrent work does not interfere; and durability, so committed data survives failure.

A strategy that lets transactions proceed without locks and checks at commit time whether the data changed meanwhile, aborting and retrying the transaction if a conflict is detected.

Code that produces the same stored result whether it processes a message once or several times, which makes retries and duplicate deliveries safe in at-least-once messaging systems.

An HTTP interface that models resources with URLs and uses standard methods such as GET, POST, PUT, and DELETE, with status codes conveying the outcome of each request.

A secret string issued to a client and sent with each request to identify the calling application; it is simple to implement but does not by itself prove user identity.

Splitting a large API result set into pages using a limit and an offset or cursor, so clients fetch data in bounded chunks instead of one oversized response.

A server-side cap on how many requests a client may make in a time window, protecting shared resources and returning a specific status code when the cap is exceeded.

Resending a failed request after waiting progressively longer between attempts, often with random jitter, so a struggling service is not overwhelmed by synchronized retries.

An isolated directory holding a project-specific interpreter link and installed packages, so dependency versions for one project do not conflict with those of another.

Recording exact package versions, usually in a lock file, so that installs on another machine or at a later date reproduce the same tested combination of libraries.

A public repository from which the pip installer downloads distributions; projects should verify package provenance because published packages are not automatically audited.

A function that yields values lazily and resumes where it left off, letting a program stream large sensor datasets without holding every record in memory at once.

An object used with a with statement that runs setup on entry and guaranteed cleanup on exit, which is how sockets, files, and database sessions are reliably closed.

A Python library providing an MQTT client class with connect, publish, subscribe, and callback hooks, commonly used to bridge Python services to an MQTT broker.

A single-threaded scheduler that runs coroutines cooperatively, letting one Python process manage many concurrent device connections without a thread per connection.

A labeled two-dimensional table structure in Python used to clean, resample, and aggregate sensor data before storage or analysis in integration pipelines.

A maintained list of everyone affected by or influencing the system, recording their interests, influence, and engagement approach so requirements work targets the right people.

A structured conversation with a stakeholder to surface needs, constraints, and tacit expectations that no existing document records, producing candidate requirements for validation.

Concrete, testable conditions a delivered feature must satisfy to be accepted, written before development so that testers and developers agree on what done means.

A table linking each requirement to its source, design elements, code, and verifying tests, making it possible to show coverage and assess the impact of a proposed change.

A formally agreed and frozen set of requirements for a release, against which later changes are proposed, reviewed, and approved through change control.

Releasing a change first to a small subset of devices or sites, watching health metrics, then widening exposure gradually so faults affect few users before a full release.

A dedicated URL or message topic that reports whether a service and its dependencies are working, used by load balancers and monitoring to route or alert correctly.

A numeric boundary on a monitored metric that, when crossed for a defined duration, triggers a notification, balancing early warning against alert fatigue from noise.

A documented, rehearsed procedure for returning a system to its last known good state, including what data migration must be reversed and who authorizes the decision.