Oracle Listener Protocols

 Oracle Listener Protocols : 

BEQUEATH, IPC, TCP, TCPS, SDP and what changed in Oracle 26ai

When we talk about Oracle connectivity, we usually reduce everything to “the listener” and “port 1521”. But Oracle actually supports multiple connection protocols, each optimized for a different use case, performance, security, locality, or scale.

Understanding these protocols helps you design systems that are faster, safer, and easier to operate.

🔹 BEQUEATH (BEQ) — direct local attach

BEQUEATH is a local-only protocol that allows a client process to attach directly to a database server process without using the listener or the network.

Typical use:

• Local SQL*Plus

• Local RMAN

• DBA maintenance

• New in Oracle 26ai: JDBC Thin on Linux for local apps (wait for next post about this feature)

Characteristics:

• No listener

• No network

• Very fast

• Very secure

• Same host only

In Oracle 26ai, BEQ became available for JDBC Thin ; allowing Java applications running on the database host to avoid TCP and connect locally.

🔹 IPC — local communication through the listener

IPC is also local-only, but it still goes through the listener. It uses OS shared memory or pipes instead of the network.

Used for:

• Local scripts

• RMAN via listener

• External procedures (extproc)

Characteristics:

• Listener involved

• Local only

• Fast

• Isolated from network

🔹 TCP — standard network connectivity

TCP is the default protocol for remote access and distributed systems.

Used for:

• Application servers

• JDBC / ODP.NET

• Microservices

• RAC and Data Guard

Characteristics:

• Network based

• Flexible and universal

• Slightly higher latency

• Firewall-controlled

🔹 TCPS — encrypted TCP

TCPS is TCP with SSL/TLS encryption.

Used for:

• Regulated environments

• Zero-trust networks

• Internet-facing systems

🔹 SDP — ultra-low latency networking

Oracle Net Services provides support for the Sockets Direct Protocol (SDP) for InfiniBand high-speed networks.  

SDP is a standard communication protocol for clustered server environments. SDP is an interface between a network interface card and the application. By using SDP, applications place most of the messaging burden upon the network interface card, freeing the CPU for other tasks. As a result, SDP decreases network latency and CPU utilization. 

SDP is designed specifically for System Area Networks (SANs). A SAN is characterized by short-distance, high-performance communications between multiple server systems, such as Oracle WebLogic Server or any other third-party middle-tier client and database servers clustered on one switch.

When used over an InfiniBand network, SDP reduces TCP/IP overhead by eliminating intermediate replication of data and transferring most of the messaging burden away from the CPU and onto the network hardware.

SDP is used in high-performance environments using RDMA / InfiniBand.

Used for:

• HPC clusters

• Trading platforms

• Ultra-low latency systems

Another method to connection:

🔹Named Pipes Protocol

The Named Pipes protocol is a high-level interface providing interprocess communications between clients and database servers using distributed applications.

Named Pipes is specifically designed for Microsoft Windows LAN environments. 

One server-side process creates a named pipe, and the client-side process opens it by name. What one side writes, the other can read. 

If a remote Oracle database is running on a host system that supports network communication using Named Pipes, then Oracle Net enables applications on a client to communicate with the Oracle database using Named Pipes.

🔹Exadirect Protocol

The Exadirect protocol is an innovative protocol for low overhead database access. Use the new transport to improve latency and throughput by leveraging Remote Direct Memory Access (RDMA) in an InfiniBand environment.

Exadirect protocol uses TCP for control communication and IB RC transport for data.

The Exadirect protocol adapter is supported only on Oracle Linux in this release.

🔹Websocket Protocol

The Database client connection supports secure websocket protocol. The secure web socket connection establishment is designed to work over HTTPS, to support HTTPS proxies and intermediary proxies.

This protocol offers a native connection to the database with minimum protocol overhead. Secure websocket protocol is used to negotiate SQL*Net protocol during connection establishment between the database server and the client. The secure websocket protocol uses TLS and requires wallet for operation.

The Web server should support web socket tunneling. Web server proxy module (in case of Apache or Oracle HTTP Server (OHS), mod_proxy_wstunnel)) proxies the secure web socket database connection data between the client and the backend database server. The Database client connects using secure websocket protocol to Web server and the Web server connects to the database using websocket protocol.

🔹 Summary

Sqlnet :

authentication_services = (BEQ, TCPS, NONE)

🔹 Why this matters

Choosing the right protocol:

• Reduces attack surface

• Improves performance

• Simplifies networking

• Improves operational reliability

Small architectural decisions at the connectivity layer can have large operational impact at scale.