Sockets vs. WCF

Question

Lavoro su un'applicazione simile alla chat, dove utilizzo Silverlight sul lato client e wpf sul lato server. In questo momento la comunicazione è basata su Socket: ho diverse classi di messaggi che serializzo e invio via TCP.

Inizio a rendermi conto che la creazione di una Classe messaggio separata per ogni possibile scenario di comunicazione è piuttosto un sovraccarico e prendere in considerazione il passaggio a WCF.

Perciò ho bisogno di conoscere le seguenti cose:

1. Sembra che tutta la comunicazione utilizzando WCF si basa sui client callind esposti metodi dal mio servizio WCF. C'è un modo per sapere quale client chiama un determinato metodo? Questo è abbastanza importante per la mia applicazione.

2. WCF notifica la mia applicazione, quando un client si disconnette (ad esempio chiude la finestra del browser in cui è in esecuzione il client Silverlight) dal server? Anche questo è abbastanza importante.

3. Il metodo chiama completamente asincrono? In tal caso, devo reindirizzare ogni chiamata di metodo al thread principale dell'applicazione server?

4. Ogni connessione client ha una propria discussione? Quante connessioni simultanee potrebbe gestire il server (in esecuzione su un PC dotato di alimentazione ragionevole) se i client chiamano i metodi dire ogni 2 secondi? Ho solo bisogno di una stima (10, 100, 1000 o anche di più). "Altro" sarebbe fantastico;)

Forse ho sbagliato completamente e WCF non funziona affatto basato sulla connessione. Quindi dovrei trovare una soluzione alternativa per gestire ancora un elenco di connessioni attive.

Grazie per il vostro aiuto! Andrej

Answer 1

1. Dal momento che si sta utilizzando un'applicazione Silverlight, è possibile implementare un validatore UserNamePassword sullo strato di messaggio, che aggiunge alcune intestazioni al messaggio sapone, questo potrebbe essere usato per identificare in modo univoco i clienti, a meno che i clienti sono anonimi . quindi è possibile utilizzare System.ServiceModel.OperationContext.Current, quando è necessario accedere al nome utente altrove nel servizio wcf.

2. Il server non viene avvisato quando il client si disconnette, poiché i messaggi di posta elettronica sono "PerCall" per impostazione predefinita, esiste un modo, utilizzare una classe Singleton come un servizio di assistenza con InstanceContextMode.Single, quindi implementare un OperationContract con un servizio di callback, quindi quando i client eseguono l'accesso al servizio devono registrarsi con il servizio di callback, il servizio callback può quindi scorrere i client connessi e verificare lo stato del callback, sia esso ancora aperto o no, infine rimuovere le voci in cui le connessioni sono chiuse, eventualmente è possibile ottenere la funzionalità desiderata.

3. Le chiamate asincrone provengono dal client, ad es. in Silverlight tutte le chiamate al servizio web sono asincrone, come in ASP hai una scelta, WCF gestisce automaticamente la funzionalità asincrona, quindi non devi reindirizzare nulla, basta codificare ServiceContract come un singolo thread, e tutto andrà bene

4. Implementare la codifica dei messaggi binari in silverlight 3, per sfruttare al massimo il server e la larghezza di banda, Silverlight non supporta le connessioni tcp non elaborate, deve essere rapped in un messaggio http per ottime ragioni. Ogni client può avere molte chiamate simultanee (ricorda async), quindi per semplificare le cose, basti pensare ad esso come se il server assegni un thread separato ad ogni chiamata di messaggio. Quindi per rispondere alla tua domanda su quello che hai appena detto, 1000.

Answer 2

Per 3 so che è possibile chiamare async.

E per 4 sì, hanno i loro thread. WCF è piuttosto "GRANDE" e complesso, dovresti ottenere un libro per capirlo meglio.

Answer 3

Le mie risposte:

1. Sì. Tutte le comunicazioni si basano sui metodi di chiamata.
2. In generale - N.
3. È possibile chiamare i metodi in modo sincrono o asincrono. Questa è la tua scelta.
4. Altro. I caso del giusto design del sistema.