Dunque... puoi spiegare perché la tua applicazione deve fare da proxy per il download di questi file? Forse così si riesce a darti un consiglio più mirato.
Vedo che lato server setti un cookie per la request, lo fai perché il client non può/deve venire a conoscenza delle credenziali usate per scaricare il file dall'altro server?
Permettimi subito una digressione: tu stai scrivendo un proxy a livello applicativo, forse la soluzione migliore sarebbe invece realizzarlo ad un livello più basso del modello OSI? Dovresti chiedere ad un amministratore di sistema, io non ho molte competenze in merito quindi potrei aver già detto delle stupidaggini :]
Inoltre guarda questo articolo di Daniele.
http://blogs.aspitalia.com/daniele/post2315/Usare-IIS-Reverse-Proxy.aspxPuò darsi che l'Application Requuest Routing Module ti sia di qualche utilità (?)
Invece, guardando il codice, ci sono diverse cose da considerare, la più importante delle quali è la poca scalabilità che una soluzione come quella offre.
Se anche non ci fossero problemi di timeout, cosa succederebbe se tanti utenti ti scaricano contemporaneamente un file da 180 mega?
Beh, vai ad esaurire velocemente le risorse del sistema:
- la RAM perché la pagina tiene il file in memoria fintanto che è in download (stai leggendo lo stream della response in un array di byte che poi ri-scrivi nella response);
- la banda, perché tutte le request andranno a scaricare i file contemporaneamente;
- il thread pool di IIS, perché il server non ti consente di tenere tante request attive in un dato momento. In realtà questo limite è abbastanza ampio, però idealmente se qualcuno decidesse di bloccarti l'applicazione potrebbe riuscirci benissimo facendo tante chiamate a quella pagina che va in esecuzione per minuti e minuti.
A questo punto ti do 2 consigli:
SE HAI ACCESSO AL SERVER CHE POSSIEDE I FILE
Fai in modo che sia direttamente quel server a fornire i file all'utente mediante una semplice richiesta GET. La tua applicazione dovrà solo fare una redirect alla pagina per il download. Se pensi che così i file siano troppo esposti e non vuoi che l'utente possa scaricare indiscriminatamente quello che vuole, allora la tua applicazione, subito prima di effettuare la ridirezione, dovrebbe informare l'altro server che "c'è un utente xyz con IP aaa.bbb.ccc.ddd che vorrebbe scaricare il file 123.txt, autorizzalo per tot minuti".
Così l'onere di servire il file non sarebbe più della tua applicazione.
SE NON HAI ACCESSO, O SE LA PERSONA CHE CE L'HA NON COLLABORA
Devi necessariamente inserire le richieste in una coda e svolgerne 1-2 alla volta. La tua applicazione, anziché andare a scaricare il file, mette invece un messaggio in una coda. Puoi usare la classe ConcurrentQueue a tale scopo.
http://msdn.microsoft.com/it-it/library/dd267265.aspxAll'utente farai immediatamente vedere questo messaggio: "Abbiamo ricevuto la tua richiesta di download, ti preghiamo di attendere che la procedura sia completa".
A questo punto, lato server ci sarà un BackgroundWorker che avrai istanziato nell'Application_Start del global.asax e che toglierà il primo elemento dalla coda e comincerà a scaricare il file.
Qui c'è un esempio di come usare il BackgroundWorker in un'applicazione web. E' un modo di far girare qualcosa fuori dalla request, così che l'operazione non sia soggetta a timeout.
http://www.dotnetfunda.com/articles/article613-background-processes-in-asp-net-web-applications-.aspxPeriodicamente esso farà rapporto sulla percentuale di completamento del download.
Aggiorna la pagina dell'utente ogni 10 secondi per fargli vedere a che punto è il suo download. Quando è completato, gli mostri il link al file che ormai si troverà sul tuo server.
Se vuoi che il file sia alla mercé di tutti, allora magari salvalo dentro una cartella che non sia direttamente accessibile da web, come /App_Data e poi glielo servi mediante un HttpHandler. Vedi qui l'esempio. Dato che hai file grandi è importante usare Response.TransmitFile.
http://www.aspitalia.com/script/944/Inviare-File-Grandi-Dimensioni-HttpHandler-ASP.NET.aspxciao
Modificato da BrightSoul il 30 maggio 2011 21.23 -