Metodi migliori rispetto ai metodi di polling tradizionali

Se per "tradizionale" intendi che ogni cliente martella il server tutte le volte che possono, allora posso aiutarti a livello architettonico.

Il design appropriato dipende da dove il tuo server cade in questa griglia:

Control \ Resources : Sufficient | Insufficient
Customizable        :     SC     |     IC
Untouchable         :     SU     |     IU

• SC: fai in modo che il server segua il modello di osservatore . Consenti ai clienti di registrarsi come osservatori.

• IC: consente solo a un sistema proxy di registrarsi con il server. I client si registrano con il proxy.

• SU: consente solo a un sistema proxy di eseguire il polling del server. I client si registrano con il proxy.

• IU: consente solo a un sistema proxy di eseguire il polling del server. I client si registrano con il proxy.

Un proxy che segue il modello di osservatore può risolvere sia i problemi di personalizzazione che di risorse. Funziona altrettanto bene su Internet come fa tra gli oggetti. Quando ti registri stai chiedendo di essere chiamato quando succede qualcosa. Ascolta su una porta e sei pronto per essere chiamato. ajax, REST, UDP, qualunque cosa.

Il problema con il polling è che l'osservatore controlla quando si verifica la chiamata ma non sa quando lo stato cambia, quindi fa molte chiamate inutili. Questo mangia risorse specialmente quando ci sono molti osservatori. La chiave per affrontare il polling è: non appena possibile, ottenere la direzione delle chiamate che vanno dal punto di cambiamento dello stato all'osservatore. Quindi le chiamate avvengono quando sono necessarie. Non quando non lo sono.

Se hai chiamate di polling in questo modo:

• Server < === Molti osservatori

Ognuno di questi sarebbe un modo migliore per rilevare le modifiche:

• SC: server === > Molti osservatori

• IC: server === > Un proxy === > Molti osservatori

• SU: Server < === Un proxy === > Molti osservatori

• IU: Server < === Un proxy === > Molti osservatori

Puoi usare Server-Sent-Events come un'alternativa al sondaggio.

Invece di chiedere al tuo server nuovi dati ogni n secondi, apri una connessione dedicata e fagli inviare i tuoi nuovi dati quando saranno disponibili!

La connessione rimarrà aperta fino a quando non verrà chiusa esplicitamente dal client o dal server (o dalla loro improvvisa chiusura).

Puoi configurare il tuo server per trasmettere dati al tuo client a intervalli fissi, o in momenti specifici sul tuo server (diciamo quando un oggetto cambia stato o quando uno schedulatore attiva un lavoro o quando).

Puoi definire diversi tipi di eventi e avere routine diverse per gestire diversi tipi di eventi.

Sul lato server è possibile tenere una coda di utenti attualmente abbonati al tipo di applicazione / evento, quando viene creato un evento, il server lo trasmetterà a tutti gli utenti in coda. I framework come Jersey2 implementano già questo approccio usando un oggetto Broadcaster .

Sul lato client dovrai scrivere un servizio che ascolterà il server ha inviato eventi su un URL specifico .

Quando entrerai in uno stato / percorso dovrai iscriverti a un tipo di server e annullare la registrazione su $destroy per evitare perdite.

Sono websocket: sono un'espressione di HTTP, funzionano nella stessa porta.

Abilita la comunicazione bidirezionale tra client e server e ovviamente è disponibile un'integrazione di angularjs per questo.

Altrimenti sul lato back office, se guardi a Spring in Java, ci sono altri modi per farlo:

• Polling lungo
• STOMP
• ...

Questo link covevr websocket e altri metodi adattati a di cosa hai bisogno.

Nota che se non hai Spring / Java, dovresti comunque leggerlo e cercare una soluzione equivalente nel tuo stack di tecnologie.

Devi definire meglio cose come "abbastanza oneroso" ed esplorare perché non recupera immediatamente il risultato più recente. Queste sono domande che probabilmente stanno accadendo indipendentemente dal fatto che tu stia effettuando il polling dal tuo cliente o meno.

Detto questo, con un front-end basato su browser, in pratica hai due opzioni se vuoi rimanere in javascript nativi: polling (come stai facendo, o probabilmente polling lungo) o socket web. Non ho mai visto le prese del web fatte con ASMX (non dicendo che non può essere fatto, solo che non ho esperienza lì quindi non so quanto sarebbe difficile da implementare). Inoltre, se si riscontrano problemi di prestazioni o accuratezza, come ho detto, potrebbero comunque esserci anche con l'uso di socket Web.