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."
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).
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.

Glossary

Need a Term Defined?