Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
3Activity
0 of .
Results for:
No results containing your search query
P. 1
Accept Or

Accept Or

Ratings: (0)|Views: 41 |Likes:
Published by newtonapples

More info:

Published by: newtonapples on Mar 12, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/11/2010

pdf

text

original

 
Acceptor
A Design Pattern for PassivelyInitializing Network Services
Douglas C. Schmidtschmidt@cs.wustl.edu
Department of Computer ScienceWashingtonUniversitySt. Louis, MO 63130, USA(314) 935-7538This paper appeared in the November/December issue of the C++ Report magazine.
1 Introduction
Thisarticleispartofacontinuingseriesthatdescribesobject-oriented techniques for developing reusable, extensible, andefficient communication software. The current topic exam-ines the
Acceptor 
pattern. This design pattern enables thetasksperformedbynetworkservices toevolveindependentlyof the strategies used to
passively
initialize the services. Bydecouplingservice
initialization
fromservice
 processing
,thispattern enables the creation of reusable, extensible, and ef-ficient network services. When used in conjunction withrelated patterns like the Reactor [1] and the Connector [2],this pattern enables the creation of highly extensible and ef-ficient communication software frameworks [3].A companion article [2] examines the Connector pattern,which is the “dual” of the Acceptor pattern. The Connectorpattern decouples the active establishment of a connectionfrom the service performed once the connection is estab-lished. Although these two patterns address similar forcesthey are described separately since their structure differssomewhat due to the asymmetry of connection establish-ment protocols. In addition,the Connectorpattern addressesadditional forces by using asynchrony to actively establishconnections with a large number of peers efficiently.This article is organized as follows: Section 2 describesthe two primary connection roles (active and passive) usedto establish connections and explains how these roles canbe decoupled from the communication roles performed onceconnections are established; Section 3 motivates the Accep-tor pattern by applying it to a connection-oriented, multi-service, application-level
Gateway
; Section 4 describes theAcceptor pattern in detail and illustrates how to implementit flexibly and efficiently by combining existing design pat-terns [4] and C++ language features, and Section 5 presentsconcluding remarks.
2 Background
SERVERCLIENT
socket()bind()connect()send()/recv()socket()bind()listen()accept()send()/recv()
1:
PASSIVE ROLE
2:
ACTIVE ROLE
 NETWORK
3:
SERVICE PROCESSING
Figure 1: Active and Passive ConnectionrolesConnection-orientedprotocols(suchasTCP, SPX,orTP4)reliablydeliver data between two or more endpointsof com-munication. Establishing connections between endpointsin-volves the followingtwo roles:
 
Passive role
– which initializes an endpoint of commu-nication at a particular address and waits passively forthe other endpoint(s) to connect with it;
 
 Activerole
whichactivelyinitiatesaconnectiontooneor more endpoints that are playing the passive role.Figure1 illustrateshow these connectionroles behave andinteract when a connection is established between an activeclientandapassiveserverusingthesocket networkprogram-minginterface [5]and the TCP transport protocol[6]. In thisfigure the server plays the passive role and the client playsthe active role.
1
One goal of the Acceptor and Connector patterns is to de-couple the passive and active connection roles, respectively,fromtheservicesperformedonceaconnectionisestablished.
1
It is importantto recognizethattraditionaldistinctionsbetween“client”and “server” refer to
communication
roles, not necessarily to
connection
roles. Althoughclients oftentake the activerole in establishingconnectionswith a passive server these connection roles can be reversed, as shown inSection 3.
1
 
These patterns are motivated by observing that the serviceprocessing performed on messages exchanged between con-nected endpoints is largely independent of the following:
 
Which endpoint initiated the connection
– connectionestablishment is inherently asymmetrical since the pas-sive endpoint
waits
and the active endpoint
initiates
theconnection. Once the connection is established, how-ever, data may be transferred between services at theendpoints in any manner that obeys the application’scommunication protocol (
e.g.,
peer-to-peer, request-response, oneway streaming, etc.). This is illustratedin Figure 1 by the peer-to-peer
send/recv
commu-nication between client and server once a connection isestablished.
 
The network programming interfaces and underlying protocols used to establish the connection
– differentnetwork programming interfaces (such as sockets [7]or TLI [8]) provide different library calls to establishconnections using various underlying transport proto-cols (such as TCP, TP4, or SPX). Once a connectionis established, however, data may be transferred be-tween endpoints using standard
read
 / 
write
systemcalls that obey the protocols used to communicate be-tween separate endpoints in a distributedapplication.
 
The creation, connection, and concurrency strategiesusedtoinitializeandexecutetheservice
theprocessingtasks performed by a service typically do not dependon the strategies used to create a service, connect theservice to one or more peers, and execute the service inoneor morethreads orprocesses. Explicitlydecouplingthese initialization strategies from the service behavioritself increases the potential for reusing and extendingthe service in different environments.
3 Motivation
To illustrate the Acceptor and Connector patterns, considerthe multi-service, application-level
Gateway
shown inFig-ure 2. This
Gateway
routes several types of data (such asstatus information, bulk data, and commands) between ser-vices runningon
Peers
located throughouta wide area andlocal area network. The
Gateway
routes several types of data (such as status information, bulk data, and commands)that are exchanged between services runningon the
Peers
.These
Peers
are located throughout local area networks(LANs) and wide-area networks (WANs) and are used tomonitor and control a satellite constellation.The
Gateway
is a Mediator [4] that coordinates interac-tions between its connected
Peers
. From the
Gateway
’sperspective, these
Peer
services differ solely by their mes-sage framingformatsandpayloadtypes. The
Gateway
usesa connection-oriented interprocess communication (IPC)mechanism (such as TCP) to transmit data between its con-nected
Peers
. Using a connection-oriented protocol sim-
WIDE AREANETWORK
SATELLITES
TRACKING STATION PEERS
 STATUS INFOCOMMANDS BULK DATATRANSFER
LOCAL AREA NETWORK
GROUND STATION PEERS
GATEWAY
Figure2: AConnection-oriented,Multi-serviceApplication-level Gatewayplifies application error handling and enhances performanceover long-delay WANs.Each communication service in the
Peers
sends and re-ceives status information, bulk data, and commands to andfrom the
Gateway
using separate TCP connections. Eachconnection is bound to a unique address (
e.g.,
an IP addressandportnumber). Forexample, bulkdatasent fromagroundstation
Peer
throughthe
Gateway
is connected to a differ-entportthanstatusinformationsent byatrackingstationpeerthrough the
Gateway
to a ground station
Peer
. Separat-ing connections in this manner allows more flexible routingstrategies and more robust error handling when connectionsfail.One way to design the
Peers
and
Gateway
is to des-ignate the connection roles
a priori
. For instance, the
Gateway
could be hard-coded to actively initiate the con-nections for all its services. To accomplish this, it coulditerate through a list of 
Peers
and synchronously connectwith each of them. Likewise,
Peers
could be hard-codedto passively accept the connections and initialize their ser-vices. Moreover, the active and passive connection codefor the
Gateway
and
Peers
, respectively, could be imple-mented with conventional network programming interfaces(such as sockets or TLI). In this case, a
Peer
could call
socket, bind, listen,
and
accept
to initialize apassive-mode listener socket and the
Gateway
could call
socket
and
connect
toactivelyinitiatea data-mode con-nection socket. Once the connections were established, the
Gateway
could route data for each type of service it pro-2
 
vided.However, the approach outlined above has several draw-backs:
 
 Limited extensibility and reuse
of the
Gateway
and
Peer
software. For example, the type of routing ser-vice (
e.g.,
status information, bulk data, or commands)performedbythe
Gateway
isindependentofthemech-anisms used to establish the connection. Moreover,these services tend to change more frequently than theconnectionmechanisms. Therefore, tightlycouplingthesoftwarethatimplementsconnectionestablishmentwiththe software that implements the service makes it hardto reuse existing services or to extend the
Gateway
by adding new routing services and enhancing existingservices.
 
 Error-prone network programming interfaces
– low-level network programming (such as sockets or TLI)do not provide adequate type-checking since they uti-lize low-level I/O handles [9]. It is surprisinglyeasy toaccidentally misuse these interfaces in ways that cannotbe detected until run-time.
 
 Lack of scalability
– If there are a large number of 
Peers
thesynchronousconnectionestablishmentstrat-egy of the
Gateway
will not take advantage of theparallelism inherent in the network and
Peers
.Therefore, a more flexible and efficient way to design the
Peers
and
Gateway
is to use the
Acceptor 
and
Connector 
patterns. These patterns resolve the following forces fornetwork clients and servers that explicitly use connection-oriented communication protocols:
 
 How to enable flexible strategies for executing network services concurrently
Once a connection is estab-lished,peer applicationsuse theconnectiontoexchangedata to perform some type of service (
e.g.,
remote lo-gin, WWW HTML document transfer, etc.). However,a service can run in a single-thread, in multiplethreads,or multipleprocesses, regardless of how the connectionwas established.
 
 How to reuse existing initialization code for each newservice
– The Connector and Acceptor patterns permitkey characteristics of services (such as the application-levelcommunicationprotocolanddataformat)toevolveindependentlyandtransparentlyfromthestrategiesusedto initialize the services. Since service characteristicstendtochangemorefrequentlythaninitializationstrate-gies this separation of concerns helps reduce softwarecoupling and increases code reuse.
 
 Howtoactivelyestablishconnectionswithlargenumbeof peers efficiently
– The Connector pattern can employasynchrony to initiate and complete multiple connec-tions in non-blocking mode. By using asynchrony, theConnectorpatternenablesapplicationstoactivelyestab-lishconnectionswitha largenumber ofpeers efficientlyover long-delay WANs.
 
 How to make the connection establishment code portable across platforms that contain different net-work programming interfaces
– This is important forasynchronous connection establishment, which is hardtoprogramportablyandcorrectlyusinglower-levelnet-workprogramminginterfaces(suchassocketsandTLI).Likewise, parameterizingthemechanisms foracceptingconnections and performing services helps to improveportability by allowing the wholesale replacement of these mechanisms. This makes the connection estab-lishmentcodeportableacrossplatformsthatcontaindif-ferent networkprogramminginterfaces(such as socketsbut not TLI, or vice versa).
 
 How to ensure that a passive-mode I/O handle is not accidentally used to read or write data
– By stronglydecoupling the
Acceptor
from the
Svc Handler
passive-mode listener endpoints cannot accidentally beused incorrectly (
e.g.,
to try to read or write data ona passive-mode listener socket used to accept connec-tions).Section 4 describes the Acceptor pattern in detail. TheConnector pattern is described in [2].
4 The Acceptor Pattern
4.1 Intent
Decouples the passive initialization of a service from thetasks performed once a service is initialized.
4.2 Also Known As
Listener
4.3 Applicability
Use the Acceptor pattern when connection-orientedapplica-tions have the followingcharacteristics:
 
The behavior of a network service does not depend onthe steps required to passively initialize a service;
 
Connections may arrive concurrently from differentpeers, but blocking or continuous polling for incomingconnections on any individual peer is inefficient.
4.4 Structure and Participants
The structure of the participants in the Acceptor pattern isillustrated by the Booch class diagram [10] in Figure 3 anddescribed below:
2
 
Reactor
2
In this diagram dashed clouds indicate classes; dashed boxes in theclouds indicate template parameters; and a solid undirected edge with ahollow circle at one end indicates a uses relation between two classes.
3

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->