Hubbry Logo
Network transparencyNetwork transparencyMain
Open search
Network transparency
Community hub
Network transparency
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Network transparency
Network transparency
Network transparency
View on Wikipedia
from Wikipedia

Network transparency refers to the ability of a protocol to transmit data over the network in a manner which is not observable to those using the applications that are using the protocol. In this way, users of a particular application may access remote resources in the same manner in which they would access their own local resources. An example of this is cloud storage, where remote files are presented as being locally accessible, and cloud computing where the resource in question is processing.

X Window

[edit]

The term is often partially correctly applied in the context of the X Window System, which is able to transmit graphical data over the network and integrate it seamlessly with applications running and displaying locally; however, certain extensions of the X Window System are not capable of working over the network.[1]

Databases

[edit]

In a centralized database system, the only available resource that needs to be shielded from the user is the data (that is, the storage system). In a distributed DBMS, a second resource needs to be managed in much the same manner: the network. Preferably, the user should be protected from the network operational details. Then there would be no difference between database applications that would run on the centralized database and those that would run on a distributed one. This kind of transparency is referred to as network transparency or distribution transparency. From a database management system (DBMS) perspective, distribution transparency requires that users do not have to specify where data is located.

Some have separated distribution transparency into location transparency and naming transparency.

Location transparency in commands used to perform a task is independent both of locations of the data, and of the system on which an operation is carried out.

Naming transparency means that a unique name is provided for each object in the database.

Firewalls

[edit]
See also: Proxy server § Transparent proxy

Transparency in firewall technology can be defined at the networking (IP or Internet layer) or at the application layer.

Transparency at the IP layer means the client targets the real IP address of the server. If a connection is non-transparent, then the client targets an intermediate host (address), which could be a proxy or a caching server. IP layer transparency could be also defined from the point of server's view. If the connection is transparent, the server sees the real client IP. If it is non-transparent, the server sees the IP of the intermediate host.

Transparency at the application layer means the client application uses the protocol in a different way. An example of a transparent HTTP request for a server: 

GET / HTTP/1.1
Host: example.org
Connection: Keep-Alive

An example non-transparent HTTP request for a proxy (cache): 

GET http://foo.bar/ HTTP/1.1
Proxy-Connection: Keep-Alive

Application layer transparency is symmetric when the same working mode is used on both the sides. The transparency is asymmetric when the firewall (usually a proxy) converts server type requests to proxy type or vice versa.

Transparency at the IP layer does not automatically mean application layer transparency.example.org

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Network transparency

View on Grokipedia
from Grokipedia
Network transparency is a fundamental principle in that enables users and applications to interact with remote resources—such as files, printers, or services—indistinguishable from local ones, thereby concealing the underlying network infrastructure and its complexities. This concept combines access transparency, which ensures uniform operations on local and remote entities, and location transparency, which hides the physical or logical placement of resources across the network. Originating in the 1980s as distributed systems evolved from standalone computing, network transparency became a cornerstone for seamless resource sharing in environments like operating systems. In practice, network transparency is implemented through protocols and that abstract network details, allowing applications to function without modification when resources are distributed. For instance, the Network File System (NFS) mounts remote directories as if they were local, enabling file operations like reading or writing without specifying network paths. Similarly, the provides transparency by running remote applications on a local display, a feature pivotal in early . These mechanisms enhance and but introduce challenges, such as managing latency, failures, and without exposing them to the user. While full network transparency remains an ideal—often limited by performance variations and requirements in real-world deployments—it underpins modern , , and remote access technologies, where resources span global data centers yet appear unified. Ongoing research focuses on balancing transparency with efficiency, as seen in systems like the (AFS), which uses caching and location databases to maintain this illusion at scale.

Fundamentals

Definition

Network transparency is a core principle in distributed systems, defined as the property that hides the details of the underlying network and the physical distribution of resources from users and applications, enabling them to access and interact with remote components as if they were local. This concealment extends to network-specific elements such as communication protocols, , hardware heterogeneity, and potential failures, allowing the system to present a unified interface without requiring explicit management of these aspects. Key characteristics of network transparency involve masking distribution-related challenges, including communication delays, resource locations, and inconsistencies arising from heterogeneous environments, to foster the illusion of a single (SSI). By achieving this, the system appears as a cohesive, centralized rather than a collection of disparate machines connected over a network, thereby simplifying interactions and reducing the on developers and end-users. At its foundation, network transparency builds on abstractions provided by and distributed operating systems, which layer services to obscure the separation of components and deliver a virtual uniprocessor-like experience. This approach ensures that the distributed nature remains invisible at higher levels, promoting seamless resource sharing while maintaining the appearance of locality in all operations. A representative example is the invocation of a (RPC), where the syntax and semantics are identical to those of a local call, with the underlying network transmission, parameter marshaling, and error handling fully abstracted away.

Importance

Network transparency, by abstracting the underlying network complexities from users and applications, significantly simplifies interactions in environments, allowing seamless access to resources as if they were local. This abstraction eliminates the need for users to possess knowledge of , resource locations, or distribution mechanisms, thereby enhancing usability and reducing cognitive overhead in managing distributed resources. For instance, users can interact with remote services uniformly, perceiving the system as a cohesive whole rather than a fragmented collection of nodes. For developers, network transparency reduces the intricacy of application design by shielding low-level network handling details, enabling a focus on core business logic and functionality rather than distribution-specific implementations. This leads to improved and portability, as applications can operate across heterogeneous networks without requiring modifications, supported by mechanisms like symbolic that decouple resource names from physical locations. Consequently, development efforts are streamlined, minimizing the burden of adapting to varying conditions or hardware configurations. In terms of scalability, network transparency facilitates efficient load balancing and resource sharing in large-scale systems, such as those in , by enabling dynamic resource placement and migration without disrupting ongoing operations. This abstraction optimizes resource utilization, reduces network traffic—potentially by up to 34% through migration techniques—and supports replication for higher availability via weighted voting protocols. Economically, it lowers development and operational costs by improving system reliability and , abstracting intricacies that could otherwise lead to bottlenecks or single points of failure, while leveraging existing infrastructure to minimize and overhead.

Types of Transparency

Access, Location, and Migration Transparency

Access transparency in distributed systems conceals the differences in data representation and access methods between local and remote resources, allowing users and applications to invoke operations uniformly regardless of whether the resource is local or remote. This ensures that the interface for accessing a resource remains consistent, masking variations in protocols, data formats, or invocation mechanisms that might otherwise distinguish distributed from centralized access. For instance, middleware systems standardize interfaces to hide these discrepancies, enabling seamless interaction across heterogeneous environments. Location transparency permits resources to be identified and accessed using logical names rather than physical addresses, such as IP addresses or machine locations, thereby enabling and relocation without user awareness. Users interact with resources through abstract identifiers that do not reveal their underlying or geographic position, often facilitated by naming services that map logical names to current locations. This supports in large-scale systems by decoupling resource references from specific hardware bindings. Migration transparency allows resources, such as processes or files, to move between nodes in the network without interrupting ongoing operations or requiring reconfiguration by users or applications. This is achieved through mechanisms that maintain consistent access points during relocation, ensuring that references to the resource remain valid post-migration. For example, in scenarios, ongoing connections like telephone calls persist as devices switch between network cells. These transparencies interrelate to enable advanced services, such as renaming and , where access and location transparencies provide the foundation for migration by preserving uniform and name-based addressing during movement. Name servers play a crucial role in achieving location-independent addressing by maintaining mappings from logical names to current physical locations, updating these dynamically to support migration without exposing changes to clients. This integration forms a core aspect of distribution transparency in open distributed frameworks.

Replication, Failure, and Performance Transparency

Replication transparency allows users to access resources in a distributed system without awareness of the multiple copies maintained across nodes for and . By hiding the replication process, including and , it presents a unified view of the resource, as if it were stored in a single location. This abstraction is crucial in systems where is duplicated to enhance reliability, yet users interact solely through a consistent interface. Seminal work on distributed systems principles emphasizes that replication transparency simplifies application development by insulating it from the complexities of managing replicas. Failure transparency conceals faults in hardware, software, or network components, enabling seamless continuation of operations through mechanisms like and automated recovery. When a occurs, the reroutes requests to healthy nodes or restores state without interrupting user tasks, masking the underlying disruption. This property relies on techniques such as process migration and error detection to maintain overall integrity. Research in fault-tolerant computing underscores that transparency reduces the burden on applications to handle exceptions directly. A key mechanism for achieving this is checkpointing, where processes periodically save their states to stable storage; upon , the rolls back to the most recent consistent checkpoint and replays operations to recover progress. The coordinated checkpointing algorithm developed by Koo and Toueg provides a foundational approach, ensuring global consistency with minimal storage overhead by limiting each process to at most two checkpoints. Performance transparency abstracts fluctuations in response times and throughput caused by network latency, varying loads, or resource reconfiguration, delivering a stable experience to users. It is often implemented via dynamic load balancing, which distributes workloads across nodes, and caching, which stores frequently accessed data closer to users to reduce delays. In high-impact distributed systems, this transparency enables reconfiguration—such as adding nodes—without perceptible degradation, though it remains challenging to fully achieve due to inherent trade-offs with other properties. For replication, distributed locking mechanisms enforce consistency by granting exclusive access to resources during updates, preventing concurrent modifications that could lead to inconsistencies across replicas. These locks coordinate via protocols that use timestamps or sequences to resolve contention efficiently. A primary challenge in implementing these transparencies lies in balancing consistency models for replication. demands synchronous updates to all replicas, ensuring immediate visibility of changes but increasing latency and reducing under failures. In contrast, permits asynchronous propagation, allowing higher throughput and at the cost of potential temporary discrepancies, as seen in Amazon's key-value store, which prioritizes for web-scale applications. This trade-off, rooted in the implications, requires designers to select models based on application needs, often favoring for performance-sensitive systems while using distributed locking to mitigate conflicts in critical updates.

Historical Development

Origins

Network transparency emerged in the and amid in and multiprocessor systems, where the goal was to mask the underlying distribution of resources to provide users with a unified view of the system. This period saw early efforts to address the challenges of interconnecting independent computers, drawing from advancements in concurrent programming and network protocols that abstracted away hardware and location details. Researchers recognized that effective distributed systems required hiding complexities such as communication delays and node failures to enable seamless interaction. A key influence came from and early projects in the 1970s, which demonstrated the practical need to abstract network complexities for reliable communication. , operational from 1969, connected diverse computers and spurred the development of protocols like TCP/IP by 1974, designed to allow networked computers to communicate transparently across multiple linked packet networks. These initiatives highlighted how transparency could simplify application development by treating remote resources as if they were local, influencing subsequent distributed system designs. Foundational contributions in the 1980s came from Andrew S. Tanenbaum's work on distributed operating systems, which emphasized the "single system image" principle to make distributed resources appear as one coherent entity. In his 1981 publication Computer Networks, Tanenbaum introduced transparency principles, distinguishing networks from distributed systems based on the degree of cohesiveness and hiding of distribution aspects. The theoretical basis for these ideas stemmed from concurrent programming models, including the proposed by Carl Hewitt, , and Richard Steiger in 1973, which treated actors as primitives for concurrent computation with location-transparent , and process calculi like Robin Milner's Calculus of Communicating Systems (CCS) from 1980, which formalized synchronous and asynchronous interactions in distributed settings. These models provided mathematical foundations for achieving transparency in process communication without exposing network details.

Key Milestones

In the 1980s, the distributed operating system, developed by and colleagues at the starting in the early 1980s, served as an early prototype that demonstrated a comprehensive suite of network transparencies, including access, location, migration, replication, and failure handling, by presenting the distributed environment as a single unified system to users. A key advancement in file access transparency came in 1984 with the introduction of the Network File System (NFS) by , which enabled clients to access remote files as if they were local through a that abstracted network details. The 1990s saw progress in standardizing location transparency for remote object invocation through the (CORBA), with version 1.1 released in 1991 by the (OMG), allowing applications to communicate across distributed environments without explicit knowledge of object locations via interface definition language (IDL) and object request brokers. In the 2000s, the era advanced replication transparency with the launch of Amazon Simple Storage Service (S3) on March 14, 2006, by , which provided scalable where data replication across multiple facilities for durability and availability was managed automatically and invisibly to users. A more recent milestone occurred in 2014 with the initial release of in June, an open-source container orchestration platform originally developed at and donated to the , which achieves migration and failure transparency by automatically rescheduling workloads across nodes and restarting failed containers without user intervention.

Applications

In Windowing Systems

Network transparency in windowing systems enables graphical applications to operate across networked machines as if they were local, abstracting the distribution of display and input resources. A seminal implementation is the , developed in 1984 at MIT's , which permits applications on one host to render windows and process user input on a remote display while concealing the network transport mechanisms. The system's architecture relies on a client-server paradigm, where the X client—typically the graphical application—sends rendering requests and receives input events from the X server, which manages the physical display and peripherals. This communication occurs transparently over TCP/IP, allowing the client to remain unaware of whether the server is local or remote. The X11 protocol, released on September 15, 1987, enhances this by providing location transparency for windows, enabling applications to draw and interact without needing details about the server's rendering hardware or network position. This design supports visual resource migration, where windows can be dynamically redirected or rehosted to different displays in the network without interrupting the application's execution, facilitating seamless transitions in distributed graphical environments. Such capabilities align with broader principles of location and migration transparency in networked systems. Contemporary extensions preserve and secure this transparency; for instance, X11 forwarding in SSH tunnels the X protocol through an encrypted connection, allowing users to run remote graphical applications with local display output while mitigating eavesdropping risks on open networks.

In Database Systems

In database systems, network transparency enables applications to access, query, and update distributed data across geographically dispersed nodes as if interacting with a single, local database, abstracting the underlying network complexities such as latency and node distribution. This abstraction supports seamless scalability and without requiring modifications to application logic. Distributed databases like Google Spanner, developed in , provide a prime example by supporting SQL-like queries over data replicated across global datacenters, presenting the system to users as a unified, local store. Spanner achieves this through its multi-version data model and TrueTime API, which bounds clock uncertainty to under 10 milliseconds using GPS and atomic clocks, ensuring externally consistent reads and writes despite network distances. Location transparency is facilitated via federated queries that automatically route and aggregate results from multiple shards without explicit user directives on data placement. Replication for failure tolerance is implemented via synchronous Paxos-based replication across 3 to 5 datacenters per data item, automatically failing over replicas to maintain during outages. A core mechanism underpinning this transparency is the two-phase commit (2PC) protocol, which coordinates atomic transactions across distributed nodes without exposing the distribution to applications. In the prepare phase, the coordinator polls participants to reserve resources and vote on commit readiness; if unanimous, the commit phase instructs all to finalize changes, logging outcomes for recovery; otherwise, an abort rolls back all, ensuring all-or-nothing semantics. This protocol, optimized in commercial systems for performance, hides coordination overhead and failure recovery from users. Oracle Real Application Clusters (RAC) demonstrates practical application of these principles by hiding node s during ongoing transactions, using Cache Fusion over a private interconnect to transfer blocks and Oracle Clusterware to relocate services and virtual IPs to surviving nodes. Transparent Application (TAF) automatically reconnects clients to backup instances, replaying in-flight work via features like Application Continuity to mask outages, with policies such as SESSION or SELECT types preserving state. Replication and transparency serve as enablers here, allowing queries to continue uninterrupted even amid node crashes or network issues. Sharding transparency represents a specialized form where horizontal data partitioning into is entirely concealed from applications, enabling scalable storage without routing awareness. In Spanner, data is divided into tablets—self-contained —managed dynamically by directories that applications reference abstractly, with automatic reshards and migrations occurring invisibly to balance load and ensure locality. This allows standard query interfaces to operate across partitions as if on a monolithic database, enhancing performance without developer intervention.

In File Systems

Network transparency in file systems allows users to access shared storage across networks as if files were stored locally, abstracting the complexities of distribution to enable seamless and manipulation. This primarily manifests through access transparency, where operations like reading and writing files do not differ based on whether the resides on local or remote storage, and replication transparency, where multiple copies of are maintained without user awareness of the duplication process. The Network File System (NFS), developed by and first released in 1984, exemplifies early achievement of this transparency by enabling clients to mount remote directories directly into their local , treating distant files identically to local ones. NFS achieves location transparency by decoupling file access from physical server details, allowing users and applications to interact with remote resources without specifying network paths or server identities. The protocol's core mechanism relies on a client-server architecture where servers export file systems via RPC calls, and clients perform operations like open, read, and write as if accessing a local disk. NFS version 3 (NFSv3), specified in 1995, operates as a , with each request containing all necessary context to avoid server state maintenance, which supports reliable caching on clients but requires separate handling for file locking. In contrast, NFS version 4 (NFSv4), introduced in 2000, incorporates statefulness to manage sessions, compound operations, and integrated locking, enhancing efficiency for caching and delegation while preserving location independence for users. Building on these foundations, the Coda file system, developed at in the early 1990s, advanced network transparency by integrating replication transparency with support for disconnected operations. Coda replicates volumes across multiple servers, allowing clients to access data from any replica transparently, and caches files locally to enable continued read-write access during network outages or mobility scenarios. Upon reconnection, Coda employs optimistic replication with version vectors to detect and resolve conflicts from concurrent modifications, ensuring without interrupting user workflows. A more modern example is Ceph, an open-source distributed storage system originating from Sage Weil's 2006 doctoral research and first publicly detailed in 2006, which provides object-based storage with automatic data placement for enhanced scalability. Ceph uses the CRUSH algorithm to pseudorandomly distribute objects across cluster nodes based on cluster topology, delivering and migration transparency as data is rebalanced dynamically without client intervention or downtime. This self-managing placement supports petabyte-scale deployments while maintaining access transparency for file, block, and object interfaces. Handling concurrency transparency in multi-user file modifications remains a key challenge and differentiator in these systems, ensuring that simultaneous accesses yield consistent results akin to single-user local environments. NFS addresses this through the Network Lock Manager (NLM) protocol in NFSv3, which provides advisory byte-range locking to coordinate modifications and prevent overwrites, integrated more tightly in NFSv4's stateful model to avoid race conditions. Coda enhances concurrency handling via server-side resolution policies and client-side hoarding, using timestamps and version vectors to merge divergent updates from disconnected users, prioritizing transparency by automating resolutions where possible and prompting manual intervention only for irreconcilable conflicts. In Ceph, concurrency is managed at the object level with atomic operations and leasing mechanisms in RADOS, the underlying object store, allowing multi-user modifications to proceed with guarantees without exposing replication details to applications.

Challenges

Firewalls and Security

Firewalls, essential for blocking unauthorized traffic in distributed systems, often interfere with access transparency by necessitating explicit port and protocol configurations that users must manage, thereby exposing the underlying network structure rather than hiding it. This requirement contradicts the goal of seamless resource access, as applications assuming network transparency may fail when firewall rules restrict connections based on origin or destination details. A prominent example is (NAT), commonly implemented in firewalls to mask internal IP addresses and conserve public IPv4 space, which hides resource locations but complicates migration transparency by preventing straightforward relocation of processes or services without reconfiguration or address rewriting. NAT breaks end-to-end connectivity, forcing applications to incorporate mechanisms that undermine the illusion of a uniform . To mitigate these disruptions, strategies such as Virtual Private Networks (VPNs) and secure tunnels using protocols encapsulate traffic, restoring aspects of access and location transparency while enforcing policies through and . , for instance, supports extensions to maintain connectivity across translated networks without exposing internal details. However, these solutions introduce trade-offs between and usability; achieving full network transparency can heighten vulnerabilities to attacks like man-in-the-middle exploits by reducing isolation layers. Introduced in the by Software Technologies, stateful inspection firewalls track connection states to enhance security but add processing latency that challenges performance transparency in distributed environments. This overhead, stemming from maintaining state tables for each session, can degrade throughput in high-volume scenarios, requiring careful tuning to balance protection and efficiency.

Limitations in Modern Networks

In massive environments, achieving perfect failure transparency—where system failures are entirely hidden from users—proves impractical due to the need for to maintain . allows asynchronous replication across geo-distributed datacenters, enabling elastic scaling and , but it introduces temporary inconsistencies that cannot be fully masked, as updates may not propagate immediately to all replicas. For instance, in systems like Pileus, reads under can be over 100 times faster than in global setups, yet developers must explicitly manage these trade-offs via agreements to ensure predictable behavior, thereby limiting full transparency. The further underscores these constraints, positing that distributed systems cannot simultaneously guarantee consistency, , and partition tolerance in the presence of network partitions. This impossibility directly challenges network transparency, particularly failure and performance aspects, as partial failures (e.g., node crashes or network splits) force systems to sacrifice either consistent views or uninterrupted access, breaking the illusion of a seamless, unified environment. In practice, strategies like best-effort during partitions (e.g., in web caching systems) prioritize responsiveness but deliver potentially stale data, while approaches may render parts of the system unavailable, requiring explicit failure notifications that expose underlying distribution. Network delays and bandwidth constraints inherently undermine performance transparency, especially in global distributions where propagation latency varies significantly across paths. In path-aware networks like SCION, the abundance of alternative routes (dozens to over 100 per destination) complicates real-time latency measurement, as dynamic queuing delays from cross-traffic prevent accurate predictions, leading to suboptimal path selection and visible performance disparities. For short-lived flows, such as DNS queries, measurement overhead exceeds flow duration, exacerbating bottlenecks and making it difficult to hide latency variations from applications. Modern IoT and amplify these issues through device heterogeneity, where variations in protocols, formats, and connectivity models hinder full network transparency. Heterogeneity in devices (affecting 49% of integration challenges) and communication standards (36%) creates barriers, as diverse edge nodes cannot seamlessly mask differences in access methods or representation, leading to fragmented views across the system. In edge environments, this results in partial transparencies that expose underlying variations, complicating unified management without specialized frameworks. Looking ahead, offers potential for adaptive transparency in and networks by dynamically optimizing and handling inconsistencies. AI-driven approaches, including hybrid evolutionary algorithms, enhance interpretability and simulatability in vehicular and edge scenarios, enabling real-time adjustments to latency and failures while improving overall network efficiency and robustness.

References

  1. https://www.cs.cmu.edu/~satya/docdir/satya89survey.pdf
  2. https://eecs.wsu.edu/~bakken/564-Fall2011-Slides/Chap1Slides.pdf
  3. https://www.linfo.org/network_transparency.html
  4. https://crystal.uta.edu/~kumar/cse6306/papers/mantena.pdf
  5. http://occs.oberlin.edu/~ctaylor/pubs/cbtaylor_cloud.pdf
  6. https://fenix.tecnico.ulisboa.pt/downloadFile/2252418288979304/Coulouris-Distributed_Systems.pdf
  7. https://www.cl.cam.ac.uk/~jac22/books/ods/ods/node18.html
  8. https://apps.dtic.mil/sti/tr/pdf/ADA214430.pdf
  9. https://www.pearson.com/en-us/subject-catalog/p/distributed-systems-concepts-and-design/P200000003160/9780137521081
  10. https://www.itu.int/rec/T-REC-X.903/en
  11. https://www.semanticscholar.org/topic/Failure-transparency/1050690
  12. https://ieeexplore.ieee.org/document/1702129
  13. https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
  14. https://www.cs.vu.nl/~ast/Publications/Papers/computing-2016.pdf
  15. https://cs.stanford.edu/people/eroberts/courses/soco/projects/distributed-computing/html/history.html
  16. https://www.internetsociety.org/internet/history-internet/brief-history-internet-related-networks/
  17. https://www.semanticscholar.org/paper/A-Universal-Modular-ACTOR-Formalism-for-Artificial-Hewitt-Bishop/acb2f7040e21cbe456030c8535bc3f2aafe83b02
  18. https://dl.acm.org/doi/10.1145/96267.96281
  19. http://www.cse.buffalo.edu/faculty/tkosar/cse710_spring13/papers/nfs.pdf
  20. https://www.omg.org/spec/CORBA/1.2/PDF
  21. https://aws.amazon.com/s3/resources/
  22. https://aws.amazon.com/s3/features/replication/
  23. https://www.cncf.io/blog/2024/07/26/the-inevitable-kubernetes-10-years-still-a-lot-to-do/
  24. https://kubernetes.io/
  25. https://web.mit.edu/saltzer/www/publications/athenaplan/f.1.1.pdf
  26. https://dl.acm.org/doi/10.1145/22949.24053
  27. https://www.rfc-editor.org/rfc/rfc1013.html
  28. https://man7.org/linux/man-pages/man1/ssh.1.html
  29. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-openssh
  30. https://research.google.com/archive/spanner-osdi2012.pdf
  31. https://15799.courses.cs.cmu.edu/fall2013/static/papers/ICDE93Commit.pdf
  32. https://docs.oracle.com/en/database/oracle/oracle-database/21/racad/real-application-clusters-administration-and-deployment-guide.pdf
  33. https://pages.cs.wisc.edu/~remzi/Classes/736/Fall2002/Papers/nfs.pdf
  34. https://www.techtarget.com/searchenterprisedesktop/definition/Network-File-System
  35. https://www.ietf.org/rfc/rfc1813.txt
  36. https://cs.uwaterloo.ca/~brecht/courses/702/Possible-Readings/file-systems/coda-file-system-tocs-1990.pdf
  37. https://dl.acm.org/doi/10.1145/121132.121166
  38. https://ceph.io/assets/pdfs/weil-ceph-osdi06.pdf
  39. https://fenix.tecnico.ulisboa.pt/downloadFile/2252418288979313/Xtra-S1-A2-Coulouris-Distributed_Systems_CH-1.pdf
  40. https://www.ogf.org/documents/GFD.83.pdf
  41. https://www.rfc-editor.org/rfc/rfc4924.html
  42. https://www.ietf.org/archive/id/draft-matsuhira-oht-04.html
  43. https://csrc.nist.gov/pubs/sp/800/77/r1/final
  44. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dplane/configuration/15-mt/sec-ipsec-data-plane-15-mt-book/sec-ipsec-nat-transp.pdf
  45. https://www.rfc-editor.org/rfc/rfc2775.html
  46. https://www.checkpoint.com/cyber-hub/network-security/firewall-as-a-service-fwaas/what-is-a-stateful-packet-inspection-firewall/
  47. https://cyberratings.org/stateful-vs-stateless-inspection-use-cases-and-limitations/
  48. https://sigops.org/s/conferences/sosp/2013/papers/p309-terry.pdf
  49. https://groups.csail.mit.edu/tds/papers/Gilbert/Brewer2.pdf
  50. https://webperso.info.ucl.ac.be/~pvr/positionPaperPVR.pdf
  51. https://netsec.ethz.ch/publications/papers/kraehenbuehl2024latency.pdf
  52. https://onlinelibrary.wiley.com/doi/10.1155/2022/8626882
  53. https://www.wiley.com/en-se/AI-Enabled%2B6G%2BNetworks%2Band%2BApplications-p-9781119812722
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.