Understanding SQL*Net
CHAPTER 2. SQL*Net Version 2 Architecture
SQL*Net version 2 uses the Transparent Network Substrate (TNS) and industry-standard network protocols to connect a client to a server and establish an Oracle session.
The next few sections provide a discussion of SQL*Net and the role it plays in distributed systems. The following architectural concepts are discussed:
- Transparent Network Substrate
- distributed processing with SQL*Net
- SQL*Net and the network listener
Transparent Network Substrate (TNS)
Forming the basis for Oracle networking products, the Transparent Network Substrate (TNS) enables Oracle to provide a network of applications above all existing networks of computers. With TNS, peer-to-peer application connectivity is possible where no direct machine-level connectivity exists.In peer-to-peer architecture, two or more nodes 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.
TNS provides two key features to a TNS-based network product and, in turn, any application built using TNS:
- a single, common interface to all industry-standard protocols
- the ability to connect to applications in physically separate networks through one or more MultiProtocol Interchanges
TNS is the foundation component of all current and planned network products from Oracle. Today, TNS networks connect Oracle clients and servers through SQL*Net version 2. In the future, Oracle Corporation will provide additional TNS-based application connectivity tools.
SQL*Net's Communication Role
Communication between client and server proceeds in a stack-like fashion with corresponding levels communicating in a peer relationship. The logical exchange unit at each layer of the stack conveys the level of generalization employed at that level. The Oracle client and server exchange SQL statements and data rows. At the UPI/OPI (User/Oracle Program Interface) layers, these exchanges translate into series of calls to SQL routines such as logon, parse, execute, and fetch. In a distributed transaction, SQL*Net is responsible for sending information across various networks on behalf of a client application or database server. In such a configuration, there are commonly two types of computers acting as the client and server.
Two-Task Common (described ![[*]](jump.gif)
) ensures that all differences between clients and servers, such as internal datatype representations or NLS character sets, are resolved, allowing the client and server to communicate transparently. SQL*Net relays all communication tasks to TNS through its common entry points. SQL*Net is unaffected by the specific communication mechanism used underneath TNS (for example, TCP/IP, DECnet, shared memory, and so on). The SQL*Net layer handles these calls as a series of Oracle send/receive messages, and TNS in turn processes the packets over the network. The network protocol, not provided by Oracle (typically provided with each particular platform by its vendor), supplies a reliable means of communication between the two tasks.
Components Involved in Distributed Processing
Several software components are involved in completing a distributed transaction, whether it is a client-server or server-server transaction. Figure 2 - 1 shows the components of a client-server session. These components are described in the following sections.
Figure 2 - 1. Oracle Client-Server Components
Client-Side Interaction
The following paragraphs discuss the components of the client-server transaction process, beginning with the client application and concluding with the Oracle Server.
Client Application
The client application provides all user-oriented activities, such as character or graphical user display, screen control, data presentation, application flow, and other application specifics. The application identifies any SQL database operations to send to the server database and passes them through the User Program Interface (UPI).
User Program Interface (UPI)
The UPI code contains all 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
The client application uses some combination of these calls to request activity within the server. Often, all UPI 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 UPI calls into a single message to the server. When a call is performed, control is passed to SQL*Net to establish the connection or transmit the request to the server.
Two-Task Common
Two-Task Common provides character set and data type conversion between different character sets or formats between client and server. This layer is optimized to perform conversion only when required on a per connection basis.
At the time of initial connection, SQL*Net version 2 is responsible for evaluating differences in internal data and character set representations and determining whether conversions are required for the two computers to communicate.
SQL*Net
The role of SQL*Net is to establish and maintain a connection between the client application and the server and exchange messages between them. The network listener receives connection requests for a particular database and passes control to the server.
Transparent Network Substrate (TNS)
TNS receives requests from network applications, in this case SQL*Net, and settles all generic machine-level connectivity issues, such as:
- the location of the server or destination (open, close functions)
- whether one or more MultiProtocol Interchanges will be involved in the connection (open, close functions)
- 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 optionally provides encryption and sequenced cryptographic message digests to protect data in transit. See theSecure Network Services Administrator's Guide for more information.
Oracle Protocol Adapter
The 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 requires 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
Going up the process stack on the server side is the reverse of what occurred on the way down the client side. See the right side of Figure 2 - 1.
The one operation unique to the server side is the act of receiving the initial connection. The server has a process (the network listener) that regularly checks for incoming connections and evaluates
their destination.
The network listener is a process on a server that listens for connection requests for one or more databases on one or more protocols. It is discussed in "SQL*Net and the Network Listener" 2 - 9. Based on the Oracle Server ID (SID) specified, the connection is passed to the Oracle Server.
The components above SQL*Net, the OPI and the Oracle Server, are different from those on the client side.
Oracle Program Interface (OPI)
The OPI has a complementary function to that of the UPI. It is responsible for responding to each of the possible messages sent by the UPI. For example, a UPI 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 UPI 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.
Server-to-Server Interaction
When two servers are communicating to complete a distributed transaction, the process and dialogues are the same as in the client-server scenario, except that there is no client application. See Chapter 5, "Distributed Updates" in Oracle7 Server Distributed Systems, Volume I for more information. The server has its own version of UPI, called NPI. The NPI interface can perform all of the functions that the UPI does for clients, allowing a coordinating server to construct SQL requests for additional servers. Figure 2-2 shows a server-to-server connection and all associated layers.
Figure 2 - 2. Oracle Server-Server Components