server push vs pull client per Agent-topologia server

Question

ho bisogno di creare un sistema composto da 2 componenti:

• un singolo server che di processo e memorizza i dati. Invia periodicamente aggiornamenti agli agenti

• Più agenti installati su endpoint remoti. Questi raccolgono i dati in (spesso, ma non sempre) le operazioni a lungo in esecuzione, e questi dati ha bisogno per arrivare al server

sto usando C# .NET, e idealmente io voglio usare uno standard di comunicazione compliant metodo (vale a dire uno che potrebbe teoricamente funzionare anche con Java, dato che potremmo anche usare gli agenti Java in futuro). Ci sono alternative ai servizi web? Quali sono le mie opzioni?

Il mio modo di vedere Ho 3 opzioni utilizzando i servizi web, e hanno fatto le seguenti osservazioni:

• pull client
  • Non aprire la porta richiesta presso l'agente, in quanto agisce come un cliente
  • avrebbe bisogno di interrogare il server per gli aggiornamenti
• server push
  • Aprire la porta presso l'agente, in quanto agisce come un server di
  • Server deve interrogare gli agenti per i risultati
• ibrida
  • Aprire la porta presso l'agente, in quanto agisce come sia un client e un server
  • Nessun polling; Server spinge gli aggiornamenti quando necessario, client invia i risultati quando sono disponibili

Il 'ibrido' (in cui gli agenti sono entrambi client e del server sembra la scelta più ovvia - ma questa applicazione sarà in genere essere installato in ambienti aziendali e governativi, e sono preoccupato che possono avere un problema con l'apertura di una porta presso l'agente. sono soffermarsi troppo su questo?

ci sono altri vantaggi e gli svantaggi che ho perso?

Answer 1

I nostri amici a http://www.infrastructures.org giurano da meccanismi di pull-based: http://www.infrastructures.org/papers/bootstrap/bootstrap.html

Una delle principali ragioni per cui preferiscono client-pull over del server-push è che i clienti possono essere giù, ei clienti devono (in generale) si applicano tutte le operazioni spinte dai server.Se questo criterio non è importante nel tuo caso, forse la loro conclusione non sarà la tua conclusione, ma penso che valga la pena di leggere la sezione "Push vs Pull" del loro articolo per determinare da solo.

Answer 2

Se si utilizza una sorta di messagi ng server (JMS per Java, non è sicuro per C#), il server di messaggistica è l'unico server che deve aprire una porta e si può avere una comunicazione bidirezionale dall'agente al server di messaggistica e dal server al server di messaggistica. Ciò consentirebbe di realizzare il modello ibrido senza dover aprire una porta sul server dell'agente.

Answer 3

IMHO, trovo la soluzione migliore è l'opzione di trazione .. che possono soddisfare le vostre principali requisiti di sistema come segue:

La prima parte: i dati ha bisogno di arrivare al server, che è, ovviamente, può essere fatto attraverso invocando un metodo web che invia tali dati come parametro

2a parte: (il server invia periodicamente aggiornamenti agli agenti): È ancora possibile eseguire ciò tramite il client (regolare) per mezzo di una sorta di metodo di servizio Web che " chiede "per gli aggiornamenti dall'ultima estrazione (una sorta di timestamp per ottenere gli aggiornamenti persi)

L'hybri Il metodo d sembra un po 'strano per me dato che penso ad un agente come parte del sistema che probabilmente potrebbe andare "offline" abbastanza spesso, che cosa farà il server se ciò fallisse? di solito è una domanda/decisione difficile, specialmente se non sei sicuro se questo è inteso come "andare offline" o un sistema/errore di rete .. ecc.

Answer 4

Direi che in questo giorno ed età si può seriamente considerare solo tirare le tecnologie. Il problema con il push è che i client sono spesso nascosti dietro dispositivi NAT (Network Address Traversal) come router wireless, modem a banda larga o firewall aziendali e sono, molto spesso, irraggiungibili dal server.

La creazione di connessioni in uscita ("telefono-casa"), in particolare su porte note come HTTP/HTTPS, può essere presumibilmente definita "possibile" anche nelle reti più ristrette.