Fino all'avviso per l'utente non compreso si può fare. Il problema è dopo perché si incappa nei limiti di http. O l'utente è in attessa di una risposta dal server in seguito ad una richiesta oppure lui deve fare il refresh ogni tot secondi.

3) realizzare un servizio windows "ospitato" da iis che faccia il lavoro. La tua pagina aspnet fara' una chiamata asincrona al servizio. Questo detto in maniera molto sintetica.

Perche' un timer? quando il servizio o il webservice finisce dovrebbe entrare in gioco il bello della chiamata asincrona (se non sbaglio il delegato utilizzato per iniziare) che intercetta anche la sua fine.

La cosa interessa anche a me xche' sto cercando di farla per ovviare ad un problema di timeout della pagina a seguito della richiesta di un'elaborazione che impiega molto tempo e risorse.

---

Modificato da riccardone_70 il 06 febbraio 2004 11.51 -

ricciolo ha scritto:

Sì ma il callback c'è sul server, non sul client. L'unico modo è un refresh a timer se non si vuole rischiare il timeout

No, non e' l'unico modo. Nel momento in cui effettuiamo una chiamata asincrona a un servizio windows o un web service, l'elaborazione si sposta su un nuovo thread. L'applicazione chiamante puo' fare quello che dici tu oppure nel momento in cui invoca il metodo in modo asincrono specifica anche il metodo che il delegato chiamera' quando sul server il processo avra' termine (callback).
Dall'msdn sull'argomento
.....
callback argument?Specifies an AsyncCallback delegate instance. If you specify a non-null value for this argument, the runtime calls the specified callback method when the asynchronous method completes. If this argument is a null reference, you must monitor the asynchronous operation to determine when it is complete.
....

---

Modificato da riccardone_70 il 06 febbraio 2004 20.32 -

ricciolo ha scritto:

...Fin qui ci siamo, il problema è avvisare l'utente che non sta sul server. A questo mi riferivo

Ci sono tre tecniche utilizzabili che si possono chiamare Pooling, Waiting e Callback.
La tecnica suggerita di utilizzare un timer ricade nelle prime due ma e' la peggiore perche' implica sovraccarico di traffico e occupazione di risorse. Puo' essere giustificata se si vuole ad esempio segnalare all'utente lo stato del processo in corso o condizionarne l'esecuzione.
Se invece si sceglie la strada di utilizzare un delegato che effettui il callback non siamo costretti ad utilizzare nessun "timer". Abbiamo a disposizione una serie di metodi e oggetti come ad esempio l'oggetto di tipo IAsyncResult che ci torna indietro il risultato dell'elaborazione nel metodo che abbiamo indicato al momento della chiamata asincrona grazie al delegato per il callback (AsyncCallback).