Network Programming Ii - Oopn

  • June 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Network Programming Ii - Oopn as PDF for free.

More details

  • Words: 721
  • Pages: 7
Network Daemon Design Dimensions

•Communication dimensions address the rules, form, & level of abstraction that networked applications use to interact •Concurrency dimensions address the policies & mechanisms governing the proper use of processes & threads to represent multiple service instances, as well as how each service instance may use multiple threads internally 1

•Service dimensions address key properties of a networked application service, such as the duration & structure of each service instance •Configuration dimensions address how networked services are identified & the time at which they are bound together to form complete applications

Communication Design Dimensions

• Communication is fundamental to networked application design • The next three slides present a domain analysis of communication design dimensions, which address the rules, form, and levels of abstraction that networked applications use to interact with each other • We cover the following communication design dimensions: • Connectionless versus connection-oriented protocols • Synchronous versus asynchronous message exchange • Message-passing versus shared memory

2

Connectionless vs. Connection-oriented Protocols • A protocol is a set of rules that specify how control & data information is exchanged between communicating entities

SYN SYN/ACK ACK

Connector

Acceptor

3-way handshake in TCP/IP • Connection-oriented protocols

• Connectionless protocols provide

provide a reliable, sequences, nonduplicated delivery service, which is useful for applications that can’t tolerate data loss • Examples include TCP & ATM

a message-oriented service in which each message can be routed and delivered independently • Examples include UDP & IP

• Connection-oriented applications must address two additional design issues: •Data framing strategies, e.g., bytestream vs. message-oriented •Connection multiplexing (muxing) strategies, e.g., multiplexed vs. nonmultiplexed 3

Alternative Connection Muxing Strategies

•In multiplexed connections all client requests emanating from threads in a single process pass through one TCP connection to a server process •Pros: Conserves OS communication resources, such as socket handles and connection control blocks •Cons: harder to program, less efficient, & less deterministic 4

•In nonmultiplexed connections each client uses a different connection to communicate with a peer service •Pros: Finer control of communication priorities & low synchronization overhead since additional locks aren't needed •Cons: use more OS resources, & therefore may not scale well in certain environments

Sync vs. Async Message Exchange •Asynchronous request/response protocols stream requests from client to server without waiting for responses synchronously •Multiple client requests can be transmitted before any responses arrive from a server •Synchronous request/response protocols are the simplest form to implement •Requests & responses are exchanged in a lock-step sequence. •Each request must receive a response synchronously before the next is sent 5

•These protocols therefore often require a strategy for detecting lost or failed requests & resending them later

Message Passing vs. Shared Memory

• Message passing exchanges data explicitly via the IPC mechanisms

• Shared memory allows multiple processes on the same or different • Application developers generally define the hosts to access & exchange data as though it were local to the address protocol for exchanging the data, e.g.: space of each process • Format & content of the data • Applications using native OS shared • Number of possible participants in each memory mechanisms must define exchange (e.g., point-to-point unicast), how to locate & map the shared multicast, or broadcast) memory region(s) & the data • How participants begin, conduct, & end structures that are placed in shared a message-passing session memory 6

Sidebar: C++ Objects & Shared Memory Allocating a C++ Object in shared Memory void *obj_buf = … // Get a pointer to location in shared memory ABC *abc = new (obj_buf) ABC; // Use C++ placement new operator

• General responsibilities using placement new operator • Pointer passed to placement new operator must point to a memory region that is big enough & is aligned properly for the object type being created • The placed object must be destroyed by explicitly calling the destructor • Pitfalls initializing C++ objects with virtual functions in shared memory • The shared memory region may reside at a different virtual memory location in each process that maps the shared memory • The C++ compiler/linker need not locate the vtable at the same address in different processes that use the shared memory • ACE wrapper façade classes that can be initialized in shared memory must therefore be concrete data types • i.e., classes with only non-virtual methods 7

Related Documents