Comunicazione avviata dal server ai client

Question

Comunicazione avviata dal server ai client

#1 da (1 voti)

-1

Sto cercando di creare un servizio internet che esegua comandi sui computer collegati. I comandi vengono avviati tramite un dashboard basato sul Web.

Al momento ho un'API REST in esecuzione con Laravel e l'applicazione dashboard di frontend è stata creata.

Mi sto bloccando su come connettere i client al servizio cloud. I client eseguiranno diversi SO (Windows, Mac, Linux).

Ho un client desktop .NET Core parzialmente compilato, ma non sono sicuro di come collegarlo al server in un modo che consenta al server di inviare comandi. Spero di ottenere questa comunicazione in tempo reale e scalabile fino a migliaia di endpoint. Deve anche essere un trasporto sicuro. (Possibilmente HTTPS)

Alcune tecnologie su cui mi sono imbattuto sono gRPC, WCF, Websockets. Sono state trovate anche altre tecnologie di reverse tunnel che probabilmente non funzioneranno.

Al termine sarà probabilmente ospitato su MS Azure.

Qualsiasi aiuto sarebbe fantastico! Grazie!

EDIT: la domanda modificata deve essere più chiara in ciò che ho cercato e in cosa sto pensando.

Josh

design c# .net-core

posta josh13564 21.05.2018 - 00:33

fonte

1 risposta

Leggi altre domande sui tag design c# .net-core

Qual è un termine valido per un valore R di lunghezza 1? Come delegare il rinnovo del token di aggiornamento in un SOA

score 1 · Accepted Answer

Consideriamo

WebSockets
Segnale R (consigliato da MSFT per questo tipo di comunicazione, costruito su Websockets)
Il client C # degli eventi inviati dal server HTML5 esiste.
Sondaggi lunghi. Funziona anche quando firewall o vecchi software bloccano gli altri.

Tutti funzionano su tutti i sistemi operativi menzionati. Tutti supportano HTTPS su TLS.

Perché non funzionano?

Non è chiaro il motivo per cui dici che Websockets non funzionerà. Se questi strumenti non funzioneranno nel tuo caso, probabilmente dovresti spiegare il motivo per cui potresti ricevere una risposta più adatta. Non sono perfetti per ogni applicazione, ma di solito le app per le quali non funzionano hanno requisiti speciali.

Il polling lungo con i controller asincroni sul lato server funziona praticamente ovunque. Non è certamente alla moda degli altri, ma molto pratico.

Se vuoi eseguire l'app su dispositivi che si trovano ovunque su Internet, queste sono le cose meno probabili in conflitto con i firewall.

Il polling lungo è un buon ripiego per qualsiasi situazione in cui metodi più alla moda falliscono a causa di firewall o criteri di rete. È solo Http e comporta zero richieste da server a client. Proprio come un GET a un sito web.

Lato server asincrono Per un lungo polling da migliaia di dispositivi, in genere vale la pena rendere i controller lato server asincroni, dal momento che .Net lo supporta, per evitare di parcheggiare migliaia di thread in attesa di un comando.

Coda o altra struttura di blocco simultaneo Con Websockets, una richiesta di riposo in genere può generare un messaggio a un altro dispositivo e utente. Sembrava da un po 'che ogni libreria o framework usasse un'app di chat come esempio per i websocket.

Il polling lungo in genere non include questa funzionalità e in genere dipende da ogni richiesta GET in attesa su una struttura di blocco di tipo Sone, in genere una coda che consente alle richieste di lettura di bloccare.