APPLIES TO:Oracle Net Services - Version 2.3.4.0.0 to 11.2.0.2Generic Windows Checked for relevance on 5-DEC-2012. TNS-12535 USE_SHARED_SOCKET PURPOSEThis article describes how to get around firewall problems with SQL*Net or Net*8 on Windows servers.SCOPESCOPE & APPLICATIONA firewall is a secure gateway that controls the traffic into and out of a company's internal network. Firewalls can cause problems when a SQL*Net client outside the firewall tries to connect to an Oracle database on Windows NT inside the firewall, or vice versa. The default Oracle Listener listens on port 1521. It may not be sufficient to configure the firewall to allow access through port 1521 so the SQL*Net clients will be able to connect. To understand why the TNS connect will fail, it is necessary to understand how a SQL*Net connection on Windows NT works.When a client initiates a TNS connect, a TCP connection is established with port 1521. A TNS CONNECT packet is then sent to the listener. On UNIX systems the listener process will fork a new Oracle process to deal with the new incoming connection. With UNIX, forked processes will inherit the resources owned by the parent process such as the file handle that represents the TCP socket. In Windows NT, the Listener tells the Oracle Service to spawn a thread. Earlier releases of SQL*Net for Windows NT used the WINSOCK V1.1 API. With this version of WINSOCK there is no capability of passing a TCP socket between two processes, such as from the Listener to the Oracle Service, and so there was no way to inherit the TCP socket. This restriction forced the client to have to create a new TCP connection to the new thread. To do this, the thread randomly selects a new TCP port to use for the connection request, for example port 10087, and informs the listener to redirect the Client to it. The listener now informs the client that they need to REDIRECT the connection attempt to this newly selected networking endpoint. The listener does this by sending a TNS REDIRECT packet to the client with details of the new port to reconnect to. The client drops the existing TCP connection and issues a TCP Connect sequence to the new TCP port, followed by a TNS Connect packet. The server thread accepts the TCP connect and responds with a TNS ACCEPT packet. The Client exchanges various TNS packets and then logs into the Database. So, if you create an Access Control List (ACL) on the firewall to allow connects through port 1521, after the REDIRECT packet has been sent to the client and the TCP connection to port 1521 is closed, the firewall will not allow the TCP connection to port 10087 so the TNS connection will fail. As the REDIRECT port that gets generated is entirely at random, it would not be secure to allow connections to this random port range in the firewall as it begins to defeat the purpose of the firewall. DETAILSnote:62528.1note:62528.1 /To resolve this problem there are several options:
WARNING: When using this method you must restart all Oracle processes for them to pick up the registry change.
Note: This parameter only works in dedicated server mode in a TCP/IP environment and will not work for the Multi-Threaded Server (MTS) configuration. To spawn a dedicated server for an instance of Oracle Database not associated with the same Oracle home as the listener and have shared socket enabled, you must also set the parameter USE_SHARED_SOCKET for both Oracle homes.
Note: If this parameter is set, you cannot use a version 8.0 or later listener to spawn Oracle7 release 7.x databases.
Note: USE_SHARED_SOCKET was introduced in Oracle version 8.0. It was set off by default in 8.0 to 10.0. The default is set to true in 10.1 and later. This parameter is planned to be deprecated in a future release.
REFERENCESNOTE:62528.1 - Using Connection Manager (CMAN) as a MultiProtocol Interchange (MPI)NOTE:124140.1 - How to configure USE_SHARED_SOCKET on Windows NT/2000 |
