bundle.core¶

Submodules¶

Attributes¶

platform_info

Exceptions¶

ProcessError

Custom exception for process execution errors.

Classes¶

`Data`	Base data model class, providing utilities for serialization and deserialization
`Entity`	An extension of the Data model that represents an entity with enhanced introspection
`Platform`	Represents the current platform's system and Python environment information.
`Process`	Asynchronously executes shell commands and captures their output.
`ProcessStream`	Executes a command asynchronously and streams output line by line.
`ProcessResult`	Data class to store the result of a process execution.
`Downloader`	Handles asynchronous downloading of files from a specified URL.
`DownloaderTQDM`	Extends Downloader with TQDM progress bar for visual feedback during download.
`Socket`	Simplified asynchronous ZeroMQ socket class with dynamic configuration,

Package Contents¶

class bundle.core.Data(/, **data: Any)[source]¶

Bases: pydantic.BaseModel

Base data model class, providing utilities for serialization and deserialization from/to JSON, along with JSON Schema generation.

model_config¶: Default model configuration settings.

model_config¶: Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].

classmethod from_dict(data: dict) → D[source]¶

Async:

Create an instance of the model from a dictionary.

Parameters:: data (dict) – The data dictionary from which to create the model instance.
Returns:: An instance of the model.
Raises:: Exception – If the model instantiation fails.

async as_dict() → dict[source]¶

Create an instance of the model from a JSON file.

Parameters:: json_path (Path) – The path to the JSON file.
Returns:: An instance of the model.
Raises:: Exception – If the model instantiation from the JSON file fails.

classmethod from_json(json_source: str | pathlib.Path) → D[source]¶

Async:

Create an instance of the model from either a JSON string or a path to a JSON file.

Parameters:

json_source (str | Path) – The JSON string or path to the JSON file.

Returns:

An instance of the model.

Raises:

RuntimeError – If the json_source is neither a string nor a Path instance.
Exception – If the model instantiation from the JSON source fails.

async as_json() → str[source]¶

Serialize the model instance to a JSON string.

Returns:: A JSON string representation of the model instance.
Raises:: Exception – If serialization to JSON fails.

async dump_json(path: pathlib.Path) → None[source]¶

Write the JSON representation of the model instance to a file.

Parameters:: path (Path) – The file path where the JSON data will be saved.
Raises:: Exception – If writing to the file fails.

classmethod as_jsonschema(mode: pydantic.json_schema.JsonSchemaMode = 'serialization') → dict[source]¶

Async:

Generate the JSON Schema of the model.

Parameters:: mode (json_schema.JsonSchemaMode) – The mode of the JSON Schema, defaults to “serialization”.
Returns:: A dictionary representing the JSON Schema of the model.
Raises:: Exception – If generating the JSON Schema fails.

classmethod as_jsonschema_str(mode: pydantic.json_schema.JsonSchemaMode = 'serialization') → str[source]¶

Async:

Serialize the JSON Schema of the model to a JSON string.

Parameters:: mode (json_schema.JsonSchemaMode) – The mode of the JSON Schema, defaults to “serialization”.
Returns:: A JSON string representation of the model’s JSON Schema.
Raises:: Exception – If serializing the JSON Schema to a string fails.

async dump_jsonschema(path: pathlib.Path, mode: pydantic.json_schema.JsonSchemaMode = 'serialization') → None[source]¶

Write the JSON Schema of the model to a file.

Parameters:

path (Path) – The file path where the JSON Schema will be saved.
mode (json_schema.JsonSchemaMode) – The mode of the JSON Schema, defaults to “serialization”.

Raises:

Exception – If writing the JSON Schema to the file fails.

class bundle.core.Entity(/, **data: Any)[source]¶

Bases: bundle.core.Data

An extension of the Data model that represents an entity with enhanced introspection and optional persistence capabilities. It tracks the entity’s creation time and can automatically save its state upon destruction if configured to do so.

name¶

The name of the entity, with a default value of “Default”.

Type:: str

born_time¶

The timestamp of entity instantiation, in nanoseconds.

Type:: int

Properties:: class_name (str): The name of the entity’s class. age (int): The age of the entity in nanoseconds, calculated from its born_time.

version: str¶

name: str = None¶

identifier: Identifier = None¶

born_time: int = None¶

property class_name: str¶: Returns the class name of the instance.

property age: int¶: Calculates and returns the age of the entity in nanoseconds since instantiation.

class bundle.core.Platform(/, **data: Any)[source]¶

Bases: bundle.core.entity.Entity

Represents the current platform’s system and Python environment information.

system¶

The operating system name (lowercase).

Type:: str

node¶

The network name (hostname) of the machine.

Type:: str

release¶

The system’s release version.

Type:: str

version¶

The system’s version.

Type:: str

arch¶

The machine architecture.

Type:: str

processor¶

The processor identifier.

Type:: str

python_version¶

The Python version in use.

Type:: str

python_implementation¶

The Python implementation (e.g., CPython).

Type:: str

python_executable¶

The path to the Python executable.

Type:: str

python_compiler¶

The Python compiler used.

Type:: str

cwd¶

The current working directory.

Type:: Path

home¶

The user’s home directory.

Type:: Path

env¶

The environment variables.

Type:: dict

is_64bits¶

Whether the Python interpreter is 64-bit.

Type:: bool

pid¶

The current process ID.

Type:: int

uid¶

The current user ID (if available).

Type:: int | None

gid¶

The current group ID (if available).

Type:: int | None

darwin¶

Darwin-specific platform information (if on macOS).

Type:: Darwin | None

system: str = None¶

node: str = None¶

release: str = None¶

version: str = None¶

arch: str = None¶

processor: str = None¶

python_version: str = None¶

python_implementation: str = None¶

python_executable: str = None¶

python_compiler: str = None¶

cwd: pathlib.Path = None¶

home: pathlib.Path = None¶

env: dict = None¶

is_64bits: bool = None¶

pid: int = None¶

uid: None | int = None¶

gid: None | int = None¶

darwin: None | Darwin = None¶

property platform_string: str¶

Return a string summarizing the platform and Python environment.

Returns:: A string in the format “{system}-{machine}-{python_implementation}{python_version}”.
Return type:: str

property is_windows: bool¶

Check if the current system is Windows.

Returns:: True if Windows, False otherwise.
Return type:: bool

property is_linux: bool¶

Check if the current system is Linux.

Returns:: True if Linux, False otherwise.
Return type:: bool

property is_darwin: bool¶

Check if the current system is Darwin (macOS).

Returns:: True if Darwin, False otherwise.
Return type:: bool

bundle.core.platform_info¶

class bundle.core.Process(/, **data: Any)[source]¶

Bases: bundle.core.entity.Entity

Asynchronously executes shell commands and captures their output.

class bundle.core.ProcessStream(/, **data: Any)[source]¶

Bases: Process

Executes a command asynchronously and streams output line by line.

async callback_stdout(line: str)[source]¶: Default stdout handler: writes directly to sys.stdout.

async callback_stderr(line: str)[source]¶: Default stderr handler: writes directly to sys.stderr.

class bundle.core.ProcessResult(/, **data: Any)[source]¶

Bases: bundle.core.data.Data

Data class to store the result of a process execution.

command: str¶

returncode: int¶

stdout: str¶

stderr: str¶

exception bundle.core.ProcessError(process: Process | ProcessStream, result: ProcessResult)[source]¶

Bases: Exception

Custom exception for process execution errors.

result¶

class bundle.core.Downloader(/, **data: Any)[source]¶

Bases: bundle.core.entity.Entity

Handles asynchronous downloading of files from a specified URL.

url¶

The URL to download the file from.

Type:: str

destination¶

The local file path to save the downloaded file. If None, data is stored in memory.

Type:: Path | None

chunk_size¶

The size of each chunk to download at a time.

Type:: int

buffer¶

A buffer to temporarily store the file’s content if no destination is specified.

Type:: bytearray

start(byte_size: int): Placeholder for initialization logic before downloading starts.

update(byte_count: int): Placeholder for update logic as chunks of data are downloaded.

end()[source]¶: Placeholder for cleanup logic after the download completes.

download() → bool[source]¶: Asynchronously downloads a file from url to destination or to buffer.

url: str¶

destination: pathlib.Path | None = None¶

chunk_size: int = 4096¶

name: str = None¶

property buffer: bytearray¶: Expose the in-memory buffer for downstream consumers.

property error_message: str¶

start(byte_size: int)[source]¶: Initializes the download process. Placeholder for subclasses to implement.

update(byte_count: int)[source]¶: Updates the download progress. Placeholder for subclasses to implement.

end()[source]¶: Finalizes the download process. Placeholder for subclasses to implement.

async download() → bool[source]¶

Asynchronously downloads a file from the specified URL.

The file is either saved to the given destination path or stored in an in-memory buffer. Utilizes aiohttp for asynchronous HTTP requests and aiofiles for async file I/O operations.

Returns:: True if the download was successful, False otherwise.
Return type:: bool

class bundle.core.DownloaderTQDM(/, **data: Any)[source]¶

Bases: Downloader

Extends Downloader with TQDM progress bar for visual feedback during download.

Overrides the start, update, and end methods of Downloader to integrate a TQDM progress bar that updates with each downloaded chunk.

start(byte_size: int)[source]¶: Initializes the TQDM progress bar.

update(byte_count: int)[source]¶: Updates the TQDM progress bar with the number of bytes downloaded.

end()[source]¶: Closes the TQDM progress bar.

class bundle.core.Socket(/, **data: Any)[source]¶

Bases: bundle.core.entity.Entity, Generic[T_Socket]

Simplified asynchronous ZeroMQ socket class with dynamic configuration, chainable methods, and support for proxying between sockets.

type: zmq.SocketType = None¶

mode: SocketMode = None¶

endpoint: str = None¶

is_closed: bool = False¶

check_positive(socket_type)[source]¶

instantiate_internal_socket() → Socket[source]¶

property socket: zmq.asyncio.Socket¶

bind(endpoint: str) → T_Socket[source]¶

Bind the socket to an endpoint.

Parameters:: endpoint (str) – The endpoint to bind to (e.g., ‘tcp://*:5555’).
Returns:: The current instance for method chaining.
Return type:: T_Socket

connect(endpoint: str) → T_Socket[source]¶

Connect the socket to an endpoint.

Parameters:: endpoint (str) – The endpoint to connect to (e.g., ‘tcp://127.0.0.1:5555’).
Returns:: The current instance for method chaining.
Return type:: T_Socket

subscribe(topic: bytes = b'') → T_Socket[source]¶

Subscribe to a topic (for SUB and DISH sockets).

Parameters:: topic – The topic to subscribe to. Defaults to b”” (all topics).
Returns:: The current instance for method chaining.
Return type:: T_Socket
Raises:: ValueError – If the socket type does not support subscription.

async close() → None[source]¶: Close the ZeroMQ socket and clean up resources.

async send(data: bytes) → None[source]¶

Send data through the ZeroMQ socket.

Parameters:: data (bytes) – The data to send.
Raises:: RuntimeError – If the socket is closed.

async recv() → bytes[source]¶

Receive data from the ZeroMQ socket.

Returns:: The received data.
Return type:: bytes
Raises:: RuntimeError – If the socket is closed.

async send_multipart(data: list[bytes]) → None[source]¶

Send a multipart message through the ZeroMQ socket.

Parameters:: data (List[bytes]) – The list of message frames to send.
Raises:: RuntimeError – If the socket is closed.

async recv_multipart() → list[bytes][source]¶

Receive a multipart message from the ZeroMQ socket.

Returns:: The list of message frames received.
Return type:: List[bytes]
Raises:: RuntimeError – If the socket is closed.

static proxy(frontend: Socket, backend: Socket) → None[source]¶

Async:

Asynchronous implementation of a ZeroMQ proxy.

Parameters:

frontend (Socket) – The frontend socket.
backend (Socket) – The backend socket.

Raises:

ValueError – If either socket is closed.

classmethod pair() → T_Socket[source]¶

ZMQ PAIR

This test module demonstrates the PAIR pattern in ZeroMQ, which is designed for simple, synchronous, bidirectional communication between exactly two peers. The PAIR pattern is suitable for connecting two sockets in a one-to-one fashion, such as in inter-thread or inter-process communication.

Key Concepts: - Socket A and Socket B: Two sockets connected in a PAIR, allowing for bidirectional communication. - Bidirectional Communication: Both sockets can send and receive messages to and from each other. - Exclusive Pairing: PAIR sockets are intended for exclusive connections between two peers. Connecting more than two peers can result in unpredictable behavior.

Diagram of the PAIR Pattern:

+—————-+ +—————-+ | | | | | Socket A | <—–> | Socket B | | (PAIR socket) | | (PAIR socket) | | | | | +——-+——–+ +——–+——-+

^

|

classmethod pub() → T_Socket[source]¶

Create a PUB socket for publishing messages using ZeroMQ.

The PUB socket type in ZeroMQ is designed for broadcasting messages to multiple subscribers. It is ideal for scenarios where a single publisher needs to disseminate information to many subscribers efficiently.

Key Features: - Broadcast Capability: Send messages to all connected SUB sockets. - Asynchronous Delivery: Publishers do not wait for subscribers to receive messages. - Topic Filtering: Subscribers can filter messages based on topics.

Use Cases: - Real-time data feeds (e.g., stock prices, news updates). - Event notification systems. - Logging services where multiple consumers need to receive log messages.

Diagram of the PUB/SUB Pattern:

+————+ +————+ | | | | | PUB Socket | ———> | SUB Socket | | | | | +————+ +————+

^

|

classmethod sub() → T_Socket[source]¶

Create a SUB socket for subscribing to messages using ZeroMQ.

The SUB (Subscriber) socket type in ZeroMQ is designed to receive messages from one or more PUB (Publisher) sockets. It is ideal for scenarios where a client needs to receive broadcasted information filtered by specific topics.

Key Features: - Subscription Filtering: Receive only messages that match specified topics. - Multiple Subscriptions: A single SUB socket can subscribe to multiple topics. - Asynchronous Reception: Subscribers receive messages as they are published.

Use Cases: - Real-time dashboards receiving live data feeds. - Notification systems where clients subscribe to certain event types. - Logging systems where different components subscribe to specific log levels or sources.

Diagram of the PUB/SUB Pattern:

+————+ +————+ | | | | | PUB Socket | ———> | SUB Socket | | | | | +————+ +————+

^

|

classmethod req() → T_Socket[source]¶

Create a REQ socket for sending requests using ZeroMQ.

The REQ (Request) socket type in ZeroMQ is used to send requests to and receive replies from REP (Reply) sockets. It enforces a strict send-receive pattern, making it suitable for synchronous client-server communication.

Key Features: - Synchronous Communication: Each request must be followed by a reply. - Load Balancing: When connected to multiple REP sockets, requests are load-balanced. - Simplified Protocol: Ensures a clear request-response cycle.

Use Cases: - RPC (Remote Procedure Call) systems. - Synchronous APIs where clients wait for server responses. - Task distribution systems requiring request-reply semantics.

Diagram of the REQ/REP Pattern:

+————+ +————+ | | | | | REQ Socket | ———> | REP Socket | | | | | +————+ +————+

^

|

classmethod rep() → T_Socket[source]¶

Create a REP socket for replying to requests using ZeroMQ.

The REP (Reply) socket type in ZeroMQ is designed to receive requests from REQ (Request) sockets and send back corresponding replies. It enforces a strict receive-send pattern, making it suitable for synchronous server-side communication.

Key Features: - Synchronous Communication: Each received request must be followed by a reply. - Load Balancing: When connected to multiple REQ sockets, replies are load-balanced. - Simplified Protocol: Ensures a clear receive-reply cycle.

Use Cases: - RPC (Remote Procedure Call) servers. - Synchronous APIs where servers respond to client requests. - Task processing systems requiring reply semantics.

Diagram of the REQ/REP Pattern:

+————+ +————+ | | | | | REQ Socket | ———> | REP Socket | | | | | +————+ +————+

^

|

classmethod dealer() → T_Socket[source]¶

Create a DEALER socket for asynchronous request routing using ZeroMQ.

The DEALER socket type in ZeroMQ is an advanced socket type that extends the REQ socket. It allows for asynchronous request sending and receiving, enabling more flexible communication patterns without the strict send-receive cycle.

Key Features: - Asynchronous Communication: Send multiple requests without waiting for replies. - Load Balancing: Efficiently distribute requests across multiple REP or ROUTER sockets. - Advanced Routing: Supports complex routing patterns when combined with ROUTER sockets.

Use Cases: - Building scalable, asynchronous client-server architectures. - Implementing load-balanced task distribution systems. - Complex messaging patterns requiring non-blocking communication.

Diagram of the DEALER/ROUTER Pattern:

+—————+ +—————+ | | | | | DEALER Socket | <——–> | ROUTER Socket | | | | | +—————+ +—————+

classmethod router() → T_Socket[source]¶

Create a ROUTER socket for advanced routing using ZeroMQ.

The ROUTER socket type in ZeroMQ is an advanced socket that complements the DEALER socket. It provides greater control over message routing by handling explicit addressing of peers, making it suitable for complex messaging architectures.

Key Features: - Explicit Addressing: Directly address and communicate with specific DEALER or REQ sockets. - Asynchronous Handling: Manage multiple incoming and outgoing messages concurrently. - Flexible Routing: Implement custom routing logic based on message content or metadata.

Use Cases: - Building centralized brokers or routers in messaging systems. - Implementing custom load-balancing and routing strategies. - Complex server architectures requiring precise control over client communication.

Diagram of the ROUTER/DEALER Pattern:

+—————+ +————–+ | | | | | ROUTER Socket | <——–> | DEALER Socket| | | | | +—————+ +————–+

classmethod pull() → T_Socket[source]¶

Create a PULL socket for receiving messages using ZeroMQ.

The PULL socket type in ZeroMQ is designed to receive messages in a pipeline pattern. It works in conjunction with PUSH sockets to distribute tasks among workers, enabling efficient and load-balanced message processing.

Key Features: - Pipeline Pattern: Receive messages in a one-way flow from PUSH sockets. - Load Balancing: Distribute incoming messages evenly across multiple PULL sockets. - Asynchronous Reception: Continuously receive messages without blocking.

Use Cases: - Task distribution systems where tasks are pushed to workers. - Parallel processing pipelines handling large volumes of data. - Event processing systems requiring efficient message ingestion.

Diagram of the PUSH/PULL Pattern:

+————+ +————+ | | | | | PUSH Socket| ———> | PULL Socket| | | | | +————+ +————+

classmethod push() → T_Socket[source]¶

Create a PUSH socket for sending messages using ZeroMQ.

The PUSH socket type in ZeroMQ is designed to send messages in a pipeline pattern. It works in conjunction with PULL sockets to distribute tasks among workers, enabling efficient and load-balanced message processing.

Key Features: - Pipeline Pattern: Send messages in a one-way flow to PULL sockets. - Load Balancing: Distribute outgoing messages evenly across multiple PULL sockets. - Asynchronous Sending: Continuously send messages without waiting for acknowledgments.

Use Cases: - Task distribution systems where tasks are pushed to workers. - Parallel processing pipelines handling large volumes of data. - Event generation systems requiring efficient message dissemination.

Diagram of the PUSH/PULL Pattern:

+————+ +————+ | | | | | PUSH Socket| ———> | PULL Socket| | | | | +————+ +————+

classmethod xpub() → T_Socket[source]¶

Create an XPUB socket for extended publishing using ZeroMQ.

The XPUB socket type in ZeroMQ extends the PUB socket by providing additional capabilities for managing subscriptions. It allows publishers to receive subscription messages from subscribers, enabling dynamic control over the publishing process.

Key Features: - Subscription Feedback: Receive messages when subscribers subscribe or unsubscribe. - Dynamic Subscription Management: Adjust publishing behavior based on active subscriptions. - Enhanced Control: Implement custom logic based on subscriber activity.

Use Cases: - Building responsive publishing systems that adapt to subscriber behavior. - Implementing access control based on subscriber subscriptions. - Monitoring subscriber activity for analytics or logging purposes.

Diagram of the XPUB/SUB Pattern:

+————-+ +————+ | | | | | XPUB Socket| <—–> | SUB Socket | | | | | +————-+ +————+

classmethod xsub() → T_Socket[source]¶

Create an XSUB socket for extended subscribing using ZeroMQ.

The XSUB socket type in ZeroMQ extends the SUB socket by providing additional capabilities for managing subscriptions. It allows subscribers to send subscription messages to publishers, enabling dynamic control over the subscription process.

Key Features: - Dynamic Subscriptions: Send and manage subscription and unsubscription messages. - Bidirectional Control: Control subscription behavior based on application logic. - Enhanced Flexibility: Implement custom subscription management strategies.

Use Cases: - Building responsive subscribing systems that can adjust subscriptions in real-time. - Implementing complex subscription management logic based on application needs. - Enhancing monitoring and analytics by tracking subscription changes.

Diagram of the XSUB/PUB Pattern:

+————-+ +————+ | | | | | XSUB Socket| <—–> | PUB Socket | | | | | +————-+ +————+

classmethod stream() → T_Socket[source]¶

Create a STREAM socket for handling raw TCP connections using ZeroMQ.

The STREAM socket type in ZeroMQ is designed for handling raw TCP connections, providing low-level access to the underlying transport layer. It is suitable for scenarios requiring fine-grained control over network communication.

Key Features: - Raw TCP Access: Handle individual TCP connections directly. - Bidirectional Communication: Send and receive data streams without message framing. - Flexible Protocol Implementation: Implement custom communication protocols on top of TCP.

Use Cases: - Building custom network protocols requiring specific control over data transmission. - Implementing transparent proxies or gateways that need direct access to TCP streams. - Developing applications that require persistent, low-level TCP connections.

Diagram of the STREAM Pattern:

+————–+ +————–+ | | | | | STREAM Socket| <———–> | STREAM Socket| | | | | +————–+ +————–+

classmethod server() → T_Socket[source]¶

Create a SERVER socket for handling server-side communication using ZeroMQ.

The SERVER socket type in ZeroMQ is designed to manage server-side communication, handling incoming connections and facilitating message exchanges with CLIENT sockets. It provides mechanisms for scalable and efficient server implementations.

Key Features: - Connection Management: Handle multiple incoming CLIENT connections. - Scalable Communication: Efficiently manage high volumes of client messages. - Flexible Messaging Patterns: Support various communication patterns such as request-reply or publish-subscribe.

Use Cases: - Building scalable server applications that handle numerous client connections. - Implementing RPC servers with efficient client request handling. - Developing real-time data distribution systems with multiple subscribers.

Diagram of the SERVER/CLIENT Pattern:

+————–+ +————–+ | | | | | SERVER Socket| <———> | CLIENT Socket| | | | | +————–+ +————–+

classmethod client() → T_Socket[source]¶

Create a CLIENT socket for handling client-side communication using ZeroMQ.

The CLIENT socket type in ZeroMQ is designed to manage client-side communication, initiating connections to SERVER sockets and facilitating message exchanges. It provides mechanisms for scalable and efficient client implementations.

Key Features: - Connection Initiation: Establish connections to SERVER sockets. - Asynchronous Communication: Send and receive messages without blocking. - Flexible Messaging Patterns: Support various communication patterns such as request-reply or publish-subscribe.

Use Cases: - Building scalable client applications that communicate with centralized servers. - Implementing RPC clients with efficient request handling. - Developing real-time data consumption systems with dynamic subscriptions.

Diagram of the SERVER/CLIENT Pattern:

+————–+ +————–+ | | | | | SERVER Socket| <———> | CLIENT Socket| | | | | +————–+ +————–+

classmethod radio() → T_Socket[source]¶

Create a RADIO socket for radio communication using ZeroMQ.

The RADIO socket type in ZeroMQ is designed for high-throughput, multicast-style communication, enabling one-to-many or many-to-many message distribution. It is suitable for scenarios requiring efficient dissemination of messages to multiple peers.

Key Features: - Multicast Communication: Send messages to multiple RADIO sockets simultaneously. - High Throughput: Designed for efficient handling of large volumes of messages. - Scalable Distribution: Easily scale message distribution to numerous peers.

Use Cases: - Live streaming applications broadcasting media to multiple clients. - Multiplayer gaming servers distributing game state updates to players. - Real-time data distribution systems requiring rapid dissemination of information.

Diagram of the RADIO Pattern:

+————-+ +————-+ +————-+ | | | | | | | RADIO Socket| —-> | RADIO Socket| —-> | RADIO Socket| | | | | | | +————-+ +————-+ +————-+

classmethod dish() → T_Socket[source]¶

Create a DISH socket for dish communication using ZeroMQ.

The DISH socket type in ZeroMQ is designed for efficient group communication, enabling one-to-many or many-to-many message distribution with a focus on low latency and high scalability. It is suitable for scenarios requiring robust and efficient multicast messaging.

Key Features: - Group Communication: Facilitate communication within a group of peers. - Low Latency: Optimize message delivery for minimal delay. - High Scalability: Efficiently manage communication with a large number of peers.

Use Cases: - Distributed sensor networks requiring synchronized data collection. - Collaborative applications where multiple users need to receive the same updates. - Real-time monitoring systems broadcasting alerts to multiple clients.

Diagram of the DISH Pattern:

+————-+ +————-+ +————-+ | | | | | | | DISH Socket | —-> | DISH Socket | —-> | DISH Socket | | | | | | | +————-+ +————-+ +————-+

classmethod gather() → T_Socket[source]¶

Create a GATHER socket for collecting messages using ZeroMQ.

The GATHER socket type in ZeroMQ is designed to collect messages from multiple sources, aggregating them into a single stream. It is ideal for scenarios where a central aggregator needs to receive data from various producers.

Key Features: - Message Aggregation: Collect messages from multiple GATHERER sockets. - Centralized Collection: Consolidate data from various sources into a single point. - Scalable Reception: Efficiently handle high volumes of incoming messages.

Use Cases: - Data aggregation systems collecting logs or metrics from multiple services. - Centralized monitoring dashboards receiving data from various sensors. - Batch processing systems where data from multiple producers is consolidated for processing.

Diagram of the GATHERER/GATHER Pattern:

+—————–+ +—————+ | | | | | GATHERER Socket | —> | GATHER Socket | | | | | +—————–+ +—————+

classmethod scatter() → T_Socket[source]¶

Create a SCATTER socket for distributing messages using ZeroMQ.

The SCATTER socket type in ZeroMQ is designed to distribute messages to multiple destinations, effectively scattering data to various consumers. It is suitable for scenarios where a central distributor needs to send data to multiple receivers.

Key Features: - Message Distribution: Send messages to multiple SCATTER sockets efficiently. - Centralized Distribution: Distribute data from a single source to multiple destinations. - Scalable Sending: Handle high volumes of outgoing messages with ease.

Use Cases: - Content distribution networks broadcasting data to multiple nodes. - Real-time notification systems sending alerts to various subscribers. - Distributed caching systems where updates need to be propagated to multiple caches.

Diagram of the SCATTER Pattern:

+—————–+ +—————-+ | | | | | SCATTER Socket | —> | SCATTER Socket | | | | | +—————–+ +—————-+

classmethod dgram() → T_Socket[source]¶

Create a DGRAM socket for datagram communication using ZeroMQ.

The DGRAM socket type in ZeroMQ is designed for connectionless, message-oriented communication using datagrams. It is ideal for scenarios requiring lightweight, non-persistent message transmission.

Key Features: - Connectionless Communication: Send and receive messages without establishing a persistent connection. - Message-Oriented: Handle discrete messages rather than continuous streams. - Low Overhead: Minimal resource usage suitable for high-frequency messaging.

Use Cases: - Real-time gaming where quick, stateless message exchanges are required. - IoT devices transmitting sensor data intermittently. - Lightweight notification systems where persistence is not necessary.

Diagram of the DGRAM Pattern:

+————–+ +————-+ | | | | | DGRAM Socket | <—–> | DGRAM Socket| | | | | +————–+ +————-+

classmethod peer() → T_Socket[source]¶

Create a PEER socket for peer-to-peer communication using ZeroMQ.

The PEER socket type in ZeroMQ is designed for direct peer-to-peer communication, enabling symmetric message exchanges between peers without a centralized broker. It is suitable for scenarios requiring decentralized and flexible communication.

Key Features: - Symmetric Communication: Both peers can send and receive messages equally. - Decentralized Architecture: No need for a central server or broker. - Flexible Topology: Supports various communication topologies including mesh and star.

Use Cases: - Decentralized chat applications enabling direct communication between users. - Distributed systems where nodes need to communicate without a central coordinator. - Collaborative tools allowing real-time interaction between multiple participants.

Diagram of the PEER Pattern:

+————–+ +————-+ | | | | | PEER Socket | <———-> | PEER Socket | | | | | +————–+ +————-+

classmethod channel() → T_Socket[source]¶

Create a CHANNEL socket for channel-based communication using ZeroMQ.

The CHANNEL socket type in ZeroMQ is designed for establishing dedicated communication channels between peers. It provides a streamlined interface for managing bi-directional message flows within a specific communication channel.

Key Features: - Dedicated Channels: Establish specific communication channels between peers. - Bi-directional Messaging: Facilitate two-way message exchanges within channels. - Channel Management: Easily manage multiple channels within the same application.

Use Cases: - Private messaging systems where each conversation is a separate channel. - Modular applications requiring isolated communication channels between components. - Collaborative environments where distinct channels are needed for different topics or groups.

Diagram of the CHANNEL Pattern:

+—————-+ +—————+ | | | | | CHANNEL Socket | <———-> | CHANNEL Socket| | | | | +—————-+ +—————+