WSDualHttpBinding per callback duplex

Question

L'utilizzo di WSDualHttpBinding per i callback duplex funzionerebbe in scenari reali?Supponiamo che io abbia un'applicazione .NET che utilizza una porta casuale, il servizio sarebbe in grado di risolvere gli indirizzi di base e la porta del client per i callback?

Answer 1

Una risposta completa alla tua domanda dipende dal fatto che lo "scenario del mondo reale" sia uno scenario Intranet o Internet.Sebbene WSDualHttpBinding funzioni in entrambi gli scenari, è necessario tenere presente alcune specifiche:

Intranet

WSDualHttpBinding funzionerà con la tua applicazione .NET utilizzando una porta personalizzata preconfigurata in uno scenario Intranet e "Sì" il servizio sarà in grado di risolvere gli indirizzi di base e la porta del client per i callback:esattamente come viene spiegato di seguito.Il motivo spiegato di seguito è che WSDualHttpBinding è progettato principalmente per essere utilizzato su Internet.

I callback duplex in uno scenario Intranet quando è possibile usare WCF sia sul client che sul server si ottengono meglio usando NetTcpBinding o NetNamedPipeBinding.Questi collegamenti utilizzano rispettivamente TCP e ICP come trasporto (anziché HTTP) e una codifica binaria personalizzata, motivo per cui WCF è richiesto su entrambi i lati.Per le richiamate al client viene riutilizzato lo stesso canale utilizzato per connettersi al Servizio tramite il Binding senza richiedere l'apertura di una nuova porta.

Internet

In uno scenario Internet le richieste e le risposte HTTP valide viaggiano solo in una direzione, HTTP è progettato come un protocollo unidirezionale.Quando si utilizza WSDualHttpBinding WCF crea quindi un canale HTTP separato per i callback.In risposta alla tua seconda domanda:per impostazione predefinita, l'indirizzo di destinazione per questa richiamata al client è composto dal nome host della macchina client e dalla porta 80.Se, ad esempio, il client è una macchina di sviluppo e ha IIS installato, la porta 80 sarà riservata esclusivamente in alcuni scenari che causeranno conflitti con l'applicazione prototipo.Questo è ciò questo post del blog presenta una soluzione e ciò che la proprietà ClientBaseAddress è progettata per aiutare.Indipendentemente dalla porta utilizzata, quella predefinita o quella personalizzata, è necessario assicurarsi che tutti i firewall e i router su entrambi i lati siano configurati correttamente per consentire la creazione sia del canale in uscita che del canale di richiamata separato.

Un'applicazione .NET può anche denotare un'applicazione Silverlight.Poiché un'applicazione Silverlight in esecuzione in un browser non può accettare nuove connessioni HTTP in ingresso, WSDualHttpBinding con il suo canale posteriore separato non funzionerà.Quindi PollingDuplexHttpBinding è stato creato inizialmente in Silverlight 2 e può essere considerato un "trucco" intelligente per aggirare il fatto che HTTP è unidirezionale mantenendo aperto il canale di richiesta per un lungo periodo (polling lungo) e utilizzandolo come canale secondario per richiama il cliente.Ciò ha una serie di implicazioni sia sul lato client che sul lato server particolarmente rilevanti per il ridimensionamento, per maggiori dettagli vedere questo post dal mio blog.

Con un'idea del tuo particolare "scenario del mondo reale" e dei tuoi casi d'uso, si spera che questo ti aiuti a elaborare l'associazione corretta da utilizzare per i callback duplex.

Answer 2

Se si tratta di un'applicazione dietro un firewall, in teoria sì.Dipende da cosa intendi per "mondo reale";se con questo intendi "prestazioni elevate" forse NetTcpBinding è un approccio migliore.