Come funziona xsockets.net (.NET WebSocket Server) su Windows 2008?

Question

Sto confrontando i server websocket

1. xsockets.net
2. SuperWebSocket
3. Fleck
4. SignalR

SignalR è disponibile solo su Server 2012, ma i miei server sono in esecuzione di Windows 2008.

SuperWebSocket & Fleck, supportano solo il fallback proxy flash.

xsockets.net, questo ha un supporto di fallback a lungo pool nel browser Web di un vecchio. Ma dice che il fallback è disponibile solo per il progetto MVC3/4. Può aprire una porta nell'applicazione MVC3/4 per accettare connessioni per client che supportano websocket? Mi sembra impossibile su Windows 2008.

Ho la domanda, cioè: come funziona XSockets.NET in Windows 2008?

Come sapete, la funzione WebSocket non viene aggiunta in http.sys fino a IIS8.0. In IIS7.5, SignalR esegue sempre la modalità di pooling lungo per tutti i client.

È lo stesso per XSockets.NET? perché si dice che il fallback di pooling lungo è supportato solo nel progetto MVC3/4. Se voglio approfittare del supporto di fallback, devo usare XSockets.NET in MVC3/4 che è finalmente ospitato da IIS. E IIS7.5 non ha la caratteristica di websocket, questo è ciò che ho paura di

Qualcuno sa come funziona in IIS7.5 che ospita l'applicazione MVC? Gestire tutti i client tramite pooling lungo?

Answer 1

Edit:

Compability

XSockets saranno websocket compatibile su qualsiasi macchina che esegue .NET 4,0 (o successivo) o Mono. Questo è indipendentemente dal sistema operativo ... È anche possibile eseguire gli XSockets completi su un Raspberry PI, se lo si desidera. L'unica volta che XSockets utilizzerà il fallback è se il client che si connette non supporta websockets (IE9, IE8 ecc.).

SignalR ha sviluppato il supporto WebSocket su .NET 4.5 e lo spazio dei nomi WebSocket incorporato (in 4.5) mentre XSockets ha implementato il protocollo WebSocket in .NET 4.0 (tra le altre cose). SignalR e XSockets non hanno davvero nulla in commento oltre al fatto che entrambi sono costruiti su .NET framework, dopo di che l'aspetto è molto diverso ... Ma questo è fuori portata.

Ambiente

Dal XSockets ha implementato il protocollo WebSocket da essa sé questo significa che XSockets non dipende da alcun server web, IIS, Apache, ecc ... Può essere eseguito come servizio di Windows standalone o su Azure se ti piace. Tuttavia, puoi anche avviare XSockets all'interno del tuo Web ed è in realtà come viene configurato quando installi il nostro pacchetto nuget.

Fallback

Quando si installa XSockets in una soluzione MVC3/MVC4 l'installazione registrerà automaticamente un controller aggiuntivo. Questo controller utilizzerà le nostre API esterne (socket) per comunicare con XSockets e l'API JavaScript eseguirà AJAX (longpolling) su questo controller se il client non supporta il websocket. Come sviluppatore non devi fare nulla di diverso oltre all'aggiunta di un ulteriore file JavaScript se vuoi usare il fallback.

Ora è possibile eseguire il fallback anche per WebForms (e Azure), ma dal momento che è fuori dal campo lo lasciamo in un secondo momento, se avete domande a riguardo.

Bottom Line Per concludere ...

• Non preoccuparti per XSockets che necessitano di un sistema operativo speciale per correre, corriamo su qualsiasi ambiente Windows/Unix/Linux a patto che .NET 4.0 o Mono è installato.
• XSockets eseguito in IIS, in Azure, come servizio di Windows o solo un'applicazione console ... È anche possibile eseguire il server su Raspberry PI o qualsiasi altra cosa (un telefono o qualsiasi altra cosa) purché i requisiti per .NET/Mono è pieno.
• XSockets può essere sviluppato sia in ambienti .NET/Mono, quindi è possibile sviluppare plugin sia da un MAC che usa Xamarin e Windows utilizzando Visual Studio.
• Il fallback viene impostato automaticamente quando lo si installa per lo sviluppo in MVC3/MVC4 ma è anche possibile impostare il fallback su WebForm di Azure e .
• SignalR hanno l'ambiente server di decidere se i clienti possono utilizzare WebSockets o no, XSockets hanno sempre WebSockets e fallback per longpolling solo quando il client non supporta WebSockets.