pith. sign in

arxiv: 2605.16897 · v1 · pith:W3TQJMP7new · submitted 2026-05-16 · 💻 cs.NI · cs.PL

Escape from Callback Hell! A New Programming Paradigm for Network Simulation

Yuanyi Zhu , Zijian Li , Xin Ai , Zixuan Chen , Sen Liu , Yang Xu This is my paper

Pith reviewed 2026-05-19 19:22 UTC · model grok-4.3

classification 💻 cs.NI cs.PL
keywords network simulationcoroutinediscrete event simulationcallback hellNS-3protocol implementationcode complexity reduction
0
0 comments X

The pith

Coroutine-based discrete event simulation lets developers write network protocols as simple sequential code instead of callback tangles.

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

The paper argues that conventional discrete event simulators rely on callbacks, which prevent natural sequential workflows and create callback hell that inflates development effort and debugging difficulty for network research. It introduces CoDES, a coroutine-based paradigm that integrates with existing simulators to let programmers express network event handling in straightforward sequential flows. When realized in NS-3, the approach is applied to MPI, HPCC, and RIP, delivering measured reductions of up to 62.3 percent in code volume and 82.6 percent in structural complexity. A sympathetic reader would care because simpler simulation code lowers the barrier to testing and evolving network functions without altering the underlying timing or accuracy guarantees. The framework claims to handle correctness, compatibility, and overhead constraints while preserving simulation fidelity.

Core claim

The central claim is that coroutine mechanisms can be fused with discrete event simulation to produce CoDES, a paradigm that naturally simulates network events through sequential workflows rather than callbacks. This directly tackles stack ripping and maintainability problems in simulators such as NS-3. Concrete implementations for Message Passing Interface, High Precision Congestion Control, and Routing Information Protocol demonstrate the reductions in code volume and complexity while simulation accuracy, execution time, and runtime memory stay unchanged.

What carries the argument

The CoDES framework, which replaces callback-driven event handling in discrete event simulators with coroutines to support sequential program structure for network protocols.

If this is right

  • Network simulation code can be written and read as ordinary sequential programs rather than scattered callback functions.
  • Development workload for protocols such as MPI, HPCC, and RIP drops measurably while code readability improves.
  • Existing simulators retain full accuracy, timing behavior, and memory footprint after the coroutine integration.
  • Rapid evaluation and iterative evolution of network functions become more practical because of reduced cognitive load.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same coroutine replacement pattern could be ported to other discrete event simulators beyond NS-3.
  • Sequential simulation code might integrate more easily with contemporary debuggers and static analysis tools.
  • Lower code complexity could shorten the time needed for researchers to prototype and validate new congestion-control or routing ideas.

Load-bearing premise

Coroutines can be integrated into existing discrete event simulators while fully preserving event ordering, timing semantics, and protocol correctness without hidden overheads or compatibility breaks.

What would settle it

Run an identical network protocol simulation under both the original NS-3 callback version and the CoDES version and observe any divergence in packet delivery order, timing, or final state.

Figures

Figures reproduced from arXiv: 2605.16897 by Sen Liu, Xin Ai, Yang Xu, Yuanyi Zhu, Zijian Li, Zixuan Chen.

Figure 1
Figure 1. Figure 1: Data fetch and send example with network function extension. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Real-world and callback-based simulation pseudocode of data fetching and sending under data source extension. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Simulation implementation of update to remote data [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: “Callback Hell” problem in existing network simula [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Debugging stack of handling received packets on the [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Simulation implementation of CoDES-based data fetch [PITH_FULL_IMAGE:figures/full_fig_p005_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Debugging stack of handling received packets on the [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Adapting CoDES to existing callback-based network simulation. [PITH_FULL_IMAGE:figures/full_fig_p008_8.png] view at source ↗
Figure 10
Figure 10. Figure 10: Comparison of nesting depth between callback-based [PITH_FULL_IMAGE:figures/full_fig_p009_10.png] view at source ↗
Figure 9
Figure 9. Figure 9: Comparison of LOC between callback-based and [PITH_FULL_IMAGE:figures/full_fig_p009_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: Absolute and relative simulation time error compared to the actual results in real-world network. [PITH_FULL_IMAGE:figures/full_fig_p010_11.png] view at source ↗
read the original abstract

Network simulation plays a crucial role in both networking research and industry. Existing commonly-used Discrete Event Simulations (DES) are based on callback mechanisms for discrete event (DE). However, due to the inability of callbacks to naturally simulate network events, programs in network simulation cannot be written in a sequential workflow. This leads to inherent complexity and poor maintainability, resulting in stack ripping and callback hell. These problems significantly increase simulation development workloads and introduce substantial cognitive loads associated with programming and debugging. To enable more efficient development of network simulation and facilitate the rapid evaluation and evolution of network functions, we propose a novel development paradigm for network simulation named ``CoDES" (\textbf{Co}routine-based \textbf{DES}). To the best of our knowledge, we are the first to focus on optimizing the network simulation development process rather than performance based on the coroutine mechanism. We implement a new network simulation framework based on CoDES that is capable of naturally simulating network events and effectively address key system challenges related to correctness, functionality, compatibility, and overhead. It enables developers to create sequential workflows for network programs and simplifies the code structure, thus reducing development workloads while enhancing code readability and maintainability. We apply this paradigm to a commonly used network simulator, NS-3 to implement Message Passing Interface (MPI), High Precision Congestion Control (HPCC), and Routing Information Protocol (RIP), achieving up to 62.3\% and 82.6\% reduction in code volume and structure complexity without sacrificing simulation accuracy, extending execution time or increasing runtime memory of simulation.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript proposes CoDES, a coroutine-based discrete event simulation paradigm for network simulators such as NS-3. It replaces callback mechanisms to enable sequential workflows for network events, addressing callback hell and stack ripping. The authors implement the framework for MPI, HPCC, and RIP, claiming reductions of up to 62.3% in code volume and 82.6% in structure complexity while preserving simulation accuracy, execution time, and runtime memory.

Significance. If the central claims on accuracy preservation and overhead neutrality hold under rigorous verification, this work could meaningfully improve developer productivity and code maintainability in network simulation, a domain where callback complexity has long hindered rapid protocol development and debugging.

major comments (2)
  1. Abstract: the claim that coroutine integration 'addresses key system challenges related to correctness' and achieves 'no sacrificing simulation accuracy' is load-bearing for the central contribution, yet the text supplies no description of how the coroutine scheduler enforces strict discrete-event ordering, handles simultaneous events, or maps suspension/resumption onto the original NS-3 scheduler without reordering or hidden delays. Concrete verification (e.g., bit-for-bit outcome comparison on timing-sensitive protocols such as HPCC) is required.
  2. Evaluation section (results for MPI/HPCC/RIP): the reported 62.3% code-volume and 82.6% structure-complexity reductions must be accompanied by the exact measurement definitions and raw data; without these, it is impossible to assess whether the gains are generalizable or result from post-hoc selection of comparison points.
minor comments (2)
  1. Abstract: the phrase 'structure complexity' is used without an explicit metric (e.g., cyclomatic complexity, number of callback registrations, or control-flow graph edges); a brief definition or reference to the measurement method would improve clarity.
  2. Implementation description: consider adding a short paragraph on the specific coroutine library or runtime used and how context-switch costs were quantified to support the 'no increase in runtime memory' claim.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback. The comments highlight important areas for improving clarity on correctness guarantees and evaluation transparency. We address each point below and will incorporate revisions to strengthen the manuscript.

read point-by-point responses

  1. Referee: Abstract: the claim that coroutine integration 'addresses key system challenges related to correctness' and achieves 'no sacrificing simulation accuracy' is load-bearing for the central contribution, yet the text supplies no description of how the coroutine scheduler enforces strict discrete-event ordering, handles simultaneous events, or maps suspension/resumption onto the original NS-3 scheduler without reordering or hidden delays. Concrete verification (e.g., bit-for-bit outcome comparison on timing-sensitive protocols such as HPCC) is required.

    Authors: We agree that additional technical detail is needed to support the correctness claims. In the revised manuscript we will add a new subsection under the CoDES framework description that explains the integration: coroutine yields are mapped directly to NS-3 event rescheduling calls, preserving the original scheduler's priority queue and timestamp ordering; simultaneous events continue to be processed in the same deterministic sequence as the callback version. We will also include side-by-side bit-for-bit outcome tables for the HPCC implementation (and the other protocols) confirming identical packet traces, congestion signals, and final states between the original and CoDES versions. revision: yes

  2. Referee: Evaluation section (results for MPI/HPCC/RIP): the reported 62.3% code-volume and 82.6% structure-complexity reductions must be accompanied by the exact measurement definitions and raw data; without these, it is impossible to assess whether the gains are generalizable or result from post-hoc selection of comparison points.

    Authors: We accept that the current presentation lacks sufficient transparency. We will revise the Evaluation section to state the precise definitions: code volume is counted as non-blank, non-comment lines of C++ source; structure complexity is measured by the number of control-flow decision points (if/else, loops, switch cases). We will add a table (or appendix) containing the raw line counts and decision-point counts for each of the three protocols before and after the CoDES refactoring, together with the specific files and functions that were compared, so readers can reproduce and generalize the reported reductions. revision: yes

Circularity Check

0 steps flagged

No circularity: implementation results from direct code changes and benchmarks

full rationale

The paper describes an implementation of a coroutine-based paradigm (CoDES) applied to NS-3 for protocols including MPI, HPCC, and RIP. It reports measured reductions in code volume (up to 62.3%) and structure complexity (up to 82.6%) along with claims of preserved accuracy, execution time, and memory. No equations, fitted parameters, predictions derived from subsets of data, or self-citations are used to derive these outcomes. The central claims rest on concrete code rewrites and empirical measurements rather than any derivation chain that reduces to its own inputs by construction. The work is therefore self-contained against external benchmarks of code size and simulator runs.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on the unverified assumption that coroutine semantics can be mapped onto discrete network events while preserving all timing and ordering properties of traditional DES; no free parameters or new physical entities are introduced, but the domain assumption about correctness is load-bearing.

axioms (1)
  • domain assumption Coroutine suspension and resumption can faithfully reproduce the event ordering and timing semantics of callback-based discrete event simulation for network protocols.
    Invoked when claiming the framework addresses correctness challenges and achieves no sacrifice in simulation accuracy.
invented entities (1)
  • CoDES framework no independent evidence
    purpose: To provide a coroutine-based implementation layer for sequential network simulation workflows.
    New software artifact introduced to realize the paradigm; no independent falsifiable evidence outside the paper is supplied in the abstract.

pith-pipeline@v0.9.0 · 5821 in / 1499 out tokens · 57535 ms · 2026-05-19T19:22:07.801954+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

47 extracted references · 47 canonical work pages

  1. [1]

    m3: Accu- rate flow-level performance estimation using machine learning,

    C. Li, A. Nasr-Esfahany, K. Zhaoet al., “m3: Accu- rate flow-level performance estimation using machine learning,” inProceedings of the ACM SIGCOMM 2024 Conference, 2024, pp. 813–827

    work page 2024

  2. [2]

    Unison: A parallel- efficient and user-transparent network simulation kernel,

    S. Bai, H. Zheng, C. Tianet al., “Unison: A parallel- efficient and user-transparent network simulation kernel,” inProceedings of the Nineteenth European Conference on Computer Systems, 2024, pp. 115–131

    work page 2024

  3. [3]

    Dons: Fast and affordable discrete event network simulation with automatic paral- lelization,

    K. Gao, L. Chen, D. Liet al., “Dons: Fast and affordable discrete event network simulation with automatic paral- lelization,” inProceedings of the ACM SIGCOMM 2023 Conference, 2023, pp. 167–181

    work page 2023

  4. [4]

    Discrete event simulation system,

    A. Varga, “Discrete event simulation system,” inProc. of the European Simulation Multiconference (ESM’2001), vol. 17, 2001

    work page 2001

  5. [5]

    G. S. Fishman,Discrete-event simulation: modeling, pro- gramming, and analysis. Springer, 2001, vol. 537

    work page 2001

  6. [6]

    Net- work simulations with the ns-3 simulator,

    T. R. Henderson, M. Lacage, G. F. Rileyet al., “Net- work simulations with the ns-3 simulator,”SIGCOMM demonstration, vol. 14, no. 14, p. 527, 2008

    work page 2008

  7. [7]

    Network simulations with opnet,

    X. Chang, “Network simulations with opnet,” inPro- ceedings of the 31st conference on Winter simulation: Simulation—a bridge to the future-Volume 1, 1999, pp. 307–314

    work page 1999

  8. [8]

    Omnet++,

    A. Varga, “Omnet++,” inModeling and tools for network simulation. Springer, 2010, pp. 35–59

    work page 2010

  9. [9]

    Glomosim: A scal- able network simulation environment,

    L. Bajaj, M. Takai, R. Ahujaet al., “Glomosim: A scal- able network simulation environment,”UCLA computer science department technical report, vol. 990027, no. 1999, p. 213, 1999

    work page 1999

  10. [10]

    The open-closed principle,

    R. C. Martin, “The open-closed principle,”More C++ gems, vol. 19, no. 96, p. 9, 1996

    work page 1996

  11. [11]

    Cooperative task management without manual stack management,

    A. Adya, J. Howell, M. Theimeret al., “Cooperative task management without manual stack management,” in2002 USENIX Annual Technical Conference (USENIX ATC 02), 2002

    work page 2002

  12. [12]

    Coherent reaction,

    J. Edwards, “Coherent reaction,” Tech. Rep., 2009

    work page 2009

  13. [13]

    Fertig,Programming with C++ 20: Concepts, Corou- tines, Ranges, and more

    A. Fertig,Programming with C++ 20: Concepts, Corou- tines, Ranges, and more. Fertig Publications, 2021

    work page 2021

  14. [14]

    Mpi: a standard message passing interface,

    D. W. Walker and J. J. Dongarra, “Mpi: a standard message passing interface,”Supercomputer, vol. 12, pp. 56–68, 1996

    work page 1996

  15. [15]

    Hpcc: High precision congestion control,

    Y . Li, R. Miao, H. H. Liuet al., “Hpcc: High precision congestion control,” inProceedings of the ACM special interest group on data communication, 2019, pp. 44–58

    work page 2019

  16. [16]

    Secularization, rip,

    R. Stark, “Secularization, rip,”Sociology of religion, vol. 60, no. 3, pp. 249–273, 1999

    work page 1999

  17. [17]

    Functional and performance analysis of discrete event network simulation tools,

    A. Musa and I. Awan, “Functional and performance analysis of discrete event network simulation tools,” Simulation Modelling Practice and Theory, vol. 116, p. 10 102470, 2022

    work page 2022

  18. [18]

    G. F. Riley and T. R. Henderson,The ns-3 network simulator. Springer, 2010, pp. 15–34

    work page 2010

  19. [19]

    Asynchronous data dissemination and its applications,

    S. Das, Z. Xiang, and L. Ren, “Asynchronous data dissemination and its applications,” inProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 2705–2721

    work page 2021

  20. [20]

    Depfast: Orchestrat- ing code of quorum systems,

    X. Luo, W. Shen, S. Mu, and T. Xu, “Depfast: Orchestrat- ing code of quorum systems,” in2022 USENIX Annual Technical Conference (USENIX ATC 22), 2022, pp. 557– 574

    work page 2022

  21. [21]

    Continuation complexity: A callback hell for distributed systems,

    E. Zamora-G ´omez, P. Garc ´ıa-L´opez, and R. Mond ´ejar, “Continuation complexity: A callback hell for distributed systems,” inEuro-Par 2015: Parallel Processing Work- shops, S. Hunold, A. Costan, D. Gim ´enezet al., Eds. Cham: Springer International Publishing, 2015, pp. 286– 298

    work page 2015

  22. [22]

    An introduc- tion to the mpi standard,

    J. J. Dongarra, S. W. Otto, M. Sniret al., “An introduc- tion to the mpi standard,”Communications of the ACM, vol. 18, p. 11, 1995

    work page 1995

  23. [23]

    Using discrete event simu- lation for programming model exploration at extreme- scale: Macroscale components for the structural sim- ulation toolkit (sst)

    J. J. Wilke and J. P. Kenny, “Using discrete event simu- lation for programming model exploration at extreme- scale: Macroscale components for the structural sim- ulation toolkit (sst).” Sandia National Lab.(SNL-CA), Livermore, CA (United States), Tech. Rep., 2015

    work page 2015

  24. [24]

    Contention-based congestion management in large-scale networks,

    G. Kim, C. Kim, J. Jeonget al., “Contention-based congestion management in large-scale networks,” in2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 2016, pp. 1–13

    work page 2016

  25. [25]

    A survey of asynchronous programming using coroutines in the internet of things and embedded systems,

    B. Belson, J. Holdsworth, W. Xiang, and B. Philippa, “A survey of asynchronous programming using coroutines in the internet of things and embedded systems,”ACM Transactions on Embedded Computing Systems (TECS), vol. 18, no. 3, pp. 1–21, 2019

    work page 2019

  26. [26]

    Pro- tothreads: Simplifying event-driven programming of memory-constrained embedded systems,

    A. Dunkels, O. Schmidt, T. V oigt, and M. Ali, “Pro- tothreads: Simplifying event-driven programming of memory-constrained embedded systems,” inProceedings of the 4th international conference on Embedded net- worked sensor systems, 2006, pp. 29–42

    work page 2006

  27. [27]

    C++ 20 coroutines on microcontrollers—what we learned,

    B. Belson, W. Xiang, J. Holdsworth, and B. Philippa, “C++ 20 coroutines on microcontrollers—what we learned,”IEEE Embedded Systems Letters, vol. 13, no. 1, pp. 9–12, 2020

    work page 2020

  28. [28]

    Fibers under the magnifying glass,

    G. Nishanov, “Fibers under the magnifying glass,” ISO C++ Committee, Tech. Rep. P1364R0, Nov. 2018

    work page 2018

  29. [29]

    Fibers are not (p) threads: The case for loose coupling of asynchronous programming models and mpi through continuations,

    J. Schuchart, C. Niethammer, and J. Gracia, “Fibers are not (p) threads: The case for loose coupling of asynchronous programming models and mpi through continuations,” inProceedings of the 27th European MPI Users’ Group Meeting, 2020, pp. 39–50

    work page 2020

  30. [30]

    The demikernel datapath os architecture for microsecond-scale datacenter systems,

    I. Zhang, A. Raybuck, P. Patelet al., “The demikernel datapath os architecture for microsecond-scale datacenter systems,” inProceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles, 2021, pp. 195–211

    work page 2021

  31. [31]

    Seda: An archi- tecture for well-conditioned, scalable internet services,

    M. Welsh, D. Culler, and E. Brewer, “Seda: An archi- tecture for well-conditioned, scalable internet services,” vol. 35, no. 5. ACM New York, NY , USA, 2001, pp. 230–243

    work page 2001

  32. [32]

    Revisiting corou- tines,

    A. L. D. Moura and R. Ierusalimschy, “Revisiting corou- tines,”ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 31, no. 2, pp. 1–31, 2009

    work page 2009

  33. [33]

    On the expressive power of programming languages,

    M. Felleisen, “On the expressive power of programming languages,”Science of computer programming, vol. 17, no. 1-3, pp. 35–75, 1991

    work page 1991

  34. [34]

    Klabnik and C

    S. Klabnik and C. Nichols,The Rust programming lan- guage. No Starch Press, 2023

    work page 2023

  35. [35]

    Resin: a holistic service for dealing with memory leaks in production cloud infrastructure,

    C. Lou, C. Chen, P. Huanget al., “Resin: a holistic service for dealing with memory leaks in production cloud infrastructure,” in16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22), 2022, pp. 109–125

    work page 2022

  36. [36]

    The c++ standard library: a tutorial and reference,

    N. M. Josuttis, “The c++ standard library: a tutorial and reference,” 2012

    work page 2012

  37. [37]

    Capriccio: Scalable threads for internet services,

    R. V on Behren, J. Condit, F. Zhouet al., “Capriccio: Scalable threads for internet services,”ACM SIGOPS Operating Systems Review, vol. 37, no. 5, pp. 268–281, 2003

    work page 2003

  38. [38]

    A natural semantics for lazy evaluation,

    J. Launchbury, “A natural semantics for lazy evaluation,” inProceedings of the 20th ACM SIGPLAN-SIGACT sym- posium on Principles of programming languages, 1993, pp. 144–154

    work page 1993

  39. [39]

    R. C. Martin,Clean code: a handbook of agile software craftsmanship. Pearson Education, 2009

    work page 2009

  40. [40]

    Why functional programming matters,

    J. Hughes, “Why functional programming matters,”The computer journal, vol. 32, no. 2, pp. 98–107, 1989

    work page 1989

  41. [41]

    Analysing software repositories to understand software evolution,

    T. Mens, S. Demeyer, M. D’Ambroset al., “Analysing software repositories to understand software evolution,” Software evolution, pp. 37–67, 2008

    work page 2008

  42. [42]

    A model for reason- ing about javascript promises,

    M. Madsen, O. Lhot ´ak, and F. Tip, “A model for reason- ing about javascript promises,”Proceedings of the ACM on Programming Languages, vol. 1, no. OOPSLA, pp. 1–24, 2017

    work page 2017

  43. [43]

    Pause’n’play: Formalizing asynchronous c,

    G. Bierman, C. Russo, G. Mainlandet al., “Pause’n’play: Formalizing asynchronous c,” inEuropean Conference on Object-Oriented Programming. Springer, 2012, pp. 233–257

    work page 2012

  44. [44]

    A detailed and flexible cycle-accurate network-on-chip simulator,

    N. Jiang, D. U. Becker, G. Michelogiannakiset al., “A detailed and flexible cycle-accurate network-on-chip simulator,” in2013 IEEE international symposium on performance analysis of systems and software (ISPASS). IEEE, 2013, pp. 86–96

    work page 2013

  45. [45]

    The design and implementation of open vswitch,

    B. Pfaff, J. Pettit, T. Koponenet al., “The design and implementation of open vswitch,” in12th USENIX sym- posium on networked systems design and implementation (NSDI 15), 2015, pp. 117–130

    work page 2015

  46. [46]

    Network emulation with netem,

    S. Hemmingeret al., “Network emulation with netem,” inLinux conf au, vol. 5, 2005, p. 2005

    work page 2005

  47. [47]

    Openstack: toward an open-source solution for cloud computing,

    O. Sefraoui, M. Aissaoui, M. Eleuldjet al., “Openstack: toward an open-source solution for cloud computing,” International Journal of Computer Applications, vol. 55, no. 3, pp. 38–42, 2012. 11

    work page 2012