Pith. sign in

REVIEW 4 major objections 5 minor 17 references

TrustMesh: A Blockchain-Enabled Trusted Distributed Computing Framework for Open Heterogeneous IoT Environments

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read TrustMesh claims that a permissioned blockchain can run non-deterministic scheduling algorithms without losing Byzantine fault tolerance, by splitting scheduling into designation, generation, and PBFT-confirmed validation.

desk verdict A plausible, genuinely implemented framework for combining non-deterministic scheduling with PBFT-style validation, but the designation phase that carries the safety claim lacks a mechanism for global resource-state consistency. read the letter →

arxiv 2411.13039 v3 pith:NMWDNCQ2 submitted 2024-11-20 cs.DC

Murtaza Rangwala , Rajkumar Buyya This is my paper · ORCID
classification cs.DC
keywords TrustMeshInternetofThingspermissionedblockchainPracticalByzantineFaultTolerancenon-deterministicschedulingedgecomputingdistributedconsensuscoldchainmonitoring
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper proposes TrustMesh, a three-layer framework for untrusted, heterogeneous IoT computing in which scheduling decisions are recorded on a permissioned blockchain. Its central claim is that non-deterministic scheduling algorithms, including heuristics, genetic algorithms, and machine learning, can be used without giving up Byzantine fault tolerance, a combination usually taken to be impossible because blockchain consensus requires deterministic proposals. TrustMesh achieves this with a multi-phase protocol: a deterministic function designates one node to generate the schedule, that node runs any algorithm it likes, and then PBFT consensus validates the result against a configurable rule set before it is committed. If true, this lets open IoT networks keep an auditable, tamper-evident ledger while choosing schedules by flexible, smart algorithms. The evaluation on a 21-node cold-chain testbed reports fault detection under 150 ms and roughly constant framework overhead as nodes scale from 4 to 16.

What carries the argument

The multi-phase PBFT commit protocol is the load-bearing mechanism. Its three phases are the Request and Designation phase ($\phi_1$), where the deterministic function $f(N,R) = \max_{n \in N}(w_c c_n + w_m m_n)$ picks the designated node $n_d$; the Generation phase ($\phi_2$), where $n_d$ runs any scheduling algorithm $A: S \to P$; and the Confirmation phase ($\phi_3$), where PBFT consensus validates the proposal $p$ against a rule set $V$ and commits it under the request identifier $id_r$. The protocol separates who may propose, what is acceptable, and how the proposal is computed, which is the step that lets nondeterminism coexist with Byzantine fault tolerance.

What would settle it

Run the framework with two honest nodes given deliberately different resource snapshots for the same schedule request and check whether they designate different proposers; if they do, the same request can produce two Active schedules, violating Agreement and Validity. A simpler check is to inject a divergent cache update and observe whether conflicting proposals pass validation.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central discovery is that the apparent conflict between Byzantine fault tolerance and non-deterministic scheduling is an artifact of demanding both from the same step. TrustMesh splits scheduling into three phases. In Phase 1 every node applies the same deterministic resource-weighting function $f(N,R)$ to agree on a designated node $n_d$. In Phase 2 that node runs any scheduling algorithm $A$ and produces a proposal $p$. In Phase 3 the network runs PBFT over $p$, but instead of requiring $p$ to match some precomputed deterministic output, it checks $p$ against a set of validation rules $V$ and the identity of the proposer. Since designation and validation are deterministic and consensus only confirms a proposal satisfying publicly checkable predicates, the ledger records schedules produced by arbitrary algorithms without sacrificing agreement or validity.

Load-bearing premise

The whole construction leans on every honest node seeing the same resource state $R$ when the designation function runs; the paper assumes atomic operations give that consistent view, but does not specify how asynchronously refreshed resource data is kept globally consistent.

Editorial extensions

If this is right

  • Scheduling policies become pluggable: an operator can swap heuristics, genetic algorithms, or machine-learning policies without changing the consensus layer or losing Byzantine fault tolerance.
  • The blockchain becomes an audit trail for scheduling: every accepted or rejected schedule is committed, so violations of vendor, geographic, resource, or security constraints can be checked afterward.
  • With $n \geq 3f+1$, up to one-third of compute nodes can behave maliciously; the 16-node experiment with five malicious nodes detected both tested attack scenarios with 100% accuracy and zero false positives.
  • Fault recovery is bounded: after a malicious proposal is rejected, a new schedule is generated in about 5 seconds, and detection latency stays below 150 ms.
  • Framework overhead is governed by consensus rather than application complexity, so increasing compute nodes from 4 to 16 raised round-trip time by only about 8.3%.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The safety guarantee depends on every honest node computing the same $f(N,R)$; because resource state is updated asynchronously in this design, a production deployment would need a synchronizing mechanism or deterministic snapshot for the proof to hold.
  • The same designate-generate-confirm pattern could be applied to other non-deterministic decisions in permissioned blockchains, such as model updates, placement choices, or dynamic pricing, whenever a deterministic designation rule and public validation predicates can be written.
  • A natural test is to compare TrustMesh against a standard PBFT chain running the same scheduling algorithm in deterministic form; the difference in round-trip time would quantify the cost of admitting nondeterminism.
  • If resource-state consistency cannot be guaranteed, the protocol's guarantees degrade, because honest nodes might disagree on who is allowed to propose even before PBFT runs.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes TrustMesh, a three-layer permissioned-blockchain framework for trusted distributed computing in heterogeneous IoT environments. Its central contribution is a multi-phase PBFT-based protocol (designation, generation, confirmation) that is claimed to allow non-deterministic scheduling algorithms, such as heuristics or machine learning, while preserving Byzantine fault tolerance. The protocol uses a deterministic designation function f(N,R) to select a designated node that generates a schedule, which is then validated and confirmed via PBFT. The paper presents informal safety and liveness proofs, an implementation using Hyperledger Sawtooth, CouchDB, Redis, and Kubernetes, and an experimental evaluation on a 21-node testbed with a cold-chain monitoring workflow, reporting resource utilization, scalability, and Byzantine fault tolerance results.

Significance. If the central claim holds, the paper addresses a real limitation of BFT-based blockchains: the usual requirement of deterministic transaction validation rules. TrustMesh's approach of separating non-deterministic schedule generation from deterministic validation is conceptually promising and could enable ML-based and heuristic schedulers in permissioned BFT networks. The paper provides direct experimental measurements, a public code repository, and falsifiable performance claims (e.g., fault detection under 150 ms, consistent framework overhead). However, the significance is contingent on the multi-phase protocol actually providing a Byzantine-safe designation mechanism, which the current manuscript does not establish. The 'formal verification' is an informal prose proof that glosses over the most load-bearing step, namely consistent agreement on resource state R.

major comments (4)
  1. [Section IV-A, Eq. (2)] Safety Property 1 claims that the designation function f(N,R) always produces the same designated node nd, but the manuscript provides no mechanism by which all honest nodes obtain a consistent view of R. Sections III-B1 and V-C describe R as maintained in a sharded Redis cache with asynchronous batched updates, and CouchDB uses multi-master replication with eventual consistency; neither provides a globally consistent snapshot. If nodes evaluate f against different local views of R, they can disagree on nd, which breaks validity and agreement before PBFT is even invoked. The proof's reference to 'atomic operations for consistent views' is not a mechanism. The paper must specify how a Byzantine-safe consistent R is obtained (e.g., by including resource-state updates in PBFT-ordered transactions) or the deterministic designation claim is unsupported.
  2. [Section III-B2, phases ϕ1–ϕ3] The protocol does not specify which actor executes phase ϕ1 or how the resulting nd is agreed upon and enforced. If every node independently computes f(N,R) and both an honest node and a Byzantine node consider themselves designated, the system can have competing proposals, defeating the single-proposer structure that PBFT confirmation relies on. If instead a single proposer computes nd and records it in a transaction, a Byzantine proposer can choose an arbitrary nd. The paper needs a concrete mechanism for securely determining and committing nd before the generation phase, or the claim that non-deterministic scheduling can be supported while preserving Byzantine fault tolerance remains unsupported.
  3. [Section IV, Liveness Property 1 and C] The liveness proof assumes synchrony and 'reliable event delivery via blockchain subscription', but these assumptions are not stated precisely or reconciled with the eventual-consistency properties of the Redis/CouchDB data layer described in Sections V-C and III-B1. The paper states in Section V-C that the combination 'supports the eventual consistency model appropriate for IoT environments', which is in tension with the synchrony and atomicity assumptions used in the safety proof. The authors should either provide a clean asynchronous or partially-synchronous model with explicit guarantees for the cache and persistent store, or weaken the liveness claims accordingly. The current informal proof, which lists bullet points rather than establishing invariant preservation, is not sufficient as a 'formal verification'.
  4. [Section VI-D, Table III] The Byzantine fault tolerance evaluation considers only two synthetic attack scenarios on a 16-node network with 5 Byzantine nodes, and reports 100% detection with zero false positives. These scenarios are narrow: they test unauthorized schedule proposals by a non-designated node and request interference by a designated node, but they do not test equivocation, collusion among multiple Byzantine nodes, or attacks that exploit the inconsistent-R ambiguity described above. The '100% accuracy' is to be expected because the test was set up to reject these specific attempts. The paper should compare against a baseline (e.g., standard PBFT or a prior framework), test more diverse Byzantine behaviors, and discuss why these scenarios are representative enough to support the general claim of Byzantine fault tolerance.
minor comments (5)
  1. [Section III-B2, Eq. (11)] In the load equation, the terms cpuused/cputotal and memused/memtotal are used but cpuused and memused are not formally defined; the resource state R in Eq. (2) uses cn and mn, so the notation should be unified for consistency.
  2. [Section III-C] The Perception Layer's 'zero-process baseline' is described as a design principle, but the manuscript does not explain how IoT nodes can initiate requests or receive responses when no processes are running; the Transaction Initiator and Response Manager are described as libraries, yet the operational flow is unclear.
  3. [Section VI-C and VIII-C] The scalability analysis in Section VI-C claims 'efficient consensus operation at scale' based on a 4-to-16-node range, while Section VIII-C correctly cautions that PBFT has O(n^2) complexity and larger deployments would show quadratic behavior. The main text should present the scaling claim with the same caveat to avoid overstatement.
  4. [Section IV-C] The fault tolerance analysis states the protocol 'inherits Byzantine fault tolerance from PBFT', but it should clarify which properties are inherited exactly, since the schedule proposal p is not a deterministic transaction and the validation rules V in Eq. (5) are evaluated by nodes on a non-deterministic output; the inheritance argument is not automatic.
  5. [Table I] The qualitative comparison marks TrustMesh as fully supporting all listed features, including 'Complete Decentralized Control', yet Section III-A admits control nodes introduce some centralization. The table's checkmarks should be reconciled with the text's caveats or the criteria should be defined more precisely.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: TrustMesh's guarantees are inherited from external PBFT and its experimental numbers are direct measurements; the designation-consistency gap is a correctness limitation, not a circular reduction.

full rationale

TrustMesh does not fit parameters to data and then relabel them as predictions. The multi-phase protocol is a design; its safety and liveness arguments (Section IV) appeal to PBFT's external agreement and total-order guarantees (Castro-Liskov [11]) and to explicitly stated assumptions (synchrony, atomic consistency, idr-based state addressing). Eq. (2) defines designation, Eq. (5) defines validity, and Eqs. (6)-(8) define schedule feasibility; none of these is fitted to the measured RRT/FO or BFT latencies in Section VI, which are direct empirical results. The only self-citation with author overlap is Ref. [3] (FogBus, Buyya co-author), used as related-work contrast rather than as the basis of the novelty or correctness claims, so it is not load-bearing. The paper's own limitations (Section VIII-C: PBFT O(n^2) at scale; Section VIII-B: only two attack scenarios tested) and the unspecified mechanism for a globally consistent resource snapshot R in Safety Property 1 are real correctness risks, but they are not cases where a claimed result is equivalent by construction to its inputs. Hence no circular step can be exhibited, and the circularity score is 0.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The central claim rests on standard distributed systems assumptions (PBFT correctness, blockchain atomicity, synchrony for liveness) plus one paper-specific assumption about consistent resource-state views that the protocol does not actually implement. There are no fitted parameters in the BFT argument; the hand-chosen scheduling parameters affect load balancing but not the fault-tolerance claim.

free parameters (2)
  • wc and wm (designation weights) = unspecified
    Used in Eq. (2) to rank nodes for designation; the paper never gives values or a calibration procedure, so any implementation must choose them by hand. Not central to the BFT claim.
  • LCDWRR load weights and smoothing constant = 0.5, 0.5, 0.1
    Hard-coded in Eqs. (11) and (12); the selection probability and load balancing behavior depend on these hand-chosen constants, and no sensitivity analysis is provided.
assumptions (5)
  • domain assumption PBFT provides Byzantine fault tolerance for n >= 3f+1 with up to f faulty nodes.
    Invoked in Section IV-C to claim the protocol inherits BFT from PBFT; the paper relies on Castro-Liskov's correctness rather than re-proving it.
  • domain assumption Hyperledger Sawtooth provides total order, atomic smart contract execution, and tamper-evident state.
    Used throughout Sections III and V to argue that transactions, schedule confirmations, and resource signatures are recorded consistently on the ledger.
  • ad hoc to paper All nodes share a consistent view of resource state R when computing the designation function f.
    Safety Property 1 in Section IV-A requires f to be deterministic, but the protocol only says atomic operations provide consistent views; no concrete consensus or synchronization mechanism for R is specified. This is an assumption introduced to make the proof go through.
  • domain assumption Liveness holds under synchrony with bounded designation time and reliable event delivery.
    Liveness Property 1 in Section IV-B relies on synchrony, eventual resource consistency, and reliable blockchain subscription, none of which are guaranteed by the protocol itself.
  • domain assumption The set of validation rules V is deterministic and shared by all nodes evaluating schedule p.
    Equation (5) in Section III-B2 makes acceptance depend on all V_i(p) being true; if nodes have different V, agreement on a schedule can fail. The paper states V is customizable but does not specify how it is synchronized.

how reviews work

0 comments
Cite this review

Pith. "Pith review of TrustMesh: A Blockchain-Enabled Trusted Distributed Computing Framework for Open Heterogeneous IoT Environments." pith.science (2026). https://pith.science/paper/NMWDNCQ2

@misc{pith2026241113039,
  author       = {Pith},
  title        = {Pith review of: TrustMesh: A Blockchain-Enabled Trusted Distributed Computing Framework for Open Heterogeneous IoT Environments},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NMWDNCQ2}},
  note         = {Machine review of arXiv:2411.13039}
}
read the original abstract

The rapid evolution of Internet of Things (IoT) environments has created an urgent need for secure and trustworthy distributed computing systems, particularly when dealing with heterogeneous devices and applications where centralized trust cannot be assumed. This paper proposes TrustMesh, a novel blockchain-enabled framework that addresses these challenges through a unique three-layer architecture combining permissioned blockchain technology with a novel multi-phase Practical Byzantine Fault Tolerance (PBFT) consensus protocol. The key innovation lies in TrustMesh's ability to support non-deterministic scheduling algorithms while maintaining Byzantine fault tolerance - features traditionally considered mutually exclusive in blockchain systems. The framework supports a sophisticated resource management approach that enables flexible scheduling decisions while preserving the security guarantees of blockchain-based verification. Our experimental evaluation using a real-world cold chain monitoring scenario demonstrates that TrustMesh successfully maintains Byzantine fault tolerance with fault detection latencies under 150 milliseconds, while maintaining consistent framework overhead across varying computational workloads even with network scaling. These results establish TrustMesh's effectiveness in balancing security, performance, and flexibility requirements in trustless IoT environments, advancing the state-of-the-art in secure distributed computing frameworks.

Figures

Figures reproduced from arXiv: 2411.13039 by the authors.

Figure 1
Figure 1. TrustMesh High Level Architecture restart failed application instances, and remove applications or their images from the network. When an administrator initiates an action, the client checks the locally hosted registry within the Network Management Layer and pushes the application image if not already present. Subsequently, a smart contract is invoked in the Computation Layer. This smart contract stores the action d… view at source ↗
Figure 2
Figure 2. Multi-Phase Commit Protocol The generation phase as defined in (3) permits the des￾ignated node to implement any scheduling algorithm A : S → P that maps from the system state space S to the space of permissible schedules P. In our implementation, we use a Least-Connected Dynamic Weighted Round Robin (LCDWRR) approach. To formally describe this algorithm, we first define its operational model. Let G = (V, E) be the … view at source ↗
Figure 3
Figure 3. Cold-Chain Monitoring DAG B. System Resource Utilization We conducted comprehensive resource utilization analysis across all three architectural layers during the execution of the cold-chain monitoring workflow. The CPU and RAM utilization patterns, illustrated in [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Resource Usage [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Performance Comparison by Testbed Configuration [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

17 extracted references · 15 canonical work pages

  1. [1]

    Toward Trust in Internet of Things Ecosystems: Design Principles for Blockchain-Based IoT Applications,

    J. Lockl, V . Schlatt, A. Schweizer, N. Urbach, and N. Harth, “Toward Trust in Internet of Things Ecosystems: Design Principles for Blockchain-Based IoT Applications,” IEEE Transactions on Engineering Management, vol. 67, no. 4, pp. 1256–1270, Nov. 2020, conference Name: IEEE Transactions on Engineering Management. [Online]. Available: https://ieeexplore....

    work page arXiv 2020

  2. [2]

    Enabling Workload Engineering in Edge, Fog, and Cloud Computing through OpenStack-based Middleware,

    G. Merlino, R. Dautov, S. Distefano, and D. Bruneo, “Enabling Workload Engineering in Edge, Fog, and Cloud Computing through OpenStack-based Middleware,” ACM Trans. Internet Technol. , vol. 19, no. 2, pp. 28:1–28:22, Apr. 2019. [Online]. Available: https: //dl.acm.org/doi/10.1145/3309705

    work page doi:10.1145/3309705 2019

  3. [3]

    FogBus: A Blockchain- based Lightweight Framework for Edge and Fog Computing,

    S. Tuli, R. Mahmud, S. Tuli, and R. Buyya, “FogBus: A Blockchain- based Lightweight Framework for Edge and Fog Computing,” Journal of Systems and Software , vol. 154, pp. 22–36, Aug. 2019. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S0164121219300822

    work page 2019

  4. [4]

    CoopEdge: A Decentralized Blockchain-based Platform for Cooperative Edge Computing,

    L. Yuan, Q. He, S. Tan, B. Li, J. Yu, F. Chen, H. Jin, and Y . Yang, “CoopEdge: A Decentralized Blockchain-based Platform for Cooperative Edge Computing,” in Proceedings of the Web Conference 2021, ser. WWW ’21. New York, NY , USA: Association for Computing Machinery, Jun. 2021, pp. 2245–2257. [Online]. Available: https://dl.acm.org/doi/10.1145/3442381.3449994

    arXiv 2021

  5. [5]

    Groupchain: Towards a Scalable Public Blockchain in Fog Computing of IoT Services Computing,

    K. Lei, M. Du, J. Huang, and T. Jin, “Groupchain: Towards a Scalable Public Blockchain in Fog Computing of IoT Services Computing,” IEEE Transactions on Services Computing , vol. 13, no. 2, pp. 252–262, Mar. 2020, conference Name: IEEE Transactions on Services Computing. [Online]. Available: https://ieeexplore.ieee.org/ abstract/document/9061111

    work page arXiv 2020

  6. [6]

    BlockEdge: Blockchain- Edge Framework for Industrial IoT Networks,

    T. Kumar, E. Harjula, M. Ejaz, A. Manzoor, P. Porambage, I. Ahmad, M. Liyanage, A. Braeken, and M. Ylianttila, “BlockEdge: Blockchain- Edge Framework for Industrial IoT Networks,” IEEE Access , vol. 8, pp. 154 166–154 185, 2020, conference Name: IEEE Access. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/9171246

    work page arXiv 2020

  7. [7]

    FogChain: A Fog Computing Architecture Integrating Blockchain and Internet of Things for Personal Health Records,

    A. H. Mayer, V . F. Rodrigues, C. A. d. Costa, R. d. R. Righi, A. Roehrs, and R. S. Antunes, “FogChain: A Fog Computing Architecture Integrating Blockchain and Internet of Things for Personal Health Records,” IEEE Access , vol. 9, pp. 122 723– 122 737, 2021, conference Name: IEEE Access. [Online]. Available: https://ieeexplore.ieee.org/abstract/document/9527256

    work page arXiv 2021

  8. [8]

    HIDRA: A Distributed Blockchain-Based Architecture for Fog/Edge Computing Environments,

    C. N ´u˜nez-G´omez, B. Caminero, and C. Carri ´on, “HIDRA: A Distributed Blockchain-Based Architecture for Fog/Edge Computing Environments,” IEEE Access , vol. 9, pp. 75 231–75 251, 2021, conference Name: IEEE Access. [Online]. Available: https://ieeexplore. ieee.org/abstract/document/9437230

    work page arXiv 2021

Show all 17 references
  1. [9]

    Fog Computing: A Platform for Internet of Things and Analytics,

    F. Bonomi, R. Milito, P. Natarajan, and J. Zhu, “Fog Computing: A Platform for Internet of Things and Analytics,” in Big Data and Internet of Things: A Roadmap for Smart Environments, N. Bessis and C. Dobre, Eds. Cham: Springer International Publishing, 2014, pp. 169–186. [Onl...

    2014 doi

  2. [10]

    A Survey of Fog Computing: Concepts, Applications and Issues,

    S. Yi, C. Li, and Q. Li, “A Survey of Fog Computing: Concepts, Applications and Issues,” in Proceedings of the 2015 Workshop on Mobile Big Data, ser. Mobidata ’15. New York, NY , USA: Association for Computing Machinery, Jun. 2015, pp. 37–42. [Online]. Available: https://dl.ac...

    2015

  3. [11]

    Practical Byzantine Fault Tolerance,

    M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” in Practical Byzantine Fault Tolerance , 1999. [Online]. Available: https:// www.usenix.org/conference/osdi-99/practical-byzantine-fault-tolerance

    1999

  4. [12]

    Lightweight Kubernetes Distributions: A Performance Comparison of MicroK8s, k3s, k0s, and Microshift,

    H. Koziolek and N. Eskandani, “Lightweight Kubernetes Distributions: A Performance Comparison of MicroK8s, k3s, k0s, and Microshift,” in Proceedings of the 2023 ACM/SPEC International Conference on Performance Engineering , ser. ICPE ’23. New York, NY , USA: Association for Co...

    2023

  5. [13]

    Performance Evaluation on Blockchain Systems: A Case Study on Ethereum, Fabric, Sawtooth and Fisco-Bcos,

    R. Wang, K. Ye, T. Meng, and C.-Z. Xu, “Performance Evaluation on Blockchain Systems: A Case Study on Ethereum, Fabric, Sawtooth and Fisco-Bcos,” in Services Computing – SCC 2020 , Q. Wang, Y . Xia, S. Seshadri, and L.-J. Zhang, Eds. Cham: Springer International Publishing, 20...

    2020

  6. [14]

    Anderson, J

    C. Anderson, J. Lehnardt, and N. Slater, CouchDB: The Definitive Guide. O’Reilly Media, Jan. 2010, google-Books-ID: PTybAgAAQBAJ

    2010

  7. [15]

    Carlson, Redis in Action

    J. Carlson, Redis in Action . Simon and Schuster, Jun. 2013, google- Books-ID: xjszEAAAQBAJ

    2013

  8. [16]

    Using ZeroMQ Security

    P. Hintjens, “Using ZeroMQ Security.” [Online]. Available: http: //hintjens.com/blog:49

  9. [17]

    How Far Have Edge Clouds Gone? A Spatial- Temporal Analysis of Edge Network Latency In the Wild,

    H. Zhang, S. Huang, M. Xu, D. Guo, X. Wang, V . C. Leung, and W. Wang, “How Far Have Edge Clouds Gone? A Spatial- Temporal Analysis of Edge Network Latency In the Wild,” in 2023 IEEE/ACM 31st International Symposium on Quality of Service (IWQoS), Jun. 2023, pp. 1–10, iSSN: 276...

    2023

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.