2009-11-28 2 views
7

Sto lavorando su una libreria di classi che recupera informazioni da un sito Web di terze parti. Il sito Web a cui si accede smetterà di rispondere se vengono eseguite troppe richieste entro un periodo di tempo impostato (~ 0,5 secondi).Di chi è la responsabilità di limitare le richieste web?

I metodi pubblici della mia libreria riguardano direttamente una risorsa un file sul server web. In altre parole, ogni volta che viene chiamato un metodo, viene creato uno HttpWebRequest che viene inviato al server. Se tutto va bene, un file XML viene restituito al chiamante. Tuttavia, se questa è la seconda richiesta web in meno di 0,5 s, la richiesta sarà timeout.

Il mio dilemma sta nel modo in cui dovrei gestire il throttling di richiesta (se non del tutto). Ovviamente, non voglio che il chiamante si sieda in attesa di una risposta, specialmente se sono assolutamente certo che la loro richiesta scadrà.

Sarebbe più sensato per la mia libreria mettere in coda e limitare le richieste web che creo, o la mia biblioteca dovrebbe semplicemente lanciare un'eccezione se il client non aspetta abbastanza a lungo tra le chiamate API?

+0

Justin. Il sito web che stai accedendo al tuo o a una terza parte. I miei commenti sul "Buon cittadino" si basavano sul fatto che si trattava di una terza parte, ma altri sembrano aver assunto il proprio sito. – Andiih

+0

Il sito è davvero un sito di terze parti. Grazie per aver sottolineato che non l'avevo specificato. Ho aggiornato la mia domanda per chiarire. –

risposta

6

Il concetto di una libreria è di dare al proprio codice client il minimo di preoccupazione possibile. Pertanto, farei il lavoro delle librerie per accodare le richieste e restituire i risultati in modo tempestivo. In un mondo ideale si usa un callback o un modello delegato in modo che il codice client possa operare in modo asincrono, non bloccando l'interfaccia utente. Puoi anche offrire l'opzione per saltare la coda (e fallire se funziona troppo presto) ed eventualmente anche offrire priorità all'interno del modello di coda.

Credo anche che sia responsabilità dell'autore della biblioteca impostarsi come un buon cittadino e che l'operazione predefinita della libreria sia quella di soddisfare le condizioni del fornitore di dati.

+0

+1 per la parte "buon cittadino". Ho quasi dimenticato di vedere questo problema dal punto di vista del fornitore di dati. Ma allora come potrei garantire che i risultati vengano forniti in modo tempestivo, senza mettere un limite di qualche tipo sul numero di richieste che potrebbero essere accodate? –

+1

Non penso che sia necessario garantire, purché si forniscano metodi per interrogare la dimensione della coda e magari anche di avere un timeout implementato dalla libreria. – Andiih

+0

Ma allo stesso tempo, non sarebbe più puro lasciarlo semplicemente accadere, lasciare che la richiesta venga negata, ma semplicemente far loro sapere che lo stanno facendo troppo velocemente? Inoltre, un giorno l'effettiva implementazione del sito potrebbe alzare il limite più in alto, potrebbe anche lasciare che la libreria sia un messaggero piuttosto che un dittatore. – BigOmega

2

Questa è la responsabilità del server Web, imo. Poiché il carico critico dipende dall'hardware, dalla larghezza di banda della rete, ecc. Molte cose al di fuori del controllo dell'applicazione, non dovrebbe preoccuparsi di provare l'accordo con esso. IIS può limitare il traffico in base a varie opzioni di configurazione.

+1

Sicuramente se la tua biblioteca è di accedere a un servizio web che accetta solo una risposta per 0,5 secondi, e questa è una condizione del suo utilizzo, allora è qualcosa di cui dovresti preoccuparti? – Andiih

+0

Se c'è qualche ragione di business per cui si accettano solo 2 richieste al secondo (forse perché i dati non vengono aggiornati più frequentemente e il client non vedrebbe nulla di nuovo?), Allora non lo chiamerei limitazione nel senso che si desidera per limitare il carico, e questo è assolutamente qualcosa che l'applicazione potrebbe far rispettare. – cdonner

+0

Il sito Web a cui si accede è un sito di terze parti, quindi sfortunatamente le impostazioni di IIS sono fuori dal mio controllo. –

3

Direi entrambi: si tratta di due sistemi indipendenti ed entrambi dovrebbero adottare misure per difendersi dal carico eccessivo. Il server Web dovrebbe rifiutare le connessioni in entrata e la libreria client dovrebbe adottare misure per ridurre le richieste a un servizio esterno lento o non responsivo. Un modello comune per affrontare questo sul client è "interruttore di circuito" che avvolge le chiamate verso un servizio esterno e non riesce in modo rapido per un certo periodo dopo il fallimento.

+0

Sarebbe bello se la richiesta fosse rifiutata, invece di ignorarla. Grazie per avermi indicato il modello dell'interruttore automatico, però. Posso certamente vedere le volte in cui sarebbe utile. –

1

Che tipo di cliente è? Si tratta di un client interattivo, ad esempio: app basata su GUI?

In tal caso, è possibile equipararlo a uno scenario del browser Web e lasciare che il timeout raggiunga il chiamante. Inoltre, se si è sicuri che questo server web limita le richieste, è possibile dire al cliente che deve attendere un determinato periodo di tempo prima di riprovare. In questo modo, il cliente non continuerà a riemettere le richieste e saprà quando si verifica il primo timeout che è inutile inviare richieste troppo velocemente.

+0

Il client è una libreria di classi, che potrebbe essere utilizzata da un'applicazione GUI. Usando le eccezioni per informare il chiamante che il mio metodo viene chiamato frequentemente è una soluzione che sto considerando. Ma so che le chiamate frequenti causeranno un timeout, quindi è davvero una circostanza eccezionale? –

+0

Hai accennato al fatto che il server gestisce le richieste se "troppe richieste" vengono inviate con una certa ora (0,5 secondi). Quanto costano "troppe richieste"? Se ci pensate, se 0.5s è il limite, allora potrebbe essere davvero difficile per il client basato su GUI superare questo. In alternativa, è possibile progettare la libreria della GUI affinché non siano in attesa di più di richieste asincrone 'N', in modo da non martellare mai il server. Vorrei limitare N = 2 (e renderlo configurabile per i tuoi utenti). E disporre di un meccanismo che utilizza un delegato per fornire notifiche di avanzamento del client. – feroze