Ciao e grazie a tutti.
Roberto
l'implementazione di porte dinamiche e' stato "aggiunto" a SQL Server 2000 e
versioni successive al fine di supportare piu' istanze per ogni macchina..
Microsoft ha potuto farsi riconoscere da IANA, l'organizzazione che
standardizza e riconosce le cosidette "porte note" solo per 1 porta, la nota
TCP 1433, solitamente utilizzata per l'istanza predefinita, e quindi non
c'e' "automaticamente" verso di predefinirne di altre.. hanno cosi' risolto
il problema alla radice, implementando il SQL Server Resolution Service,
parte integrante del servizio, ora separato, in SQL Server 2005, ed
implemetato a parte nel servizio SQLBrowser;
il principio delle "porte dinamiche" fa si che, allo startup dell'istanza,
se cosi' impostata, questa cerca una porta libera.. al successivo startup,
verifica che tale porta sia nuovamente libera ed utilizzabile, diversamente
un'altra porta viene ricercata.. questa dinamicita' fa si' che sia
"pericoloso", per i client, specificare una porta specifica di utilizzo in
quanto potrebbe essere modificata ad ogni successivo startup del servizio..
entra cosi' in gioco il SQL Server Resolution Service/SQLBrowser che, in
ascolto sulla porta UDP 1434, intercetta tutte le chiamate ad istanze non in
ascolto sulla porta "predefinita" TCP 1433 per le quali non sia anche stato
specificato, a livello di connessione, la porta specifica di indirizzamento,
tipo
".....; Data Source = serverName{\InstanceName}, numPort; ..."
ovvero anche tramite un Alias opportunamente configurato..
il servizio legge nel registry la porta utilizzata dall'istanza e
reindirizza la connessione entrante verso quella porta, dopo di che, per
quella connessione, non entra piu' in gioco... rientrera' in campo alla
successiva apertura di connessione, se e quando avverra'...
ovviamente questo implica una piccola latenza in quanto l'overhead di
recupero delle informazioni da parte di SQLBrowser richiede un roundtrip a
livello di registry... cosa di poco conto, ma comunque da tenere in
considerazione... ci aggiungiamo magari anche la latenza derivante alla
connessione al domain controller per recuperare il sid della login trusted
da passare come credenziale a SQL Server, e l'overhead puo' diventare anche
umanamente apprezzabile...
l'utilizzo di porte dinamiche semplifica ovviamente l'amministrazione, ma
personalmente, per svariati motivi, incluso la maggior velocita' di
connessione, ma soprattutto la possibilita' di definizione di politiche di
sicurezza per le quali una porta "non nota" viene definita per il servizio
SQL Server in modo da diminuire la cosidetta "superficie di attacco",
preferisco sempre utilizzare una porta statica da me assegnata (non la 1433,
anche per l'istanza predefinita), che deve poi essere utilizzata da tutti i
client che accederanno al servizio, sia tramite un'eventuale definizione di
un Alias come piu' semplicemente specificando esplicitamente la porta di
indirizzamento remoto nelle stringhe di connessione...
saluti e buon Natale..
--
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz http://italy.mvps.org
DbaMgr2k ver 0.21.0 - DbaMgr ver 0.65.0 and further SQL Tools
--------- remove DMO to reply