| Lesson 17 | Configuring Multiple Protocol Endpoints on the Same Server |
| Objective | Configure one Oracle Net listener with TCP, TCPS, and IPC endpoints on the same Oracle 23ai server node in Oracle Cloud Infrastructure. |
This lesson is best understood as a modern Oracle Net architecture topic, not as an older Multi-Threaded Server discussion. In Oracle 23ai on a self-managed Oracle Cloud Infrastructure compute node, a single Oracle Net listener can expose multiple protocol endpoints on the same server. The most practical combination is usually standard TCP for ordinary Oracle Net client connectivity, TCPS for encrypted secure connectivity, and IPC for local same-host communication.
The key modernization is this: you do not usually need three completely separate listener processes just because you want three types of connectivity. In most deployments, Oracle Net can handle this through one listener process with multiple ADDRESS entries in listener.ora. That design is cleaner, easier to manage, and more consistent with how modern Oracle networking is typically configured on OCI.
This lesson therefore explains how to configure a single listener with multiple protocol addresses, how OCI networking affects which ports are reachable, why TCPS needs wallet-based TLS configuration, and why IPC is mainly for local same-host communication rather than remote client access.
When people say “multiple protocol listeners on the same node,” the phrase can be misleading. In older discussions it might sound as though each protocol requires its own independent listener process. In Oracle 23ai, the more accurate picture is usually one listener definition exposing multiple protocol endpoints on the same host.
For this lesson, the three relevant protocol types are:
These are not equal in purpose. TCP and TCPS are the major network-facing endpoints that clients care about. IPC is primarily local to the server and is useful for same-host Oracle communication or administrative interaction that does not need to traverse the network stack.
TCP remains the standard Oracle Net transport for ordinary client connections. In a self-managed OCI deployment, this is often the endpoint used by internal application servers, legacy-compatible clients, or systems operating inside a controlled private network.
The conventional listener port is:
TCP : 1521
That does not mean 1521 is mandatory, but it remains the default port most administrators and client tools expect. In modern OCI environments, TCP is often acceptable for trusted internal connectivity, although many deployments increasingly prefer encrypted traffic for all external or regulated access.
TCPS is the secure variant of TCP and is used when listener traffic must be protected with TLS. In Oracle 23ai, this is the modern protocol to emphasize whenever the listener is exposed beyond a tightly controlled internal network or when security policy requires encrypted transport.
A typical TCPS listener endpoint uses a port such as:
TCPS : 2484
Unlike plain TCP, TCPS requires wallet-based certificate material. That is why the diagram correctly associates the TCPS path with WALLET_LOCATION and Oracle Wallet / TLS configuration. If the wallet is missing, misconfigured, or the certificate chain is not trusted, the TCPS endpoint may exist in theory but will not work correctly in practice.
In OCI, TCPS is especially important because network exposure and security boundaries matter more. OCI security lists or network security groups must allow the TCPS port, and the listener must be configured to reference the correct wallet location.
IPC, or Inter-Process Communication, is different from TCP and TCPS because it is not primarily about remote client networking. IPC is most relevant for same-host Oracle interaction, where local processes communicate without using the normal network path.
That makes IPC useful for local administrative or Oracle-internal communication scenarios, but it should not be treated as the equal remote-access counterpart of TCP or TCPS. For the purposes of this lesson, IPC belongs in the architecture because it shows that one listener definition can include a local communication path as well as network-based paths.
Because this lesson is framed around Oracle 23ai running on OCI, listener configuration cannot be separated from OCI networking. Even if listener.ora is perfectly written, the listener still depends on the surrounding VCN, subnet design, and OCI admission controls.
At a minimum, the OCI environment should be reviewed for:
This is why the lesson should not read like an old on-premises Oracle Net page that ignores the network layer around the server. In OCI, the listener is only one part of the connectivity design. The cloud network must also allow the intended traffic.
The central Oracle Net configuration file for this lesson is listener.ora. In a modern multi-protocol design, the listener uses multiple ADDRESS entries rather than separate operating-system listener processes for every protocol.
A simplified example looks like this:
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dbserver1.example.com)(PORT = 1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCPS)(HOST = dbserver1.example.com)(PORT = 2484))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
SSL_CLIENT_AUTHENTICATION = FALSE
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /u01/app/oracle/admin/wallet)
)
)
This structure expresses the main lesson clearly. One listener definition can accept more than one protocol address. TCP and TCPS use different ports because they are different network endpoints. IPC uses a local key-based endpoint rather than a normal network port.
In Oracle 23ai, dynamic service registration should normally be preferred over static SID_LIST entries unless there is a very specific reason to use static registration. The database instance can register its services automatically with the listener through the LOCAL_LISTENER parameter.
That is why the diagram correctly shows dynamic service registration flowing from the Oracle Database 23ai instance toward the Oracle Net listener. In a well-configured self-managed environment, the listener does not need a heavy static SID_LIST_LISTENER definition just to advertise ordinary database services.
A simplified example is:
ALTER SYSTEM SET LOCAL_LISTENER =
'(ADDRESS=(PROTOCOL=TCP)(HOST=dbserver1.example.com)(PORT=1521))'
SCOPE=BOTH;
Depending on the design, additional listener address logic may be referenced through a TNS alias, but the important principle is that service registration should be dynamic whenever possible.
Because TCPS is part of the lesson, the rewrite must acknowledge that listener.ora is not the only relevant file. A broader Oracle Net security configuration may also require settings in sqlnet.ora, especially when TLS behavior and wallet usage are part of the server-side design.
A simplified server-side example is:
SQLNET.AUTHENTICATION_SERVICES = (NONE)
SSL_VERSION = 1.2
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /u01/app/oracle/admin/wallet)
)
)
The exact cipher and TLS settings depend on the security policy and client capabilities, but the architectural point remains the same: TCPS is not just another port number. It is a wallet-backed secure endpoint.
On the client side, separate aliases can be used for TCP and TCPS so that different connection paths are explicit and easy to test. That makes it possible to direct ordinary internal application traffic to TCP while reserving encrypted access for clients that require TCPS.
ORCL_TCP =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dbserver1.example.com)(PORT = 1521))
(CONNECT_DATA = (SERVICE_NAME = orclpdb1.example.com))
)
ORCL_TCPS =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCPS)(HOST = dbserver1.example.com)(PORT = 2484))
(CONNECT_DATA = (SERVICE_NAME = orclpdb1.example.com))
(SECURITY = (SSL_SERVER_CERT_DN = "CN=dbserver1.example.com"))
)
This reinforces the main lesson objective: TCP and TCPS can coexist on the same node, but they serve different security and deployment needs.
Oracle Net can support multiple separate named listeners if you truly need them. For example, you could define LISTENER_TCP and LISTENER_TCPS separately and start them independently. However, that is not the main lesson to emphasize here.
The more efficient and more modern explanation is that Oracle 23ai on a self-managed OCI node can usually support the required architecture through one listener process with multiple protocol addresses. That is simpler to manage and matches the diagram you selected for Lesson 17.
This lesson applies to a self-managed Oracle 23ai database on OCI compute. Autonomous Database is different because Oracle manages the listener layer for you. Administrators do not normally edit listener.ora directly in Autonomous Database, so the step-by-step listener endpoint configuration described here is not the normal Autonomous model.
That distinction matters because it keeps the lesson technically accurate. This is an Oracle Net administration lesson for self-managed OCI infrastructure, not a generic OCI database lesson.
Configuring multiple protocol endpoints on the same Oracle 23ai server in OCI is best understood as configuring one Oracle Net listener with multiple addresses, not as launching three unrelated listeners. In practice, TCP supports standard client connectivity, TCPS supports encrypted secure connectivity, and IPC supports local same-host communication.
The lesson also shows why modern Oracle networking must be explained together with OCI controls. The listener definition, wallet-based TLS configuration, dynamic service registration, and OCI port admission rules all work together. Once that architecture is clear, the purpose of the diagram and the lesson objective become much easier to understand.