Zen Protocol Documentation
WebsiteTelegramBlogForum
  • Zen Protocol Docs
  • Apps
    • Headless Full Node
      • Full Node NPM Package
      • Build from Source
      • CLI
      • API
        • Wallet
        • Contracts
        • General
        • Blockchain
        • AddressDB
      • Deploy
        • Systemd
        • Shell script
        • Docker
      • Technical Model
      • AddressDB
    • Wallet
      • Desktop Wallet
        • Installers
      • Web Wallet
        • Run Locally
      • Wallet User Guide
        • Connect a Wallet
          • Create a Wallet
          • Import a Wallet
          • Watch Mode
        • My Wallet
          • Navigation Bar
          • Portfolio
          • Receive
          • Send / Execute
          • Transaction History
        • Contracts
          • Active Contracts
          • Execute a Contract
            • Message Body Field
          • Extend a Contract
          • Activate a Contract
        • Voting
          • Common Goods Pool
            • Generating a Ballot ID
          • Governance
        • Signer
        • Settings
          • Account Settings
          • Node Connectivity
      • Deprecated Desktop Wallet
        • Executable Installers
        • Wallet Structure
          • Video Tutorials
    • Explorer
    • Zen.js
      • Payment Processing
    • Oracle
      • Oracle GUI
      • Oracle Service
      • Oracle's API
      • Deploy
        • Systemd
        • Docker
      • How the Oracle contract works
      • How to create an Attestation token
    • Dex
      • Dex User Guide
        • Traded Pairs
        • Search Pairs
        • Order Book
        • Operations
        • My Wallet
        • Settings
      • How DEX contract works
    • Fixed Payout
      • Fixed Payout Generator User Guide
        • Issue
        • Redeem
        • Cancel
        • Verify
        • Settings
      • How the FP Contract works
      • How are the asset named?
  • Smart Contracts
  • Contract Structure
  • Contract Cost
  • Contract Activation
  • Contract Examples
  • Smart Contracts SDK
  • Contracts Language ZF*
  • Named Token Tutorial
  • Consensus
  • Common Goods Pool
  • Block Validation
  • Transaction Validation
  • Serialization
  • Use Cases
    • Create Unsigned Transaction
    • Secure Sign Transaction
    • Cold Storage using Full Node
  • Troubleshooting
    • Responsible Disclosure
    • Bug Bounty
    • Known Bugs
  • For Miners
    • Pools
    • GPU Mining
    • GPU Bounties
  • Check Crowdsale Contribution
  • Alpha call option
Powered by GitBook
On this page
  • Actor Model
  • Service Bus and Publisher - NetMQ
  1. Apps
  2. Headless Full Node

Technical Model

Actor Model

The Actor model is a programming paradigm that enables concurrent and distributed systems to be designed and implemented more easily. In the Actor model, computation is modeled as a collection of independent actors that communicate with each other by sending messages.

An actor is a unit of computation that can receive messages, perform computations, and send messages to other actors. Each actor has its own internal state, which can be accessed only by the actor itself. Actors can create new actors, and each actor has a unique address or identifier that other actors can use to send messages to it.

In the Actor model, message passing is the primary means of comm

unication between actors. When an actor receives a message, it can perform some computation and then send messages to other actors, including the original sender. Actors can also send messages to themselves, which can be used for scheduling future work or for implementing timeouts.

One of the main benefits of the Actor model is that it simplifies the design of concurrent and distributed systems. Because each actor has its own internal state, there is no need for locks or other synchronization mechanisms to coordinate access to shared resources. This can make it easier to reason about the behavior of a system and to avoid race conditions and deadlocks.

Another advantage of the Actor model is that it can be used to build highly scalable systems. Because actors are independent and communicate only by message passing, it is easy to add or remove actors as needed to handle changes in the load on the system.

Service Bus and Publisher - NetMQ

NetMQ is a software library that provides tools for enabling efficient and reliable communication between applications over computer networks. It offers various messaging patterns, such as request-reply, publish-subscribe, and push-pull, among others. With NetMQ, developers can implement messaging functionality in their applications, allowing them to communicate with other applications or services seamlessly.

A service bus is an architectural pattern that provides a central messaging system for different applications or services to communicate with each other. The service bus acts as an intermediary, routing messages between applications and providing useful features like message queuing, transformation, and routing. This allows for loosely coupled communication between applications and services, making it easier to maintain and scale distributed systems.

In the context of messaging patterns like publish-subscribe, a publisher is an application or component that sends messages to a messaging system or service bus. The publisher is responsible for publishing messages to a specific topic or channel, which subscribers can then consume. This allows for broadcasting messages to multiple recipients in a scalable and efficient way.

In summary, NetMQ, service bus, and publisher are all tools and patterns that help facilitate communication between applications or services in a distributed system. They enable developers to build scalable and reliable systems that can handle complex messaging scenarios.

PreviousDockerNextAddressDB

Last updated 2 years ago