---

Novembre 2015

Volume 30 Numero 12

Il presente articolo è stato tradotto automaticamente.

ASP.NET - Usare ASP.NET come downloader di file a prestazioni elevate

Da Doug Duerner

Connessioni lente e difettosa sono già state deleterie per il download dei file di grandi dimensioni. È possibile ritrovo un aeroporto Raccolta multimediale tramite una connessione Wi-Fi sketchy per l'utilizzo di una presentazione durante un lungo volo o il savannah africane sta tentando di scaricare un file di installazione di grandi dimensioni tramite collegamento satellite per una data pump solare alimentati acqua. In entrambi i casi, il costo della presenza di arresto anomalo di scaricare un file di grandi dimensioni è lo stesso: tempo perso, produttività svuotati e l'esito dell'assegnazione imperiled.

Non deve necessariamente essere in questo modo. In questo articolo viene illustrato come creare un'utilità per risolvere il problema di ripristino e continuare il download non riuscito può essere causato da scarse connessioni che sono suscettibili di eliminazione non in linea durante i trasferimenti di file di grandi dimensioni.

Situazione generale

Si desidera creare un'utilità downloader file semplice che è possibile aggiungere facilmente per il Server Web IIS esistente, con un'operazione estremamente semplice e facile da utilizzare client programma (o la possibilità di utilizzare semplicemente il Web browser come client).

Il Server Web IIS ha già dimostrato di essere un server Web aziendale altamente scalabile, avvalendosi di ai browser per anni. Volevamo fondamentalmente sfruttare le capacità del Server Web IIS per gestire un numero di richieste HTTP Web allo stesso tempo, in parallelo e applicarlo al file di download (copia).

Essenzialmente, dovevamo un'utilità di downloader file che è possibile scaricare i file di grandi dimensioni per gli utenti in tutto il mondo che talvolta si trovano in aree remote con lente e collegamenti di rete spesso difettoso. Con la possibilità che alcuni utenti remoti in tutto il mondo ancora utilizzando collegamenti modem o satellite difettoso che potrebbe essere offline in modo casuale volte oppure alternare in modo intermittente online e offline, l'utilità è necessario estremamente flessibile con la possibilità di ritentare solo le parti del file di download non riuscito. Si non desidera che un utente di dedicare tutta la notte download di un file di grandi dimensioni su un collegamento lento e se si è verificato un piccolo videogioco nel collegamento di rete, è necessario avviare il processo di download intero nuovo. È inoltre necessaria per garantire questi file di grandi dimensioni in fase di download non sono stati memorizzati nel buffer nella memoria del server e che l'utilizzo della memoria del server è minimo, in modo che l'utilizzo della memoria non mantenere aumento fino a un errore del server quando molti utenti sono stati download di file contemporaneamente.

Viceversa, se l'utente è stato abbastanza fortunato a disporre di un collegamento di rete ad alta velocità affidabili, con i computer client e server in computer di fascia alta con più processori e schede di rete, si volessero individuare l'utente sia in grado di scaricare un file utilizzando più thread e più connessioni, consentire il download di più blocchi di file contemporaneamente in parallelo utilizzando tutte le risorse hardware , mentre allo stesso tempo l'utilizzo di memoria minima del server.

In breve, è stata creata una semplice, multithreading e parallelo, l'utilità di download di file di utilizzo della memoria basso che può suddividere il file in blocchi, scaricare i singoli blocchi su un thread separato e consentire all'utente di ripetere solo i blocchi che non è riuscito a scaricare.

Il progetto di esempio che accompagna questo articolo contiene il codice per l'utilità di download di file e fornisce un'infrastruttura di base rudimentale che può essere espansa in futuro, consentendo di ottenere più sofisticate come necessario viene visualizzato.

Cenni preliminari sul progetto di esempio

In sostanza, DownloadHandler.dll Trasforma un Server Web IIS esistente in un downloader file multithreading che consente di scaricare un file in blocchi, in parallelo, utilizzando un semplice URL dal client eseguibile autonomo (FileDownloader.exe), come illustrato nella Figura 1. Si noti che il parametro (chunksize = 5242880) è facoltativo e, se viene omesso, verrà predefinito per scaricare l'intero file in un blocco. Figura 2 e Figura 3 illustrano come consente di inviare solo le parti del file non riuscite ripetutamente finché non vengono completate senza dover riavviare completamente l'intero download dall'inizio, come la maggior parte degli altri software download di file.

Figura 1 Panoramica ad alto livello di progettazione del flusso di elaborazione per DownloadHandler.dll (utilizzando FileDownloader.exe come Client)

File eseguibile autonomo nella figura 2 il Download dei Client (con blocchi non riuscite)

File eseguibile autonomo nella figura 3 il Download dei Client (dopo il nuovo tentativo)

Figura 1 una panoramica generale della progettazione di DownloadHandler.dll e FileDownloader.exe, che mostra il flusso di elaborazione, come i blocchi del file sul disco rigido del computer server passano attraverso DownloadHandler.dll e FileDownloader.exe nel file sul disco rigido del computer client, che illustra le intestazioni di protocollo HTTP coinvolti nel processo.

In Figura 1, FileDownloader.exe avvia un file da scaricare mediante una chiamata al server utilizzando un URL semplice che contiene il nome del file da scaricare come parametro di stringa di query URL (file=file.txt) e internamente utilizza il metodo HTTP (persona), in modo che inizialmente il server invierà nuovamente solo relative intestazioni di risposta, uno dei quali contiene la dimensione totale del file. Il client utilizza quindi un costrutto di Parallel. foreach per eseguire un'iterazione, la dimensione totale di suddivisione in blocchi (intervalli di byte) in base alla dimensione del blocco nel parametro (chunksize = 5242880). Per ogni iterazione singoli, il costrutto di Parallel. foreach esegue un metodo di elaborazione su un thread separato, passando l'intervallo di byte associati. All'interno del metodo di elaborazione, il client invia una chiamata di HttpWebRequest al server utilizzando lo stesso URL e internamente aggiunge un'intestazione di richiesta HTTP che contiene l'intervallo di byte fornito a tale metodo di elaborazione (ovvero, compresi: byte = 0-5242880, intervallo: byte = 5242880 10485760 e così via).

Nel computer server, l'implementazione dell'interfaccia IHttpAsyncHandler (System.Web.IHttpAsyncHandler) gestisce ogni richiesta in un thread separato, l'esecuzione del metodo HttpResponse.TransmitFile per scrivere l'intervallo di byte richiesto dal file del computer server direttamente nel flusso di rete, con alcun buffer esplicita, pertanto l'impatto di memoria sul server è quasi inesistenti. Il server invia la risposta con un codice di stato HTTP 206 (PartialContent) e aggiunge internamente l'intestazione della risposta HTTP che identifica l'intervallo di byte restituito (ovvero, Content-Range: byte 0-5242880/26214400, Content-Range: byte 5242880-10485760/26214400 e così via). Come ogni thread riceve la risposta HTTP nel computer client, scrive i byte restituiti nella risposta per la parte corrispondente del file sul disco rigido del computer client che è stato identificato nell'intestazione della risposta HTTP (Content-Range). Utilizza i/o file sovrapposto asincrono (per garantire la gestione dei / o di Windows non serializzare il / o le richieste prima dell'invio di pacchetti di richiesta dei / o al driver in modalità kernel per completare il file operazione di scrittura). Se più thread in modalità utente tutti non una scrittura di file e non è disponibile il file aperto per il / o sovrapposte asincrona, verranno serializzate le richieste e il driver in modalità kernel riceverà solo una richiesta alla volta. Per ulteriori informazioni sui / o sovrapposte asincrona, vedere "Guida del Driver per gestire più di un / o in un tempo richiesta" (bit.ly/1NIaqxP) e "Supporto dei / o asincrono" (bit.ly/1NIaKMW) sul sito Centro per sviluppatori di Hardware.

Per implementare l'asincronia nella nostra IHttpAsyncHandler, abbiamo registrare manualmente una struttura overlapped dei / o alla porta di completamento i/o e il pool di thread CLR esegue il delegato di completamento fornito in una struttura overlapped in un thread della porta di completamento. Questi sono gli stessi thread di porta di completamento utilizzato dalla maggior parte dei metodi asincroni predefiniti. In genere, è consigliabile utilizzare i nuovi metodi asincroni predefiniti per il lavoro più O associate ai /, ma in questo caso si vuole utilizzare la funzione HttpResponse.TransmitFile grazie alla possibilità di attesa per il trasferimento di file di grandi dimensioni senza di essi in modo esplicito il buffer nella memoria del server. È sorprendente!

Parallel. foreach viene utilizzato principalmente per operazioni associate alla CPU e mai veramente deve essere utilizzato nell'implementazione di un server grazie alla sua natura di blocco. Abbiamo ripartire il lavoro a un thread della porta di completamento dal ThreadPool CLR, invece di un thread di lavoro regolare dal ThreadPool CLR per impedire che riducono gli stessi thread utilizzati da IIS per soddisfare le richieste in ingresso. Inoltre, il modo più efficiente in cui i processi di porta di completamento funzionano in maniera limita l'utilizzo di thread nel server. Esiste un diagramma con una spiegazione più dettagliata elencato nell'esempio di codice di progetto nella sezione commenti nella parte superiore della classe IOThread che vengono evidenziate le differenze tra i thread di porta e un thread di lavoro nel ThreadPool CLR. Poiché la scalabilità a milioni di utenti non è l'obiettivo principale di questa utilità, che possiamo permetterci spendere i thread di server aggiuntivi necessari per eseguire la funzione HttpResponse.TransmitFile per conseguire il risparmio di memoria associato nel server durante il trasferimento di file enormi. Essenzialmente, ci stiamo commerciali la perdita di scalabilità causata dall'utilizzo di thread aggiuntivi per il server (anziché i metodi asincroni predefiniti con nessun thread), per utilizzare la funzione HttpResponse.TransmitFile, che utilizza la memoria server straordinariamente minimo. Sebbene sia all'esterno dell'ambito di questo articolo, facoltativamente, è possibile utilizzare i metodi asincroni incorporati in combinazione con i/o file privo di buffer per ottenere un risparmio di memoria simile con nessun thread aggiuntivo, ma da siamo consapevoli, tutto ciò che deve essere allineato settore e abbastanza difficile implementare correttamente. A questo, viene visualizzato che Microsoft è intenzionalmente rimosso l'elemento NoBuffering dall'enumerazione FileOptions per impedire effettivamente il / o file non memorizzato nel buffer, che richiedono un hacker manuale per rendere ancora possibile. Si erano piuttosto nervosi dei rischi associati all'implementazione non corretta e deciso di usare l'opzione meno rischioso di HttpResponse.TransmitFile, che è stato testato completamente.

FileDownloader.exe possibile avviare più thread, una chiamata distinta HttpWebRequest corrispondente a una parte separata (intervallo di byte) del file scaricato in base alla dimensione totale del file di ogni rilascio suddivisa in "Blocco di byte" specificato, come illustrato nella Figura 2.

È possibile ripetere tutti i thread che non riesce a scaricare la parte del file (l'intervallo di byte) specificata nella chiamata HttpWebRequest eseguendo semplicemente HttpWebRequest stessa chiamare (per solo tale intervallo di byte non riuscita) più volte fino a quando non andrà a buon fine, come illustrato nella Figura 3. Non si perdono le parti di file già scaricato, che nel caso di una connessione lenta può comportare molte ore di download di salvataggio. È possibile eliminare quasi impatto negativo di una connessione difettosa che viene costantemente passare alla modalità offline. E con più thread di progettazione il download di parti diverse del file nello stesso momento in parallelo, direttamente nel flusso di rete con alcun buffer esplicita, e nel disco rigido con i/o file sovrapposto asincrono, è possibile aumentare la quantità di download eseguite durante il periodo di tempo quando una connessione instabili è effettivamente in linea. Lo strumento continuerà a completare le restanti parti ogni volta che il collegamento di rete torna alla modalità online, senza perdere il lavoro. Desideriamo considerarla come più di un downloader file "non riproducibile", non il downloader di un file "può essere ripristinato".

La differenza può essere illustrata un esempio ipotetico. Che si desidera scaricare un file di grandi dimensioni che verrà tutta la notte. Quando si esce da lavoro e farne uso, si avvia il downloader di un file può essere ripristinato. Quando si arriva al lavoro la mattina, viene visualizzato il download del file non riuscita al 10% ed è pronto per essere ripreso. Ma quando riprende, sarà comunque necessario eseguire notturno nuovamente per completare il restante 90%.

Al contrario, si avvia il downloader riproducibile file quando si esce da lavoro e farne uso tutta la notte. Quando si arriva al lavoro la mattina, viene visualizzato il download del file non riuscita in un blocco al 10%, ma ha continuato a scaricare il resto dei blocchi del file. A questo punto, è necessario ripetere semplicemente che un blocco e termine. In presenza di tale blocco non riuscita, da un videogioco momentanea nel collegamento di rete, elimino viene terminato il restante 90% su tutta la notte quando il collegamento di rete veniva. htm.

Il client di download predefinito incorporato nel browser Web utilizzabile anche come client di download, utilizzando un URL, ad esempio https://localhost/DownloadPortal/Download?file=test.txt&chunksize=5242880.

Si noti che il parametro (chunksize = 5242880) anche facoltativo quando utilizza il browser Web come un client di download. Se omesso, il server scarica l'intero file in un blocco utilizzando la stessa HttpResponse.TransmitFile. Se incluso, verrà eseguito una chiamata HttpResponse.TransmitFile separata per ogni blocco.

Figura 4 è una panoramica generale della progettazione di DownloadHandler.dll quando si utilizza un browser Web che non supporta contenuto parziale come un client di download. Viene illustrato il flusso di elaborazione, come i blocchi del file sul disco rigido del computer server passano-through DownloadHandler.dll e il browser Web nel file sul disco rigido del computer del browser Web.

Figura 4 Panoramica ad alto livello di progettazione del flusso di elaborazione per DownloadHandler.dll (tramite Browser Web che non supporta contenuto parziale come Client)

Una funzionalità interessante della nostra implementazione dell'interfaccia IHttpAsyncHandler sul Server Web IIS è il supporto di "byte serving" inviando l'intestazione HTTP Accept-Ranges nella risposta HTTP (Accept-Ranges: byte), indicante i client servite le parti di un file (intervallo di contenuto parziale). Se il client di download predefinito all'interno del browser Web supporta contenuto parziale, può inviare il server dell'intestazione HTTP di intervallo nella richiesta HTTP (intervallo: byte = 5242880 10485760), e quando il server invia il nuovo parziale al client, verrà inviato nuovamente l'intestazione HTTP Content-Range all'interno di risposta HTTP (Content-Range: byte 5242880-10485760/26214400). Pertanto, a seconda di ciò che il browser Web in uso e il valore predefinito scaricare incorporate nel browser client, è possibile ottenere alcuni dei vantaggi come il client eseguibile autonomo. In ogni caso, la maggior parte dei browser verrà consentono di creare il proprio client di download personalizzati che possono essere inseriti nel browser, sostituendo il valore predefinito incorporato.

Configurazione di progetto di esempio

Per il progetto di esempio, è sufficiente copiare DownloadHandler.dll e IOThreads.dll nella directory \bin sotto la directory virtuale e inserire una voce nella sezione relativa ai gestori e sezione relativa ai moduli di Web. config, come illustrato di seguito:

<handlers>
  <add name="Download" verb="*" path="Download"
    type="DownloaderHandlers.DownloadHandler" />
</handlers>
<modules>
  <add name="CustomBasicAuthenticationModule" preCondition="managedHandler"
    type="DownloaderHandlers.CustomBasicAuthenticationModule" />
</modules>

Se è presente alcuna directory virtuale sul Server IIS, crearne uno con una directory \bin, renderla un'applicazione e assicurarsi che utilizza un Pool di applicazioni di Microsoft .NET Framework 4.

Il modulo di autenticazione di base personalizzato utilizza stesso, facile da utilizzare, AspNetSqlMembershipProvider utilizzato oggi, in molti siti Web ASP.NET archiviazione del nome utente e password necessaria per scaricare un file all'interno del database aspnetdb sul Server SQL. Uno dei vantaggi di AspNetSqlMembershipProvider utili è l'utente non dispone di un account nel dominio Windows. Istruzioni dettagliate su come installare AspNetSqlMembershipProvider e le impostazioni necessarie sul Server IIS per l'utente di configurare gli account e certificati SSL sono elencati nell'esempio di codice di progetto nella sezione commenti nella parte superiore della classe CustomBasicAuthenticationModule. Altre opzioni di configurazione avanzate per l'ottimizzazione del Server IIS utilizzate in genere già impostate dal reparto IT che gestisce i server e vengono esula dall'ambito di questo articolo, ma se non è il caso, sono disponibili nella libreria TechNet all'indirizzo bit.ly/1JRJjNS.

Completato. È sufficiente che.

Fattori interessanti

Il fattore più prestigiose interessante del progetto non è più veloce, ma è più flessibile e fault tolerance a interruzioni della rete causate da collegamenti di rete attendibili e instabile continuamente connessione in rete e non in linea. In genere, il download di un file, in un blocco su una connessione, genererà la velocità effettiva massima.

Esistono alcune eccezioni a questa regola, ad esempio un ambiente server con mirroring in un file viene scaricato in porzioni separate, recupero di ogni parte del file da un server mirror diversi, come illustrato nella univoci Figura 5. Ma in genere, download di un file su più thread è effettivamente più lento download di un file su un singolo thread, poiché la rete è in genere il collo di bottiglia. Tuttavia, la possibilità di ritentare esclusivamente le parti non riuscite del file da scaricare ripetutamente finché non vengono completate, senza dover riavviare il processo di download intero, plasma ci piace pensare a una sorta di quasi-la tolleranza di errore.

Figura 5 ipotetico miglioramenti futuri per simulare un'infrastruttura molto rudimentali Mirror

Inoltre, se un utente non di modificare la struttura come miglioramento futuro per simulare un'infrastruttura di server mirror estremamente rudimentale, come illustrato nella Figura 5, potrebbe forma ciò che può essere considerato come una sorta di quasi-ridondanza.

Essenzialmente, la progettazione consente di scaricare in modo affidabile un file in una rete inaffidabile. Un brevi interruzioni a singhiozzo il collegamento di rete non significa che è necessario ricominciare dall'inizio; In alternativa, è possibile ritentare semplicemente solo le parti del file che non è riuscita. Sarebbe interessante per la progettazione (che potrebbe renderlo ancora più resilienti) per archiviare lo stato di avanzamento corrente del download in un file sul disco rigido come viene eseguita l'operazione di download, pertanto è possibile ripetere essenzialmente un download interrotto anche su riavvio del computer client e l'applicazione client. Ma che sarà un esercizio a discrezione del lettore.

Un altro fattore interessante, paragonabile alla sua attuale importanza sopra descritto, consiste nell'utilizzare HttpResponse.TransmitFile sul server per scrivere i byte del file direttamente nel flusso di rete, con alcun buffer esplicita, ovvero per minimalize l'impatto sulla memoria del server. È sorprendente trascurabile come l'impatto è nella memoria del server, anche quando si scaricano file molto grandi.

Esistono tre fattori aggiuntivi che sono molto meno significativo, ma interessanti comunque.

In primo luogo, poiché la progettazione include sia il client front-end e il server back-end, si dispone del controllo completo sulla configurazione del server. In questo modo la libertà di modificare le impostazioni di configurazione che spesso notevolmente impedire il file di processo nei server di proprietà da altri e ha il controllo di download. Ad esempio, è possibile regolare il limite di connessione imposte per ogni indirizzo IP del client su un valore maggiore del limite di due connessioni normale. È inoltre possibile regolare il limite per ogni connessione client a un valore maggiore.

In secondo luogo, il codice del progetto di esempio all'interno il front-end client (FileDownloader.exe) e il server back-end (DownloadHandler.dll) può essere utilizzato come semplici e chiaro blocchi di codice di esempio che illustra l'utilizzo di richiesta e risposta intestazioni HTTP necessarie per agevolare gli intervalli di byte di contenuto parziale nel protocollo HTTP. È facile per vedere quali intestazioni di richiesta HTTP al client deve inviare per richiedere il byte gli intervalli e le intestazioni di risposta HTTP server deve inviare restituire gli intervalli di byte contenuto come parziale. Deve essere relativamente semplice modificare il codice per implementare la funzionalità di livello superiore nella parte superiore di questa semplice funzionalità di base o implementare alcune delle funzionalità più avanzate disponibili nei pacchetti software più sofisticati. Inoltre, è possibile utilizzare come modello iniziale semplice che rende relativamente semplice aggiungere il supporto per alcune delle altre intestazioni HTTP più avanzate, ad esempio Content-Type: multipart/byteranges, Content-MD5: digest md5, If-Match: tag di entità e così via.

In terzo luogo, poiché il progetto utilizza il Server Web IIS, è automaticamente trarre vantaggio da alcune delle funzionalità incorporate fornite dal server. Ad esempio, le comunicazioni possono essere crittografate automaticamente (tramite HTTPS con un certificato SSL) e compressi (utilizzando la compressione gzip). Tuttavia, potrebbe non essere consigliabile eseguire la compressione gzip in file molto grandi, se questa operazione genera una quantità eccessiva di stress sul server di CPU. Tuttavia, nel caso in cui la CPU del server possono spalla il carico aggiuntivo, l'efficienza di trasferimento dei dati compressi di dimensioni molto ridotte può talvolta fare la differenza nella velocità effettiva globale dell'intero sistema.

Miglioramenti futuri

Il codice di progetto di esempio fornisce solo la funzionalità di base minima necessaria per il downloader di file per il funzionamento. Il nostro obiettivo era mantenere la struttura semplice e facile da comprendere in modo è possibile utilizzare facilmente relativamente come base in base al quale aggiungere i miglioramenti e funzionalità aggiuntive. È semplicemente un punto di partenza e un modello di base. Molti miglioramenti aggiuntivi sarebbe essenziali prima anche possibile iniziare a essere utilizzato in un ambiente di produzione. Aggiunta di un livello più alto livello di astrazione che offre questa funzionalità aggiuntiva, più avanzati viene lasciata come un esercizio per il lettore. Tuttavia, si sarà expound in molti dei miglioramenti ancora più cruciali.

Il codice di progetto di esempio non include attualmente un checksum di hash MD5 per il file. Nel mondo reale, è essenziale per utilizzare una sorta di strategia di checksum di file per garantire il file scaricato nel client corrisponda al file sul server e che non sia stato alterato o alterato in alcun modo. Le intestazioni HTTP facilitano a che fare con l'intestazione (Content-MD5: digest md5). In effetti, incluso uno dei nostri prototipi prima esegue un checksum di hash MD5 per il file ogni volta che è stato richiesto il file e il posizionamento del digest nell'intestazione (Content-MD5: digest md5) prima che il file lasciato il server. Il client quindi eseguirebbe lo stesso checksum hash MD5 per il file ricevuto e verificato il digest risultante corrisponde il digest nell'intestazione (Content-MD5: digest md5) restituito dal server. Se non corrisponde, il file era stato alterato o danneggiato. Anche se il risultato è l'obiettivo di assicurare il file non viene modificata, i file di grandi dimensioni causa intenso utilizzo eccessivo della CPU sul server e ha impiegato troppo tempo per eseguire.

In realtà, richiederà probabilmente una sorta di livello della cache che non checksum hash MD5 di elaborazione sul file (in background) una volta per tutta la durata del file e archivia il digest risultante nel dizionario con il nome del file come chiave. Quindi una ricerca semplice dizionario è tutto ciò che serve per ottenere il digest per il file sul server e il digest può essere aggiunti all'intestazione di quando il file con un impatto minimo sulle CPU server lo lascia il server in un attimo.

Il codice di progetto di esempio inoltre non attualmente impedire un client utilizzando un numero enorme di thread e suddividere il file in un numero elevato di blocchi. Consente in sostanza un client "do deve eseguire" per garantire che è possibile scaricare un file. Nel mondo reale, sarebbe probabilmente necessario essere un tipo di infrastruttura che potrebbe imporre un limite sul client, in modo che un client non sarebbero in grado di assumere il controllo server e tutti gli altri client di mancanza di risorse.

Figura 5 illustra un ipotetico miglioramento futuro per simulare un'infrastruttura mirror molto rudimentali modificando la progettazione di fornire un elenco di coppie "intervallo di byte/nome nodo" come parametro di stringa di query URL, invece di parametro "chunksize" del progetto corrente. La progettazione corrente può essere modificata in modo relativamente semplice per ottenere ciascun blocco del file da un server diverso per l'iterazione semplicemente le coppie di "intervallo di byte/nome nodo" avvio di un oggetto HttpWebRequest per ogni coppia, anziché internamente l'iterazione per dividere la dimensione totale in blocchi in base al parametro "chunksize" e l'avvio di un oggetto HttpWebRequest per ogni blocco.

È possibile costruire l'URL per la classe HttpWebRequest sostituendo semplicemente il nome del server con il nome di nodo associato nell'elenco di coppie "intervallo di byte/nome nodo", l'aggiunta di un intervallo di byte associati all'intestazione HTTP di intervallo (ovvero, compresi: byte = 0 5242880) e quindi rimuovendo completamente l'elenco di "intervallo di byte/nome nodo" dall'URL. Una sorta di file di metadati può identificare in quali server si trovano le parti di un file e computer richiedente potrebbe quindi assemblare un file di parti del file che vengono distribuite in server diversi.

Se un file viene eseguito il mirroring su 10 server, la progettazione può essere modificata per ottenere la parte 1 del file da copia sul server mirror 1, parte 2 di file dalla copia di server mirror 2, parte 3 del file dalla copia mirror 3 server e così via. Anche in questo caso, sarebbe essenziale eseguire un checksum di hash MD5 per il file dopo aver recuperato tutte le parti del file e riassemblati completo di file sul client, per assicurarsi che nessun blocco erano danneggiato su qualsiasi server mirror e che in realtà ha ricevuto l'intero file. Si potrebbe anche ottenere un po' di fantasia e salvarlo al livello successivo facendo in modo che i server geograficamente distribuiti in tutto il paese compilazione alcuni intelligence elaborate nel codice che potrebbe determinare quali server sono in minor carico di elaborazione, quindi utilizzando tali server per soddisfare la richiesta restituisce i blocchi del file.

Avvolgendo

Per creare il downloader di file più rapide e scalabili, ma per crearne uno che è estremamente resistente alle interruzioni della rete temporaneo, non era l'obiettivo della progettazione.

Abbiamo rilevato grande sforzo per assicurarsi che la progettazione è estremamente semplice e chiaramente dimostrato come utilizzare le intestazioni di protocollo HTTP per intervalli di byte "byte serving" e il contenuto parziale.

Nella ricerca, è effettivamente trovato abbastanza difficile trovare un buon, deselezionare esempio di come eseguire l'operazione di byte HTTP semplice che servono e come utilizzare le intestazioni di intervalli di byte nel protocollo HTTP. La maggior parte degli esempi sono stati inutilmente complesse o utilizzate molte delle altre intestazioni per implementare funzionalità del protocollo HTTP, rendendo difficile la comprensione, tantomeno provare a migliorare o espandere in futuro molto più avanzate.

Si desidera fornire una solida base semplice che include solo il valore minimo necessario, pertanto, sarebbe relativamente facile da provare e aggiungere in modo incrementale ulteriori funzionalità avanzate nel tempo, o anche visitare finora per implementare un intero livello più alto livello di astrazione che aggiunge alcune delle funzionalità più avanzate del protocollo HTTP.

Volevamo semplicemente viene fornito un esempio semplice per ottenere informazioni da e compilare in futuro. Buon lavoro!

---

Doug Duernerè un software engineer senior con oltre 15 anni di progettazione e implementazione di sistemi di grandi dimensioni con le tecnologie Microsoft. Ha lavorato per più istituti bancari Fortune 500 e per una società di software commerciale che progettato e creato il sistema di gestione di rete distribuita su larga scala utilizzato per il dipartimento della difesa difesa informazioni sistemi Agenzia (Disabilita) per il "griglia informazioni globali" e lo stato del reparto. Ha un fanatico cuore, concentrandosi su tutti gli aspetti, ma piace gli ostacoli tecnici più complessi e difficili, specialmente quelle che tutti gli utenti è indicato "non può essere eseguite." È possibile contattarlo Duerner coding.innovation@gmail.com.

Wang Yeon registrazioneè un software engineer senior con oltre 15 anni di progettazione e implementazione di sistemi di grandi dimensioni con le tecnologie Microsoft. Inoltre, ha lavorato per un gruppo Fortune 500 istituto bancario e per una società di software commerciale che progettato e creato il sistema di gestione di rete distribuita su larga scala utilizzato per il dipartimento della difesa difesa informazioni sistemi Agenzia (Disabilita) per il "griglia informazioni globali" e lo stato del reparto. Ha inoltre progettato e implementato un sistema di certificazione Driver su larga scala per uno dei maggiori produttori di chip del mondo. Wang ha una laurea specialistica in informatica. Ha Ciba problemi complessi per cena ed è possibile contattarlo yeon_wang@yahoo.com.

Grazie ai seguenti esperti tecnici Microsoft per la revisione di questo articolo: Stephen Cleary e James McCaffrey