2
Understanding Net8

Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to connect a client to a server and establish an Oracle session.

This chapter describes TNS and the role it plays in distributed systems. It also explains how Net8 interacts with TNS to perform basic connectivity and transport operations. This chapter contains the following sections:

• Section 2.1, "Net8 Operations"
• Section 2.2, "Connect Operations"
• Section 2.3, "Data Operations"
• Section 2.4, "Exception Operations"
• Section 2.5, "Net8 and the Transparent Network Substrate (TNS)"
• Section 2.6, "Net8 Architecture"

2.1 Net8 Operations

Net8 is responsible for enabling communications between the cooperating partners in an Oracle distributed transaction, whether they be client-server or server-server. Specifically, Net8 provides three basic networking operations:

• Connect Operations
• Data Operations
• Exception Operations

2.2 Connect Operations

Net8 supports two types of connect operations:

• Connecting to Servers (open)
• Disconnecting from Servers (close)

2.2.1 Connecting to Servers

Users initiate a connect request by passing information such as a username and password along with a short name for the database service that they wish to connect. That short name, called a service name, is mapped to a network address contained in a connect descriptor. Depending upon your specific network configuration, this connect descriptor may be stored in one of the following:

• a local names configuration file called TNSNAMES.ORA
• a Names Server for use by Oracle Names
• a native naming service such as NIS or DCE CDS

  Note:: If the network includes Oracle Names, you do not need a local names (TNSNAMES.ORA) configuration file. The service names and associated connect descriptors are stored in a Names Server. Similarly, if an Oracle Native Naming Adapter such as NIS or DCE CDS is being used, this information is stored and retrieved from that native name service.

Net8 coordinates its sessions with the help of a network listener.

2.2.2 Establishing Connections with the Network Listener

The network listener is a single process or task setup specifically to receive connection requests on behalf of an application. Listeners are configured to "listen on" an address specified in a listener configuration file (called LISTENER.ORA) for a database or non-database service. Once started, the listener will receive client connect requests on behalf of a service, and respond in one of three ways:

• Bequeath the session to a new dedicated server process
• Redirect to an existing server process (such as a dispatcher or prestarted dedicated server process)
• Refuse the session

Figure 2-1 depicts the role of the network listener in a typical Net8 connection to a server.

Figure 2-1 Network Listener In a Typical Net8 Connection

2.2.2.1 Bequeathed Sessions to Dedicated Server Processes

If the listener and server exist on the same node, the listener may create or `spawn' dedicated server processes as connect requests are received. Dedicated server processes are committed to one session only and exist for the duration of that session. The sequence of events that occur when the listener creates a dedicated server process and passes or `bequeaths' control of a session to it is as follows:

1. The listener is started and listens on an address specified in a listener configuration file (LISTENER.ORA).
2. A client connects to the listener with the network address.
3. The listener receives the session request, and determines if the client's request may be serviced. If not, the listener refuses the session and then resumes at Step 5.
4. The listener spawns a new dedicated server process to serve the incoming session, and bequeaths the session to that server process. Once the session is established, data flows directly between the client and dedicated server process.
5. The listener continues listening for incoming sessions.

When a client disconnects, the dedicated server process associated with the client closes.

Figure 2-2 depicts the role of the network listener in a bequeathed connection to a dedicated server process.

Figure 2-2 Bequeathed Connection To a Dedicated Server Process

2.2.2.2 Redirected Sessions to Existing Server Processes

Alternatively, Net8 may redirect the request to an existing server process. It does this by sending the address of an existing server process back to the client. The client will then resend its connect request to the server address provided.

Existing server processes include:

• Prestarted or Prespawned Dedicated Server Processes by the listener
• Dispatcher Processes created outside the listener process

2.2.2.2.1 Prespawned Dedicated Server Processes

Net8 provides the option of automatically creating dedicated server processes before the request is received. These processes last for the life of the listener, and can be reused by subsequent connection requests. The use of prespawned dedicated server processes requires specification in a listener configuration file.

Note: : Prespawned dedicated servers require SQL*Net release 2.1 or later, and Oracle Server release 7.1 or later.

The sequence of events that occurs when using prespawned dedicated server processes to service client connection requests is as follows:

1. The listener is started and listens on an address specified in a listener configuration file.
2. The listener then spawns a series of dedicated server processes until it reaches the specified pool size for each Oracle System Identifier (SID) defined in its configuration file.
3. Each spawned server process performs a partial address listen and provides the listener with the partial address that it is listening on. The listener initially marks all prespawned servers as idle.

   Note:: A partial address listen is where the server process listens, but informs the underlying protocol stack that it has no preference as to the specific address it will listen on. As a result, many protocol stacks will choose a free listening address and automatically assign this to the requesting server process.

4. The client sends a connect request to the listener.
5. The listener receives the session request, and determines if the client's request may be serviced. If not, the listener refuses the session and then resumes at Step 9.
6. The listener issues a redirect message to the client containing one of the network addresses of the prespawned servers. The listener logs that server as active.
7. The client dissolves the session to the listener and establishes a session to the prespawned server using the address provided in the redirect message.
8. The listener spawns another server process to replace the active prespawned server (provided a value called PRESPAWN_MAX in the listener configuration file is greater than the number of prespawned server processes active and idle).
9. The listener continues listening for incoming sessions.

The above sequence of events continues until the maximum prespawn limit is reached, at which point the listener stops spawning new dedicated server processes.

When clients disconnect, the prespawned dedicated server process associated with the client returns to the idle pool. It then waits a specified length of time to be assigned to another client. If no client is handed to the prespawned server before the timeout expires, the prespawned server shuts down.

Figure 2-3 depicts the role of the network listener in a redirected connection to a prespawned dedicated server process.

Figure 2-3 Redirected Connection To a Prespawned Dedicated Server Process

2.2.2.2.2 Dispatcher Server Processes

A dispatcher server process enables many clients to connect to the same server without the need for a dedicated server process for each client. It does this with the help of a dispatcher which handles and directs multiple incoming session requests to the shared server.

When an Oracle server has been configured as a multi-threaded server, incoming sessions are always routed to the dispatcher unless either the session specifically requests a dedicated server or no dispatchers are available. The sequence of events that occurs with the dispatcher server is as follows:

1. The listener is started and listens on either a default address or the addresses specified in its configuration file.
2. A database instance starts. Dispatchers start according to the configuration parameters in the initialization parameter file. Each dispatcher then performs a listen on the address assigned to it.
3. Each dispatcher's address is registered. When the listener is not listening on its default address, the listener's network name may be specified in the database initialization file (INIT.ORA). The name may resolve to more than one such address if multiple listeners are used.

   Once the dispatcher addresses are registered, the listener can redirect incoming connect requests to them.

   • If step 2 is performed before step 1, the dispatchers will not be able to contact the listener in step 3. If this occurs, there may be a delay as the dispatcher attempts to connect to the listener. If a connect request comes in a timeframe where no dispatchers are registered, these requests may be handled through prespawned dedicated or newly spawned dedicated server processes or be rejected.

The listener and the Oracle dispatcher server are now ready to receive incoming sessions.

Note: : You can check which dispatchers have registered with the listener by issuing a SERVICES command in the Listener Control Utility. For more information, refer to SERVICES in the LSNRCTL Commands in Appendix A, "Control Utility Reference".

Once the listener and the dispatcher server have been started, the session activity continues as follows:

1. The client connects to the listener with the network address.
2. The listener receives the connect request, and determines if the client's request may be serviced. If not, the listener refuses the session and then resumes at Step 6.
3. The listener issues a redirect message to the client containing the network address of the least-used dispatcher for the shared server.
4. The client dissolves the session to the listener and establishes a session to the shared server using the network address provided in the redirect message.
5. The dispatcher updates the listener with the new load value because of the presence of the new session. This allows the listener to balance the incoming session requests between dispatchers running on the same protocol.
6. The listener resumes listening for incoming sessions.

When clients disconnect, the shared server associated with the client stays active and processes other incoming requests.

Figure 2-4 depicts the role of the network listener in a redirected connection to a dispatcher server process.

Figure 2-4 Redirected Connection To a Dispatcher Server Process

2.2.2.3 Refused Sessions

The network listener will refuse a session in the event that it does not know about the server being requested, or if the server is unavailable. It refuses the session by generating and sending a refuse response packet back to the client.

2.2.3 Disconnecting from Servers

Requests to disconnect from the server can be initiated in the following ways:

• user-initiated disconnect
• additional connection request
• abnormal connection termination
• timer-initiated disconnect

2.2.3.1 User-Initiated Disconnect

A user can request a disconnection from the server when a client-server transaction completes. A server can also disconnect from a second server when all server-server data transfers have been completed, and no need for the link remains.

2.2.3.2 Additional Connection Request

If a client application is connected to a server and requires access to another user account on the same or other server, most Oracle tools will first disconnect the application from the server to which it is currently connected. Once the disconnection is completed, a connection request to the new user account on the appropriate server is initiated.

2.2.3.3 Abnormal Connection Termination

Other components will occasionally disconnect or abort communications without giving notice to Net8. In this event, Net8 will recognize the failure during its next data operation, and clean up client and server operations, effectively disconnecting the current operation.

2.2.3.4 Timer Initiated Disconnect or Dead Connection Detection

Dead connection detection is a feature that allows Net8 to identify connections that have been left hanging by the abnormal termination of a client. On a connection with dead connection detection enabled, a small probe packet is sent from server to client at a user-defined interval (usually several minutes). If the connection is invalid (usually due to the client process or machine being unreachable), the connection will be closed when an error is generated by the send operation, and the server process will terminate the connection.

This feature minimizes the waste of resources by connections that are no longer valid. It also automatically forces a database rollback of uncommitted transactions and locks held by the user of the broken connection.

2.3 Data Operations

Net8 supports four sets of client-server data operations:

• send data synchronously
• receive data synchronously
• send data asynchronously
• receive data asynchronously

On the client side, a SQL dialogue request is forwarded using a send request in Net8. On the server side, Net8 processes a receive request and passes the data to the database. The opposite occurs in the return trip from the server.

Basic send and receive requests are synchronous. When a client initiates a request, it waits for the server to respond with the answer. It can then issue an additional request.

Net8 adds the capability to send and receive data requests asynchronously. This capability was added to support the Oracle shared server, also called a multi-threaded server, which requires asynchronous calls to service incoming requests from multiple clients.

2.4 Exception Operations

Net8 supports three types of exception operations:

• initiate a break over the connection
• reset a connection for synchronization after a break
• test the condition of the connection for incoming break

The user controls only one of these three operations, that is, the initiation of a break. When the user presses the Interrupt key ([Ctrl-C] on some machines), the application calls this function. Additionally, the database can initiate a break to the client if an abnormal operation occurs, such as during an attempt to load a row of invalid data using SQL*Loader.

The other two exception operations are internal to products that use Net8 to resolve network timing issues. Net8 can initiate a test of the communication channel, for example, to see if new data has arrived. The reset function is used to resolve abnormal states, such as getting the connection back in synchronization after a break operation has occurred.

2.5 Net8 and the Transparent Network Substrate (TNS)

Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to accomplish its basic functionality. TNS is a foundation technology that is built into Net8 providing a single, common interface to all industry-standard protocols.

With TNS, peer-to-peer application connectivity is possible where no direct machine-level connectivity exists. 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. In a peer-to-peer system, a node can be both a client and a server.

A review of how Oracle clients and servers operate and communicate with each other will help you to understand what TNS is and how it works with Net8 to establish Oracle sessions.

2.6 Net8 Architecture

Oracle networking environments are based on two concepts:

• Distributed Processing
• Stack Communications

Distributed Processing

Oracle databases and client applications operate in what is known as a distributed processing environment. Distributed or cooperative processing involves interaction between two or more computers to complete a single data transaction. Applications such as an Oracle tool act as clients requesting data to accomplish a specific operation. Database servers store and provide the data.

In a typical network configuration, clients and servers may exist as separate logical entities on separate physical machines. This configuration allows for a division of labor where resources are allocated efficiently between a client workstation and the server machine. Clients normally reside on desktop computers with just enough memory to execute user friendly applications, while a server has more memory, disk storage, and processing power to execute and administer the database.

Distributed Databases

This type of client-server architecture also enables you to distribute databases across a network. A distributed database is a network of databases stored on multiple computers that appears to the user as a single logical database. Distributed database servers are connected by a database link, or path from one database to another. One server uses a database link to query and modify information on a second server as needed, thereby acting as a client to the second server.

2.6.1 Stack Communications

The concept of distributed processing relies on the ability of computers separated by both design and physical location to communicate and interact with each other. This is accomplished through a process known as stack communications.

Stack communications can be explained by referencing the Open System 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. Figure 2-5 depicts a typical OSI Protocol Communications Stack.

Figure 2-5 OSI Communications Stack

Information descends through layers on the client side where it is packaged for transport across a network medium in a manner that it can be translated and understood by corresponding layers on the server side.

A typical OSI protocol communications stack will contain seven such layers:

• Application - this is the OSI layer closest to the user, and as such is dependent on the functionality requested by the user. For example, in a database environment, a Forms application may attempt to initiate communication in order to access data from a server.
• Presentation - ensures that information sent by the application layer of one system is readable by the application layer of another system. This includes keeping track of syntax and semantics of the data transferred between the client and server. If necessary, the presentation layer translates between multiple data representation formats by using a common data format.
• Session - as its name suggests, establishes, manages, and terminates sessions between the client and server. This is a virtual pipe that carries data requests and responses. The session layer manages whether the data traffic can go in both directions at the same time (referred to as asynchronous), or in only one direction at a time (referred to as synchronous).
• Transport - implements the data transport ensuring that the data is transported reliably.
• Network - ensures that the data transport is routed through optimal paths through a series of interconnected subnetworks.
• Link - provides reliable transit of data across a physical link.
• Physical - defines the electrical, mechanical, and procedural specifications for activating, maintaining and deactivating the physical link between client and server.

2.6.2 Stack Communications in an Oracle networking environment

Stack communications allow Oracle clients and servers to share, modify, and manipulate data between themselves. The layers in a typical Oracle communications stack are similar to those of a standard OSI communications stack.

2.6.2.1 Client-Server Interaction

In an Oracle client-server transaction, information passes through the following layers:

• Client Application
• Oracle Call Interface (OCI)
• Two Task Common
• Net8
• Oracle Protocol Adapters
• Network Specific Protocols

Figure 2-6 depicts a typical communications stack in an Oracle networking environment.

Figure 2-6 Typical Communications Stack in an Oracle environment

Client Application

Oracle client applications provide all user-oriented activities, such as character or graphical user display, screen control, data presentation, application flow, and other application specifics. The application identifies database operations to send to the server and passes them through to the Oracle Call Interface (OCI).

Oracle Call Interface (OCI)

The OCI code contains all the information required to initiate a SQL dialogue between the client and the server. It defines calls to the server to:

• parse SQL statements for syntax validation
• open a cursor for the SQL statement
• bind client application variables into the server shared memory
• describe the contents of the fields being returned based on the values in the server's data dictionary
• execute SQL statements within the cursor memory space
• fetch one or more rows of data into the client application
• close the cursor

The client application uses a combination of these calls to request activity within the server. OCI calls can be combined into a single message to the server, or they may be processed one at a time through multiple messages to the server, depending on the nature of the client application. Oracle products attempt to minimize the number of messages sent to the server by combining many OCI calls into a single message to the server. When a call is performed, control is passed to Net8 to establish the connection and transmit the request to the server.

For more information about OCI, refer to the Oracle Call Interface Programmer's Guide.

Two-Task Common

Two-Task Common provides character set and data type conversion between different character sets or formats on the client and server. This layer is optimized to perform conversion only when required on a per connection basis.

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

Net8

Net8 provides all session layer functionality in an Oracle communications stack. It is responsible for establishing and maintaining the connection between a client application and server, as well as exchanging messages between them. Net8 itself has three component layers that facilitate session layer functionality:

• Network Interface (NI) - This layer provides a generic interface for Oracle clients, servers, or external processes to access Net8 functions. The NI handles the "break" and "reset" requests for a connection.
• Network Routing (NR)/ Network Naming (NN)/ Network Authentication (NA) - NR provides routing of the session to the destination. This may include any intermediary destinations or `hops,' on the route to the server destination. NN resolves aliases to a Net8 destination address. NA negotiates any authentication requirement with the destination.
• Transparent Network Substrate (TNS) - TNS is an underlying layer of Net8 providing a common interface to industry standard protocols. TNS receives requests from Net8, and settles all generic machine-level connectivity issues, such as: the location of the server or destination (open, close functions); whether one or more protocols will be involved in the connection (open, close functions); and how to handle interrupts between client and server based on the capabilities of each (send, receive functions). The generic set of TNS functions (open, close, send, receive) passes control to an Oracle Protocol Adapter to make a protocol-specific call. Additionally, TNS supports encryption and sequenced cryptographic message digests to protect data in transit.

Oracle Protocol Adapters

Oracle Protocol Adapters are responsible for mapping TNS functionality to industry-standard protocols used in the client-server connection. Each adapter is responsible for mapping the equivalent functions between TNS and a specific protocol.

Network-Specific Protocols

All Oracle software in the client-server connection process require an existing network protocol stack to make the machine-level connection between the two machines. The network protocol is responsible only for getting the data from the client machine to the server machine, at which point the data is passed to the server-side Oracle Protocol Adapter.

Server-Side Interaction

Information passed from a client application across a network protocol is received by a similar communications stack on the server side. The process stack on the server side is the reverse of what occurred on the client side with information ascending through communication layers. The one operation unique to the server side is the act of receiving the initial connection through the network listener.

The following components above the Net8 session layer are different from those on the client side:

• Oracle Program Interface (OPI)
• Oracle Server

Oracle Program Interface (OPI)

The OPI performs a complementary function to that of the OCI. It is responsible for responding to each of the possible messages sent by the OCI. For example, an OCI request to fetch 25 rows would have an OPI response to return the 25 rows once they have been fetched.

Oracle Server

The Oracle Server side of the connection is responsible for receiving dialog requests from the client OCI code and resolving SQL statements on behalf of the client application. Once received, a request is processed and the resulting data is passed to the OPI for responses to be formatted and returned to the client application.

2.6.3 Server-to-Server Interaction

When two servers communicate to complete a distributed transaction, the process, layers, and dialogues are the same as in the client-server scenario, except that there is no client application. The server has its own version of OCI, called the Network Program Interface (NPI). The NPI interface performs all of the functions that the OCI does for clients, allowing a coordinating server to construct SQL requests for additional servers.

---