Glossary

Definitions for the networking, real-time protocol, cryptography and authentication terms used across the sgcWebSockets, sgcSign and sgcBiometrics documentation. Each entry links to the relevant RFC or specification where applicable.

WebSocket: A bidirectional, full-duplex messaging protocol over a single TCP connection. Standardised in RFC 6455. Used by sgcWebSocketClient / sgcWebSocketServer as the transport for MQTT, AMQP, STOMP, WAMP and custom subprotocols.
RFC 6455: The IETF specification "The WebSocket Protocol" — defines the handshake, framing, control frames and closing handshake. See datatracker.ietf.org/doc/html/rfc6455.
HTTP/2: The second major version of HTTP, designed to reduce latency through stream multiplexing, header compression and server push. Standardised in RFC 9113.
RFC 9113: "HTTP/2" — the consolidated specification that supersedes RFC 7540. Defines frame types, stream multiplexing, flow control, header compression via HPACK and the upgrade negotiation rules.
HPACK: Header Compression for HTTP/2, defined in RFC 7541. Uses a static table, a dynamic table and Huffman coding to reduce header overhead on each HTTP/2 stream.
RFC 7541: "HPACK: Header Compression for HTTP/2." Specifies the binary encoding rules, indexed-header references and the dynamic-table size negotiation used by HTTP/2 endpoints.
ALPN: Application-Layer Protocol Negotiation, a TLS extension defined in RFC 7301. Lets a client advertise application protocols (e.g. "h2", "http/1.1") during the TLS handshake so the server can pick one.
RFC 7301: "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension." Defines the ALPN extension used to negotiate HTTP/2 over TLS.
HTTP/3: The third major version of HTTP, running over QUIC instead of TCP. Standardised in RFC 9114. Removes head-of-line blocking and integrates TLS 1.3 into the transport.
QUIC: A UDP-based, multiplexed and secure transport protocol defined in RFC 9000. Carries HTTP/3 and offers connection migration, 0-RTT and integrated TLS 1.3.
MQTT: Message Queuing Telemetry Transport — a lightweight publish-subscribe protocol for constrained devices. Two major versions are in production use: 3.1.1 and 5.0.
MQTT 3.1.1: OASIS standard published in 2014. Defines the original CONNECT/PUBLISH/SUBSCRIBE flow with three QoS levels, retained messages and Last Will and Testament. See OASIS MQTT 3.1.1.
MQTT 5.0: OASIS standard published in 2019. Adds user properties, reason codes, topic aliases, shared subscriptions, session expiry and enhanced authentication on top of 3.1.1. See OASIS MQTT 5.0.
QoS (Quality of Service): MQTT message delivery guarantee. QoS 0 — at most once (fire-and-forget). QoS 1 — at least once (acknowledged with PUBACK). QoS 2 — exactly once (four-step handshake: PUBLISH, PUBREC, PUBREL, PUBCOMP).
Retained message: An MQTT message stored by the broker and delivered to every new subscriber whose topic filter matches. One retained message per topic; publishing a zero-length payload with the retained flag clears it.
Last Will and Testament (LWT): An MQTT message registered at CONNECT time that the broker publishes on the client's behalf if the connection is closed abnormally. Used for presence detection and disconnect notification.
Broker: The central server in a publish-subscribe protocol (MQTT, AMQP, STOMP). Receives messages from publishers, matches them against subscriptions and forwards to subscribers.
Topic: A hierarchical, slash-delimited string that identifies the channel a message is published to. Subscribers filter on topic patterns.
Wildcard topic: An MQTT topic filter containing + (single-level wildcard) or # (multi-level wildcard, must be the final segment). Example: sensors/+/temperature matches one level; sensors/# matches every descendant.
AMQP: Advanced Message Queuing Protocol — a binary, wire-level messaging protocol with two incompatible major versions in production use: 0-9-1 (RabbitMQ legacy) and 1.0 (OASIS / ISO/IEC 19464).
AMQP 0-9-1: The wire protocol popularised by RabbitMQ. Defines the exchange-queue-binding model with direct, fanout, topic and headers exchange types.
AMQP 1.0: The OASIS / ISO standard (ISO/IEC 19464). Defines a peer-to-peer link-based transfer model used by Azure Service Bus, ActiveMQ Artemis and SwiftMQ.
STOMP: Simple (or Streaming) Text Oriented Messaging Protocol — a text-based frame protocol designed to be implementable in any language. Versions 1.0, 1.1, 1.2. Used by ActiveMQ and RabbitMQ.
WAMP: Web Application Messaging Protocol — combines RPC and Pub/Sub patterns on a single connection, typically over WebSocket. Defined at wamp-proto.org.
WebRTC: Web Real-Time Communications — a browser-grade peer-to-peer media and data API. Uses ICE to traverse NAT, DTLS-SRTP for media encryption and SCTP-over-DTLS for data channels.
SDP: Session Description Protocol, defined in RFC 8866. Used inside WebRTC offer/answer exchanges to describe media streams, codecs and ICE candidates.
ICE: Interactive Connectivity Establishment — the NAT-traversal framework that gathers candidate address pairs (host, server-reflexive, relayed) and connectivity-checks each pair. Defined in RFC 8445.
STUN: Session Traversal Utilities for NAT — a protocol for discovering a host's public-facing IP and port mapping. Specified in RFC 8489.
RFC 8489: "Session Traversal Utilities for NAT (STUN)." The current revision; obsoletes RFC 5389.
TURN: Traversal Using Relays around NAT — a STUN extension that relays media through a server when peer-to-peer paths fail. Specified in RFC 8656.
RFC 8656: "Traversal Using Relays around NAT (TURN): Relay Extensions to STUN." The current revision; obsoletes RFC 5766.
RTCPeerConnection: The W3C WebRTC API surface representing a connection between two peers. Holds the local and remote SDP, ICE state and media tracks. sgcWebSockets ships a Delphi component (TsgcWebRTCPeerConnection) that mirrors the browser API.
DTLS: Datagram Transport Layer Security — TLS adapted for UDP-style unreliable transports. Used by WebRTC for SRTP key exchange. Current version: DTLS 1.3.
RFC 9147: "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3." Latest DTLS specification.
TLS 1.2: Transport Layer Security 1.2, defined in RFC 5246. Widely deployed; still required by HTTP/2 endpoints that haven't migrated to TLS 1.3.
TLS 1.3: Transport Layer Security 1.3, the current major TLS revision. Removes legacy ciphersuites, requires forward secrecy and supports 0-RTT resumption. Specified in RFC 8446.
RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3."
mTLS (mutual TLS): A TLS handshake in which both peers present X.509 certificates, so the server authenticates the client as well as the client authenticating the server. Used for zero-trust service-to-service authentication and certificate-pinned API access.
JWT: JSON Web Token — a compact, URL-safe token format carrying signed claims. Defined in RFC 7519. Used for stateless authentication.
RFC 7519: "JSON Web Token (JWT)." Specifies the claim set, header format and serialisation rules.
JWS: JSON Web Signature, defined in RFC 7515. The signing mechanism used by JWTs (header.payload.signature).
JWE: JSON Web Encryption, defined in RFC 7516. The encryption mechanism used to produce encrypted JWTs.
OAuth 2.0: An authorisation framework that lets a third-party application obtain limited access to a user's resources without sharing their credentials. Defined in RFC 6749.
RFC 6749: "The OAuth 2.0 Authorization Framework." Defines four core grant types, the access token / refresh token model and the authorization endpoint / token endpoint contract.
PKCE: Proof Key for Code Exchange — an OAuth 2.0 extension that mitigates the authorization-code interception attack for public clients. Defined in RFC 7636. Now required for all OAuth 2.1 clients.
RFC 7636: "Proof Key for Code Exchange by OAuth Public Clients."
OAuth Authorization Code grant: The browser-redirect OAuth flow used by web and native applications. The client receives a code from the authorization endpoint and exchanges it (server-side, with PKCE) for tokens at the token endpoint.
OAuth Client Credentials grant: The machine-to-machine OAuth flow where the client authenticates with its own credentials (no user) to obtain an access token for backend service calls.
OAuth Device Authorization grant: The OAuth flow for input-constrained devices (TVs, CLI tools). Defined in RFC 8628. The device polls the token endpoint while the user authenticates on a secondary device.
OAuth Resource Owner Password grant: Legacy OAuth 2.0 flow where the client collects the user's username and password directly and sends them to the token endpoint. Deprecated in OAuth 2.1 in favour of authorization-code + PKCE.
OAuth Refresh Token: A long-lived token returned alongside an access token. Used at the token endpoint to obtain a new access token without re-prompting the user.
DPoP: Demonstration of Proof-of-Possession — an OAuth 2.0 mechanism that binds access tokens to a client-held key pair, mitigating bearer-token theft. Defined in RFC 9449.
OpenID Connect: An identity layer built on top of OAuth 2.0 that returns a signed ID Token (JWT) alongside the access token, with a standardised UserInfo endpoint and discovery document.
WebAuthn: The W3C Web Authentication API for passwordless authentication using public-key credentials backed by platform authenticators or roaming security keys.
FIDO2: The FIDO Alliance umbrella for WebAuthn + the CTAP (Client-To-Authenticator Protocol) used between the browser and an external authenticator.
U2F: Universal 2nd Factor — the original FIDO protocol for second-factor security keys. Superseded by FIDO2 / CTAP2 but still supported by legacy YubiKeys.
Server-Sent Events (SSE): A simple, text-based, one-way streaming protocol over HTTP using Content-Type: text/event-stream. Part of the WHATWG HTML standard. Used for live notifications and AI streaming responses.
Socket.IO: A higher-level library on top of WebSocket (with HTTP long-polling fallback) that provides rooms, namespaces, automatic reconnection and binary support. Distinct wire protocol from raw WebSocket.
SignalR: Microsoft's real-time library originally for ASP.NET. Uses WebSocket, Server-Sent Events or long polling as transport, with built-in hub-based RPC and automatic transport negotiation.
SignalR Core: The redesigned SignalR for ASP.NET Core. Uses a different on-the-wire protocol than classic SignalR — clients must target the matching server version.
Pusher: A hosted real-time messaging service with channel and presence semantics. sgcWebSockets ships a typed Pusher client component.
MCP (Model Context Protocol): An open protocol introduced by Anthropic for exposing tools, resources and prompts from a server to an LLM-powered host application. sgcWebSockets ships both an MCP client (TsgcWSAPIClient_MCP) and server (TsgcWSAPIServer_MCP).
LLM (Large Language Model): A neural network trained on large text corpora to predict the next token, used for generation, summarisation, classification and conversation. Examples include OpenAI GPT, Anthropic Claude and Google Gemini. sgcWebSockets provides typed clients such as TsgcAIOpenAI and TsgcAIAnthropic.
Token: The atomic unit of text an LLM reads and generates — typically a sub-word fragment rather than a whole word. Models price usage and bound their context window by token count; roughly 1 token is about 4 characters of English.
Context window: The maximum number of tokens an LLM can process in a single request, covering both the prompt and the generated response. Exceeding it forces truncation or summarisation; window sizes range from a few thousand to over a million tokens.
System prompt: A high-priority instruction supplied to an LLM that sets its role, tone, constraints and available tools before any user message. It steers behaviour across the whole conversation and is distinct from the per-turn user prompt.
Inference: The runtime phase in which a trained model produces output for a given input, as opposed to training. For LLMs, inference generates the response one token at a time and is the operation billed per token by hosted APIs.
Streaming responses: Delivering an LLM's output incrementally, token by token, as it is generated rather than waiting for the full completion. Most LLM APIs stream over Server-Sent Events, letting applications render partial text in real time.
Function calling (tool use): An LLM capability where the model, given JSON schemas describing available tools, returns a structured request to call one with arguments. The host executes the tool and feeds the result back, enabling the model to query APIs, databases or compute. The Model Context Protocol standardises how those tools are exposed.
AI agent: An LLM-driven system that pursues a goal over multiple steps by reasoning, calling tools and acting on the results in a loop, rather than producing a single reply. Agents typically combine function calling, memory and a planning prompt.
RAG (Retrieval-Augmented Generation): A technique that retrieves relevant documents from an external store (often via vector search) and injects them into the LLM prompt as context, so the model answers from up-to-date, domain-specific data instead of relying solely on its training.
Embeddings: Dense numeric vectors that encode the semantic meaning of text (or other data) so that similar items map to nearby points in vector space. They power semantic search and RAG; sgcWebSockets exposes embedding endpoints such as TsgcAIOpenAIEmbeddings.
Vector database: A database optimised for storing embeddings and running approximate nearest-neighbour searches over them. Used as the retrieval backend for RAG and semantic search. Examples include Pinecone, Qdrant, Weaviate and pgvector.
Semantic search: Searching by meaning rather than keyword match, by embedding the query and the corpus as vectors and ranking results by vector similarity. Returns conceptually related results even when no exact terms overlap.
Hallucination: An LLM output that is fluent and plausible but factually wrong or fabricated, arising because the model predicts likely text rather than retrieving verified facts. Grounding techniques such as RAG and tool use reduce its frequency.
Prompt engineering: The practice of designing the instructions, examples and structure given to an LLM to elicit accurate, well-formatted output. Common patterns include few-shot examples, chain-of-thought prompting and explicit output schemas.
Cloud HSM: A Hardware Security Module rented as a cloud service (e.g. AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM). Keys never leave the HSM; signing operations are remote.
eIDAS: Electronic Identification, Authentication and Trust Services — the EU regulation (910/2014, updated by 2024/1183) defining Qualified Electronic Signatures (QES), Qualified Trust Service Providers and the legal equivalence of QES to handwritten signatures.
Code signing: Applying a digital signature to an executable, library or installer so that operating systems and users can verify origin and integrity before running it. Windows uses Authenticode; macOS uses codesign; Java uses jarsigner.
ClickOnce signing: Microsoft's deployment-manifest signing for ClickOnce .NET applications. Signs the application manifest and the deployment manifest with an Authenticode certificate.
NuGet signing: Adding a PKCS#7 author or repository signature to a .nupkg file so consumers can verify the package's origin. Required for nuget.org listing of signed packages.
VSIX signing: Signing a Visual Studio Extension (.vsix) package using OPC (Open Packaging Conventions) signatures so the Visual Studio gallery can verify provenance.
Windows Hello: Microsoft's biometric / PIN sign-in feature in Windows 10 and 11. Built on top of the Windows Biometric Framework and the platform credential provider.
Windows Biometric Framework: The Windows kernel-mode + user-mode framework that abstracts biometric sensors behind a common API. sgcBiometrics builds directly on WBF (Winbio*).
IOCP: I/O Completion Ports — the Windows scalable async-I/O primitive. The sgcWebSockets Enterprise edition ships an Indy-style IOCP server that scales to tens of thousands of concurrent WebSocket connections.
EPOLL: The Linux scalable I/O event notification facility. The sgcWebSockets Enterprise edition ships an EPOLL Linux64 server matching the IOCP design.
HTTP.SYS: The Windows kernel-mode HTTP listener (used by IIS and Windows Communication Foundation). The Enterprise HTTP.SYS server registers URL prefixes with the kernel for high throughput.
OpenSSL: The widely deployed open-source TLS/cryptography library (libssl + libcrypto). sgcWebSockets supports both OpenSSL 1.0.2/1.1.1 and the current OpenSSL 3.x.
SChannel: Secure Channel — the Microsoft Windows TLS/SSL provider integrated into the OS. sgcWebSockets supports SChannel as an alternative to OpenSSL on Windows; no DLLs to redistribute.
gRPC: A modern, contract-first RPC framework using Protocol Buffers over HTTP/2 streams. Supports unary, server-streaming, client-streaming and bidirectional-streaming calls.
Server Push: An HTTP/2 mechanism letting the server send resources (PUSH_PROMISE) to the client before the client requests them. Now disabled by default in Chromium-based browsers; sgcWebSockets still supports it for backend-to-backend use.
Multiplexing: Carrying multiple independent streams over a single transport connection. HTTP/2 multiplexes streams over one TCP connection; HTTP/3 multiplexes streams over one QUIC connection without head-of-line blocking at the transport layer.
Header compression: Reducing the bytes-on-wire cost of repeated HTTP headers. HTTP/2 uses HPACK; HTTP/3 uses QPACK. Both rely on a per-connection dynamic table of recently-used header fields.
Flow control: The mechanism that prevents a sender from overwhelming a receiver. HTTP/2 has per-stream and per-connection flow-control windows driven by WINDOW_UPDATE frames.
Keep-alive: Periodic probe frames sent to keep a connection alive through intermediaries and detect dead peers. WebSocket uses PING/PONG control frames; MQTT uses PINGREQ/PINGRESP at the configured KeepAlive interval.
CoAP: Constrained Application Protocol — a RESTful, UDP-based protocol for constrained devices, with optional DTLS. Specified in RFC 7252.
RCON: Source Remote Console — the Valve / Source-engine remote administration protocol used by Counter-Strike, Garry's Mod and similar game servers. sgcWebSockets ships a typed RCON client.
REST API: An HTTP interface following Representational State Transfer conventions, where resources are addressed by URL and acted on with HTTP verbs (GET, POST, PUT, DELETE), typically exchanging JSON. Most exchange and cloud APIs expose a REST endpoint for requests alongside a WebSocket stream for real-time updates.
API key / secret: A credential pair issued by a service: the public key identifies the caller and is sent with each request, while the private secret is never transmitted and is used locally to compute a request signature (typically HMAC). Compromise of the secret allows request forgery, so it is stored, not shared.
HMAC request signing: Authenticating an API request by computing a keyed hash (HMAC) over a canonical string of its method, path, body and timestamp using the API secret, then sending the result as a signature header. The server recomputes it to verify integrity and authenticity without the secret ever crossing the wire. HMAC is defined in RFC 2104.
Order book: The live list of outstanding buy (bid) and sell (ask) orders for a trading pair on an exchange, sorted by price. Exchange WebSocket feeds publish order-book snapshots plus incremental depth updates that clients apply to maintain local state.
Ticker stream: A real-time exchange feed of summary market statistics for a symbol — last price, best bid/ask, 24-hour volume and price change — pushed over WebSocket as values change. Lighter-weight than a full order-book feed.
Listen key: A short-lived token (used by Binance and similar exchanges) that authorises a private user-data WebSocket stream of account, balance and order events. The client obtains it from a REST endpoint and must periodically refresh it to keep the stream open.

Glossary

Need a Term Defined?