DOCSLIB.ORG

Wrapper Facade 1 Wrapper Facade

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Wrapper Facade 1 Wrapper Facade Wrapper Facade 1 Wrapper Facade The Wrapper Facade design pattern encapsulates low-level functions and data structures within more concise, robust, portable, and maintainable object-oriented class interfaces. Example Consider you are developing a server for a distributed logging service that can handle multiple clients concurrently using a connection-ori- ented protocol like TCP [Ste90]. When a client wants to log data, it must first send a connection request. The logging server accepts con- nection requests using an acceptor factory, which listens on a net- work address known to clients. When a connection request arrives from a client, the acceptor factory accepts the client's connection and creates a socket handle that rep- resents this client's connection endpoint. This handle is passed up to the logging server, which spawns a thread and waits in this thread for logging requests to arrive on the connected socket handle. Once a cli- ent is connected, it can send logging requests to the server. The server receives these requests via the connected socket handles, processes the logging requests, and writes the requests to a log file. Server Server 1: socket() 2: bind() 3: listen() 8: recv() 5: accept() 9: write() 6: thr_create() 4: connect() Client : Acceptor : Logging 7: send() Factory Handler A common way to develop the logging server is to use low-level C lan- guage functions and data structures for threading, synchronization and network communication, for example by using Solaris threads [EKBF+92] and the socket [Ste97] network programming API. However, if the logging server is expected to run on multiple plat- forms, such as Solaris and Win32, the data structures you need may differ in type, and the functions may differ in their syntax and seman- © Douglas C. Schmidt 1998, 1999, all rights reserved, © Siemens AG 1998, 1999, all rights reserved 23.04.1999 Wrapper-Facade.pub.doc 2 tics. As a result, the implementation will contain code that handles the differences in the Solaris and Win32 operating system APIs for sockets, mutexes, and threads. For example, if written with C APIs, the logging server implementation and the logging handler function, which runs in its own thread, will likely contain many #ifdefs: #if defined (_WIN32) #if defined (_WIN32) #include <windows.h> EnterCriticalSection (&lock); typedef int ssize_t; #else #else mutex_lock (&lock); // The following typedef is platform-specific. #endif /* _WIN32 */ typedef unsigned int UINT32; // Execute following two statements #include <thread.h> // in a critical section to avoid #include <unistd.h> // race conditions and scrambled #include <sys/socket.h> // output, respectively. #include <netinet/in.h> // Count # of requests #include <memory.h> ++request_count; #endif /* _WIN32 */ if (write_record (log_record, len) == -1) break; // Keep track of number of logging requests. static int request_count; #if defined (_WIN32) LeaveCriticalSection (&lock); // Lock to protect request_count. #else #if defined (_WIN32) mutex_unlock (&lock); static CRITICAL_SECTION lock; #endif /* _WIN32 */ #else } static mutex_t lock; #endif /* _WIN32 */ #if defined (_WIN32) closesocket (h); // Maximum size of a logging record. #else static const int LOG_RECORD_MAX = 1024; close (h); #endif /* _WIN32 */ // Port number to listen on for requests. return 0; static const int logging_port = 10000; } // Entry point that writes logging records. // Main driver function for the server. int write_record (char log_record[], int len) { int main (int argc, char *argv[]) { /* ... */ struct sockaddr_in sock_addr; return 0; } // Handle UNIX/Win32 portability. #if defined (_WIN32) // Entry point that processes logging records for SOCKET acceptor; // one client connection. #else #if defined (_WIN32) int acceptor; u_long #endif /* _WIN32 */ #else // Create a local endpoint of communication. void * acceptor = socket (PF_INET, SOCK_STREAM, 0); #endif /* _WIN32 */ // Set up the address to become a server. logging_handler (void *arg) { memset (reinterpret_cast<void *> (&sock_addr), // Handle UNIX/Win32 portability. 0, sizeof sock_addr); #if defined (_WIN32) sock_addr.sin_family = AF_INET; SOCKET h = reinterpret_cast <SOCKET> (arg); sock_addr.sin_port = htons (logging_port); #else sock_addr.sin_addr.s_addr = htonl (INADDR_ANY); int h = reinterpret_cast <int> (arg); // Associate address with endpoint. #endif /* _WIN32 */ bind (acceptor, reinterpret_cast<struct sockaddr *> (&sock_addr), sizeof sock_addr); for (;;) { // Make endpoint listen for connections. #if defined (_WIN32) listen (acceptor, 5); ULONG len; #else // Main server event loop. UINT32 len; for (;;) { #endif /* _WIN32 */ // Handle UNIX/Win32 portability. #if defined (_WIN32) // Ensure a 32-bit quantity. SOCKET h; char log_record[LOG_RECORD_MAX]; DWORD t_id; #else // The first <recv> reads the length int h; // (stored as a 32-bit integer) of thread_t t_id; // adjacent logging record. This code #endif /* _WIN32 */ // does not handle "short-<recv>s". // Block waiting for clients to connect. ssize_t n = recv (h, h = accept (acceptor, 0, 0); reinterpret_cast <char *> (&len), // Spawn a new thread that runs the <server> sizeof len, 0); // entry point. // Bail out if we're shutdown or #if defined (_WIN32) // errors occur unexpectedly. CreateThread (0, 0, if (n <= sizeof len) break; LPTHREAD_START_ROUTINE(&logging_handler), len = ntohl (len); reinterpret_cast <void *> (h), 0, &t_id); if (len > LOG_RECORD_MAX) break; #else thr_create // The second <recv> then reads <len> (0, 0, logging_handler, // bytes to obtain the actual record. reinterpret_cast <void *> (h), // This code handles "short-<recv>s". THR_DETACHED, &t_id); for (ssize_t nread = 0; nread < len; nread += n) { #endif /* _WIN32 */ n = recv (h, log_record + nread, } len - nread, 0); return 0; // Bail out if an error occurs. } if (n <= 0) return 0; } © Douglas C. Schmidt 1998, 1999, all rights reserved, © Siemens AG 1998, 1999, all rights reserved 23.04.1999 Wrapper-Facade.pub.doc Wrapper Facade 3 Even moving platform-specific declarations into separate configura- tion header files does not resolve the problems. For example, #ifdefs that separate the use of platform-specific APIs, such as the thread creation calls, still pollute application code. Likewise, #ifdefs may also be required to work around compiler bugs or lack of features in certain compilers. The problems with different semantics of these APIs also remain. Moreover, adding a new platform still requires ap- plication developers to modify and update the platform-specific dec- larations, whether they are included directly into application code or separated into configuration files. Context Applications that access services provided by low-level functions and data structures. Problem Applications are often written using low-level operating system func- tions and data structures, such as for networking and threading, or other libraries, such as for user interface or database programming. Although this is common practice, it causes problems for application developers by failing to resolve the following problems: • Verbose, non-robust programs. Application developers who program directly to low-level functions and data structures must repeatedly rewrite a great deal of tedious software logic. In general, code that is tedious to write and maintain often contains subtle and perni- cious errors. ➥ The code for creating and initializing an acceptor socket in the main() function of our logging server example is prone to errors. Common errors include failing to zero-out the sock_addr or not using htons on the logging_port number [Sch92]. In particular, note how the lock will not be released if the write_record() function returns -1. ❏ • Lack of portability. Software written using low-level functions and data structures is often non-portable between different operating systems and compilers. Moreover, it is often not even portable to program to low-level functions across different versions of the same operating system or compiler due to the lack of release-to-release compatibility [Box97]. ➥ Our logging server implementation has hard-coded dependen- cies on several non-portable native operating system threading and © Douglas C. Schmidt 1998, 1999, all rights reserved, © Siemens AG 1998, 1999, all rights reserved 23.04.1999 Wrapper-Facade.pub.doc 4 network programming C APIs. For instance, thr_create(), mutex_lock() and mutex_unlock() are not portable to Win32 platforms. Although the code is designed to be quasi-portable—it also compiles and runs on Win32 platforms—there are various subtle portability problems. In particular, there will be resource leaks on Win32 platforms since there is no equivalent to the Solaris THR_DETACHED feature, which spawns a ‘detached’ thread whose exit status is not stored by the threading library. ❏ • High maintenance effort. C and C++ developers typically achieve portability by explicitly adding conditional compilation directives into their application source code using #ifdefs. However, using conditional compilation to address platform-specific variations at all points of use makes it hard to maintain and extend the applica- tion. In particular, the physical design complexity [Lak95] of the application software becomes very high since platform-specific im- plementation details are scattered throughout the application source files. ➥ The readability and maintainability of the code in our logging server example is impeded by the #ifdefs that handle Win32 and Solaris portability. For instance, several #ifdefs are required to handle differences
Load more

Recommended publications
  • 1. Domain Modeling
    Software design pattern seminar sse, ustc Topic 8 Observer, Mediator, Facade Group K 1. The observer pattern (Behavioral pattern, chapter 16 and 17) 1) the observer is an interface or abstract class defining the operations to be used to update itself 2) a solution to these problems A. Decouple change and related responses so that such dependencies can be added or removed freely and dynamically 3) solution A. Observable defines the operations for attaching, de-attaching and notifying observers B. Observer defines the operations to update itself 4) liabilities A. Unwanted concurrent update to a concrete observable may occur Figure 1 Sample Observer Pattern 2. The mediator pattern (Behavioral pattern, chapter 16 and 17) 1) the mediator encapsulates how a set of objects interact and keeps objects from referring to each other explicitly 2) a solution to these problems A. a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand B. reusing an object is difficult because it refers to and communicates with many other objects C. a behavior that's distributed between several classes should be customizable without a lot of subclassing 3) solution A. Mediator defines an interface for communicating with Colleague objects, knows the colleague classes and keep a reference to the colleague objects, and implements the communication and transfer the messages between the colleague classes 1 Software design pattern seminar sse, ustc B. Colleague classes keep a reference to its Mediator object, and communicates with the Mediator whenever it would have otherwise communicated with another Colleague 4) liabilities A.
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • Secure Telemedicine System for Home Health Care
    Graduate Theses, Dissertations, and Problem Reports 2000 Secure telemedicine system for home health care Sridhar Vasudevan West Virginia University Follow this and additional works at: https://researchrepository.wvu.edu/etd Recommended Citation Vasudevan, Sridhar, "Secure telemedicine system for home health care" (2000). Graduate Theses, Dissertations, and Problem Reports. 1099. https://researchrepository.wvu.edu/etd/1099 This Thesis is protected by copyright and/or related rights. It has been brought to you by the The Research Repository @ WVU with permission from the rights-holder(s). You are free to use this Thesis in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses you must obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/ or on the work itself. This Thesis has been accepted for inclusion in WVU Graduate Theses, Dissertations, and Problem Reports collection by an authorized administrator of The Research Repository @ WVU. For more information, please contact [email protected]. SECURE TELEMEDICINE SYSTEM FOR HOME HEALTH CARE Sridhar Vasudevan Thesis submitted to the College of Engineering and Mineral Resources at West Virginia University in partial fulfillment of the requirements for the degree of Master of Science in Computer Science V.Jagannathan, Ph.D., Chair Sumitra Reddy, Ph.D. James D. Mooney, Ph.D. Department of Computer Science and Electrical Engineering Morgantown, West Virginia 2000 Keywords: EJB, Java, Home Health Care, Telemedicine SECURE TELEMEDICINE SYSTEM FOR HOME HEALTH CARE Sridhar Vasudevan ABSTRACT This thesis describes a low-cost telemedicine system that provides home based patient care by linking patients with skilled nurses at the home care agency.
    [Show full text]
  • Java Design Patterns I
    Java Design Patterns i Java Design Patterns Java Design Patterns ii Contents 1 Introduction to Design Patterns 1 1.1 Introduction......................................................1 1.2 What are Design Patterns...............................................1 1.3 Why use them.....................................................2 1.4 How to select and use one...............................................2 1.5 Categorization of patterns...............................................3 1.5.1 Creational patterns..............................................3 1.5.2 Structural patterns..............................................3 1.5.3 Behavior patterns...............................................3 2 Adapter Design Pattern 5 2.1 Adapter Pattern....................................................5 2.2 An Adapter to rescue.................................................6 2.3 Solution to the problem................................................7 2.4 Class Adapter..................................................... 11 2.5 When to use Adapter Pattern............................................. 12 2.6 Download the Source Code.............................................. 12 3 Facade Design Pattern 13 3.1 Introduction...................................................... 13 3.2 What is the Facade Pattern.............................................. 13 3.3 Solution to the problem................................................ 14 3.4 Use of the Facade Pattern............................................... 16 3.5 Download the Source Code.............................................
    [Show full text]
  • Design Patterns Mock Test
    DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT http://www.tutorialspoint.com Copyright © tutorialspoint.com This section presents you various set of Mock Tests related to Design Patterns Framework. You can download these sample mock tests at your local machine and solve offline at your convenience. Every mock test is supplied with a mock test key to let you verify the final score and grade yourself. DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT IIII Q 1 - Which of the following describes the Composite pattern correctly? A - This pattern builds a complex object using simple objects and using a step by step approach. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 2 - Which of the following describes the Decorator pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 3 - Which of the following describes the Facade pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure.
    [Show full text]
  • Developing GUI Applications. Architectural Patterns Revisited
    Developing GUI Applications: Architectural Patterns Revisited A Survey on MVC, HMVC, and PAC Patterns Alexandros Karagkasidis [email protected] Abstract. Developing large and complex GUI applications is a rather difficult task. Developers have to address various common soFtware engineering problems and GUI-speciFic issues. To help the developers, a number of patterns have been proposed by the software community. At the architecture and higher design level, the Model-View-Controller (with its variants) and the Presentation-Abstraction- Control are two well-known patterns, which specify the structure oF a GUI application. However, when applying these patterns in practice, problems arise, which are mostly addressed to an insuFFicient extent in the existing literature (iF at all). So, the developers have to find their own solutions. In this paper, we revisit the Model-View-Controller, Hierarchical Model-View- Controller, and Presentation-Abstraction-Control patterns. We first set up a general context in which these patterns are applied. We then identiFy Four typical problems that usually arise when developing GUI applications and discuss how they can be addressed by each of the patterns, based on our own experience and investigation oF the available literature. We hope that this paper will help GUI developers to address the identified issues, when applying these patterns. 1 Introduction Developing a large and complex graphical user interface (GUI) application for displaying, working with, and managing complex business data and processes is a rather difficult task. A common problem is tackling system complexity. For instance, one could really get lost in large number of visual components comprising the GUI, not to mention the need to handle user input or track all the relationships between the GUI and the business logic components.
    [Show full text]
  • Design Patterns Design Patterns
    Design Patterns • More design patterns (GoF) – Structural: Adapter, Bridge, Façade – Creational: Abstract Factory, Singleton – Behavioral: Observer, Iterator, State, Visitor Design Patterns-10, CS431 F06, BG Ryder/A Rountev 1 Design Patterns • Design patterns have become very popular in the last decade or so • Major source: GoF book 1995 • “Design Patterns: Elements of Reusable Object- Oriented Software” • Gamma, Helm, Johnson, Vlissides (gang of 4) • Patterns describe well-known solutions to common design problems • Used in Java libraries, especially in the GUI libraries Design Patterns-10, CS431 F06, BG Ryder/A Rountev 2 1 Design Patterns (LAR Ch26; GoF) • Structural • Concerned with how classes and objects are composed to make larger structures (Adapter, Bridge, Composite, Façade) • Creational • Abstract the instantiation process to make a system independent of how its objects are created & represented (Abstract Factory, Singleton) • Behavioral • Describe patterns of communication and interaction between objects (algorithms and responsibility assignment) (Observer, State, Strategy, Mediator) Design Patterns-10, CS431 F06, BG Ryder/A Rountev 3 Adapter Pattern: Interface Matcher • Problem: incompatible interfaces • Solution: create a wrapper that maps one interface to another • Key point: neither interface has to change and they execute in decoupled manner – Think of how you use a power plug adaptor when you travel to Europe • Example: – Client written against some interface – Server with the right functionality but with the wrong interface
    [Show full text]
  • 1 Layered Architecture
    e-gov Architecture Application Architecture 1 Layered Architecture ................................................................................. 3 1.1 Introduction ..................................................................................... 3 1.2 Best practices................................................................................... 3 1.2.1 Choose a layered architecture ......................................................... 3 1.2.2 Apply design patterns to layer the architeture.................................... 6 2 Domain Layer .......................................................................................... 8 2.1 Introduction ..................................................................................... 8 2.2 Best practices................................................................................... 8 2.2.1 Introduce a domain layer in the architecture...................................... 8 2.2.2 Apply design patterns on the domain layer ........................................ 9 2.2.3 Utilize the full power of OO ............................................................10 2.2.4 Avoid the anemic domain model .....................................................10 2.2.5 Minimize the dependencies with other layers ....................................10 2.2.6 Unit test the domain layer..............................................................10 3 Service Layer..........................................................................................11 3.1 Introduction ....................................................................................11
    [Show full text]
  • Introduction to Design Patterns
    Chapter 1 Introduction • Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. • It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don't. • Expert designers find recurring patterns of classes and communicating objects in many object-oriented systems, and can apply them immediately to design problems without having to rediscover them. • Recording experience in designing object-oriented software as design patterns. • Design patterns make it easier to reuse successful designs and architectures. What is a Design Pattern? • Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice". • Four essential elements of a pattern:: 1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. 2. The problem describes when to apply the pattern. 3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations 4. The consequences are the results and trade-offs of applying the pattern. • The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. Design Patterns in Smalltalk MVC • Model is the application object • View is the model's screen presentation • Controller defines the way the user interface reacts to user input.
    [Show full text]
  • Abstract Factory Pattern Real World Example
    Abstract Factory Pattern Real World Example Sparry Reuven blackmails some spiritual and outact his swimming so fumblingly! Gasper remains unilateral: she embow her observatories allegorize too ninefold? Whining Dirk wince some menstruation and traps his Alain-Fournier so banteringly! Can You Improve This Article? Abstract factory code and features, when there are different flavors of elements of each service and every shape based on objects will implement modular gui design pattern real object step is. Do this pattern is hard before uploading a level, we are prototypical instance creation logic on desktop or dependent products are design pattern is often. Living in real world design pattern real factory world example, real world has a generic interfaces that will post helpful example, amazon web api like services. If i like this Decorator design pattern tutorial in Java then my share remains your friends and colleagues. Let's you factory method with own factory voil here read the. So basically, we release another attribute of abstraction which will identify the location and internally use again car factory implementation without even giving a single hint you the user. Sometimes, it think of patterns as recipes. It is not related to that. This is the Elven Army! In their state, we have been made up of objects of objects. What medium the intent of the merit Pool pattern? Given a real object as needed. This differs from the Observer pattern determined it allows any subscriber implementing an advance event handler to register what and vague topic notifications broadcast radio the publisher. And think is real world you have new instance property from a partial classes one place here abstract container, we have no review stack exchange is not.
    [Show full text]
  • Wrapper Facade
    Wrapper Facade A Structural Pattern for Encapsulating Functions within Classes Douglas C. Schmidt [email protected] Department of Computer Science Washington University St. Louis, MO 63130, (314) 935-7538 This paper appeared in the C++ Report magazine, Febru- ary, 1999. CLIENT DATABASE 1 Introduction PRINTER CONNECTION This paper describes the Wrapper Facade pattern. The intent REQUEST LOGGING of this pattern is to encapsulate low-level functions and data SERVER structures with object-oriented (OO) class interfaces. Com- SOCKET HANDLES mon examples of the Wrapper Facade pattern are class li- NETWORK braries like MFC, ACE, and AWT that encapsulate native CONSOLE OS C APIs, such as sockets, pthreads, or GUI functions. CLIENT LOGGING Programming directly to native OS C APIs makes net- RECORDS LOGGING working applications verbose, non-robust, non-portable, and RECORDS hard to maintain because it exposes many low-level, error- CLIENT SERVER prone details to application developers. This paper illus- trates how the Wrapper Facade pattern can help to make these types of applications more concise, robust, portable, and maintainable. Figure 1: Distributed Logging Service This paper is organized as follows: Section 2 describes the Wrapper Facade pattern in detail using the Siemens for- mat [1] and Section 3 presents concluding remarks. The logging server shown in Figure 1 handles connec- tion requests and logging records sent by clients. Logging records and connection requests can arrive concurrently on 2 Wrapper Facade Pattern multiple socket handles. Each handle identifies network communication resources managed within an OS. 2.1 Intent Clients communicate with the logging server using a connection-oriented protocol like TCP [2].
    [Show full text]