Skip Headers

Oracle9i Net Services Administrator's Guide
Release 2 (9.2)

Part Number A96580-02
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page

Go to previous page Go to next page
View PDF

Architecture of Oracle Net Services

This chapter describes the architecture of Oracle Net, the listener, shared server, dedicated server, and Oracle Connection Manager.

This chapter contains these topics:

Oracle Net Stack Communication Architecture

The primary function of Oracle Net is to establish and maintain connections between a client application and an Oracle database server. Oracle Net is comprised of several communication layers that enable clients and database servers to share, modify, and manipulate data.

This section contains these topics:

Stack Communication for Client/Server Application Connections

Figure 4-1 illustrates the various layers on the client and on the database server after a connection has been established.

Figure 4-1 Layers Used in a Client/Server Application Connection

Text description of net81099.gif follows
Text description of the illustration net81099.gif

This communication architecture is based on the Open Systems Interconnection (OSI) model. In the OSI model, communication between separate computers occurs in a stack-like fashion with information passing from one node to the other through several layers of code, including:

1. Physical layer

2. Data link layer

3. Network layer

4. Transport layer 

5. Session layer

6. Presentation layer

7. Application layer

Figure 4-2 shows how Oracle Net software--Oracle Net Foundation layer and Oracle Protocol Support--fits into the Session layer of the OSI model.

Figure 4-2 OSI Communication Layers

Text description of net81100.gif follows
Text description of the illustration net81100.gif

See Also: for information about the OSI stack

As shown in Figure 4-1, the client/server stack is comprised of the following:

Client Application

During a session with the database, the client uses Oracle Call Interface (OCI) to interact with the database server. OCI is a software component that provides an interface between the client application and the SQL language the database server understands.

See Also:

Oracle Call Interface Programmer's Guide


Character set differences can occur if the client and database server are running on different operating systems. The presentation layer resolves any differences. It is optimized for each connection to perform conversion only when required.

The presentation layer used by client/server applications is Two-Task Common (TTC). TTC provides character set and data type conversion between different character sets or formats on the client and database server.

At the time of initial connection, TTC is responsible for evaluating differences in internal data and character set representations and determining whether conversions are required for the two computers to communicate.

Oracle Net Foundation Layer

The Oracle Net foundation layer is responsible for establishing and maintaining the connection between the client application and database server, as well as exchanging messages between them. The Oracle Net foundation layer is able to perform these tasks because of a technology called Transparent Network Substrate (TNS). TNS provides a single, common interface functioning over all industry-standard protocols. In other words, TNS enables peer-to-peer application connectivity. In a peer-to-peer architecture, two or more computers (called nodes when they are employed in a networking environment) can communicate with each other directly, without the need for any intermediary devices.

On the client side, the Oracle Net foundation layer receives client application requests and resolves all generic computer-level connectivity issues, such as:

On the server side, the Oracle Net foundation layer performs the same tasks as it does on the client side and also works with the listener to receive incoming connection requests.

In addition to establishing and maintaining connections, the Oracle Net foundation layer communicates with naming methods to resolve names and uses security services to ensure secure connections.

Oracle Protocol Support

Positioned between the Oracle Net foundation layer and the network protocol layer, the Oracle protocol support layer is responsible for mapping TNS functionality to industry-standard protocols used in the client/server connection. This layer supports the following network protocols:

Network Protocol

All Oracle software in the client/server connection process requires an existing network protocol stack to establish the computer-level connection between the two computers for the transport layer. The network protocol is responsible for transporting data from the client computer to the database server computer, at which point the data is passed to the serverside Oracle protocol support layer.

TCP/IP Protocol

The Transmission Control Protocol/Internet Protocol (TCP/IP) is the de facto standard communication protocol used for client/server conversation over a network.

TCP/IP with SSL Protocol

The TCP/IP with Secure Sockets Layer (SSL) protocol enables an Oracle application on a client to communicate with remote Oracle databases through TCP/IP and SSL. Oracle Advanced Security is required in order to use TCP/IP with SSL.

SSL stores authentication data, such as certificates and private keys, in an Oracle Wallet. When the client initiates a connection to the database server, SSL performs a handshake between the two using the certificate. During the handshake, the following processes occur:

The database server checks the user's certificate to verify that it bears the certificate authority's signature.

See Also:

Oracle Advanced Security Administrator's Guide

Named Pipes Protocol

The Named Pipes protocol is a high-level interface providing interprocess communications between clients and database servers using distributed applications. One severside process creates the pipe, and the other clientside process opens it by name. What one side writes, the other can read, and vice versa. Named Pipes is specifically designed for PC LAN environments.

Named Pipes enables client/server conversation over a network using Named Pipes. This combination of Oracle products enables an Oracle application on a client to communicate with remote Oracle databases through Named Pipes (if the Oracle database is running on a host system that supports network communication using Named Pipes).


Information passed from a client application across a network protocol is received by a similar communications stack on the database server side. The process flow on the database server side is the reverse of the process flow on the client side, with information ascending through the communication layers.

Instead of OCI, the database server uses Oracle Program Interface (OPI). For each statement sent from OCI, OPI provides a response. For example, an OCI request to fetch 25 rows would elicit an OPI response to return the 25 rows once they have been fetched.

Stack Communication for Java Application Connections

The Oracle Java Database Connectivity (JDBC) Drivers provide Java applications access to an Oracle database. Oracle offers two JDBC drivers.

Figure 4-3 shows the stack communication layers used by JDBC drivers.

Figure 4-3 Layers Used for Java-Client Applications

Text description of net81101.gif follows
Text description of the illustration net81101.gif

The JDBC OCI driver uses a communication stack similar to a standard client/server communication stack. The JDBC Thin driver uses a Java implementation of the Oracle Net foundation layer called JavaNet and a Java implementation of TTC called JavaTTC.

See Also:

Oracle9i JDBC Developer's Guide and Reference

Stack Communication for Web Client Connections

In addition to the TTC presentation, the Oracle database server supports many other presentations that can be used for Web clients accessing features inside the database. The listener facilitates this by supporting any presentation requested by the database.

For example, Figure 4-4 shows the stack communication layers used in an HTTP or FTP connection to Oracle XML DB in the Oracle9i instance. WebDAV connections use the same stack communication layers as HTTP and FTP.

Figure 4-4 Layers Used in Web Client Connections

Text description of net81102.gif follows
Text description of the illustration net81102.gif

See Also:

Oracle9i XML Database Developer's Guide - Oracle XML DB

Listener Architecture

The database server receives an initial connection from a client application through the listener. The listener is an application positioned on top of the Oracle Net foundation layer. Figure 4-5 illustrates the various layers on the client and database server during an initial connection.

Figure 4-5 Layers Used in an Initial Connection

Text description of net81103.gif follows
Text description of the illustration net81103.gif

The listener brokers client requests, handing off the requests to the Oracle database server. Every time a client requests a network session with a database server, a listener receives the initial request.

Each listener is configured with one or more protocol addresses that specify its listening endpoints. Clients configured with one of these protocol addresses can send connection requests to the listener.

Once a client request has reached the listener, the listener selects an appropriate service handler to service the client's request and forwards the client's request to it. The listener determines if a database service and its service handlers are available through service registration. During service registration, the PMON process--an instance background process--provides the listener with information about the following:

This information enables the listener to direct a client's request appropriately Figure 4-6 shows instances registering information with listeners. Note that it does not represent all the information that can be registered.

Figure 4-6 Service Registration

Text description of net81035.gif follows
Text description of the illustration net81035.gif

Optionally, listening endpoints--port numbers--can be dynamically registered with the listener. For example, with Oracle XML DB, HTTP, FTP, and WebDAV listening endpoints are registered with the listener.

If the listener is not running when an instance starts, PMON is not able to register the service information. PMON attempts to connect to the listener periodically, however, it may take up to 60 seconds before PMON registers with the listener after it has been started. To initiate service registration immediately after the listener is started, use the SQL statement ALTER SYSTEM REGISTER. This is especially useful in high-availability configurations.

If a listener receives an incoming request before the respective instance has been registered, the listener rejects the request.

Figure 4-7 shows the role of a listener during connection establishment with a browser making an HTTP connection and a client making a TTC connection:

  1. The database registers information about the services, instances, and service handlers with the listener.
  2. The client makes an initial connection with the listener.
  3. The listener parses the client request and forwards it to the service handler for the database service requested.

    See Also:

Figure 4-7 Listener Architecture

Text description of net81108.gif follows
Text description of the illustration net81108.gif

Database Server Process Architecture

Based on the service handler type registered with the listener, the listener forwards requests to either a shared server or dedicated server process.

Shared Server Processes

Shared server processes are utilized in the shared server architecture. Figure 4-8 depicts a shared server architecture. With shared server architectures, client processes ultimately connect to a dispatcher. The PMON process registers the location and load of the dispatchers with the listener, enabling the listener to forward requests to the least loaded dispatcher.

A dispatcher can support multiple client connections concurrently. Each client connection is bound to a virtual circuit. A virtual circuit is a piece of shared memory used by the dispatcher for client database connection requests and replies. The dispatcher places a virtual circuit on a common queue when a request arrives. An idle shared server picks up the virtual circuit from the common queue, services the request, and relinquishes the virtual circuit before attempting to retrieve another virtual circuit from the common queue. This approach enables a small pool of server processes to serve a large number of clients.

Figure 4-8 Shared Server Architecture

Text description of net81116.gif follows
Text description of the illustration net81116.gif

Dedicated Server Processes

Figure 4-9 depicts a dedicated server architecture. With a dedicated server architecture, each client process connects to a dedicated server process. The server process is not shared by any other client.

PMON registers information about dedicated server processes with the listener. This enables the listener to start up a dedicated server process when a client request arrives and forward the request to it.


Dedicated server architectures do not support HTTP, FTP, or WebDAV clients. Only TTC clients are supported.

Figure 4-9 Dedicated Server Architecture

Text description of net81115.gif follows
Text description of the illustration net81115.gif

Oracle Connection Manager Architecture

Oracle Connection Manager is a router through which a client connection request may be sent either to its next hop or directly to the database server. Clients who route connection requests through an Oracle Connection Manager can take advantage of the connection multiplexing, access control, and protocol conversion features configured on that Oracle Connection Manager.

Oracle Connection Manager has two processes:

The CMGW gateway process receives client connections and evaluates against a set of rules whether to deny or allow access. If access is allowed, the gateway process forwards the requests to the next hop, typically the database server. In addition to allowing or denying access, the CMGW process can also multiplex or funnel multiple client connections through a single protocol connection.

The CMGW process registers with the CMADMIN administrative process. CMADMIN is a multi-threaded process that is responsible for all administrative functions of Oracle Connection Manager.


On Windows NT, the gateway process is represented by the OracleHOME_NAMECMan service, and the administrative process is represented by the OracleHOME_NAMECMAdmin service.

Table 4-1 describes the detailed responsibilities of the CMGW and CMADMIN processes.

Table 4-1  Oracle Connection Manager Processes
Process/Service Description

CMGW process on UNIX

OracleHOME_NAMECMan service on Windows NT

The CMGW process is responsible for the following tasks:

  • Registering with the CMADMIN process
  • Listening for incoming connection requests

    By default it listens on TCP/IP with port 1630.

  • Initiating connection requests to listeners for clients
  • Relaying data between the client and database server

CMADMIN process on UNIX

OracleHOME_NAMECMAdmin service on Windows NT

The CMADMIN process is responsible for the following tasks:

  • Processing the CMGW registration
  • Identifying all listeners serving at least one database instance
  • Registering source route address information about the CMGW process and listeners
  • Answering requests initiated by the Oracle Connection Manager Control utility

Figure 4-10 shows the CMGW process registering with the CMADMIN process and the CMGW process handling client requests. Notice that the CMGW process has denied access to the fourth client. The three client connections are then multiplexed through a single network protocol connection to the database.

Figure 4-10 Oracle Connection Manager Architecture

Text description of netag128.gif follows
Text description of the illustration netag128.gif

A Complete Architecture

Oracle Net provides an architectural solution that allows for greater scalability in Internet and intranet environments.

Figure 4-11 shows how multiple connections to an Oracle database server are made more scalable with Oracle Connection Manager and a shared server architecture. Oracle Connection Manager is used to offload some of the network I/O of the application Web servers, and shared server is used to serve more concurrent users.

Figure 4-11 Scalable Architectural Solutions

Text description of net81113.gif follows
Text description of the illustration net81113.gif