Both ports connect to different Azure SQL IP address. The application only connects to one SQL Server, but it creates two connections. I guess it’s part of the protocol.
The local container only connects to 1433.
The Azure container connects to 1433 and another port.
Does TDS need to anything for Connectivity from within Azure?
Connectivity from within Azure
If you are connecting from within Azure your connections have a connection policy of Redirect by default. A policy of Redirect means that after the TCP session is established to Azure SQL Database, the client session is then redirected to the right database cluster with a change to the destination virtual IP from that of the Azure SQL Database gateway to that of the cluster. Thereafter, all subsequent packets flow directly to the cluster, bypassing the Azure SQL Database gateway. The following diagram illustrates this traffic flow.
Connectivity from outside of Azure
If you are connecting from outside Azure, your connections have a connection policy of Proxy by default. A policy of Proxy means that the TCP session is established via the Azure SQL Database gateway and all subsequent packets flow via the gateway. The following diagram illustrates this traffic flow.
My connection to the SQL server doesn’t disconnect after I changed the SQL server Connection Policy from Default to Proxy.
The TCP traffic on port 1433 on the Azure container is constant every 2 seconds like my local container.
The Azure container only connects to 1433 after the change.
Maybe it will help if you can look at the decrypted traffic. That would require some work but I’m not sure how else to find out more. It’s the ssl — OTP 29.0.2 (ssl 11.7.2) option on SSL. Some stuff is linked from Support SSLKEYLOGFILE environment variable. · Issue #132 · sneako/finch · GitHub that might show you how to implement it.
When the Azure container is connected to the SQL server using the Redirect connection policy, it doesn’t need the connection on port 1433. It uses the other port in range of 11000-11999 to communicate with the database.
When the connection on port 1433 closes, it also closes the connection on port 11000.
TDS in deps\tds\lib\tds\tls.ex asserts the connection to 11000 when it calls send/2 for something.
def send(socket, payload) do
socket
|> assert_connected!()
|> GenServer.call({:send, payload})
end
# Asserts that the port / socket is still open and returns its `pid`
defp assert_connected!(socket) do
{:connected, pid} = Port.info(socket, :connected)
pid
end
Are you confident that change isn’t going to result in processes sticking around when they shouldn’t?