Il modo migliore per spostare file di varie dimensioni su reti lente usando .NET

Question

Sto costruendo un client/server remoting .NET che trasmetterà migliaia di file, di varie dimensioni (da pochi byte a centinaia di MB) e vorrei un feedback sul metodo migliore per raggiungere questo obiettivo. Come la vedo io, ci sono un paio di opzioni:

• Serialize l'intero file nel mio oggetto i servizi remoti e trasmettere a tutti in una volta, indipendentemente dalle dimensioni. Questo probabilmente sarebbe il più veloce, ma un errore durante la trasmissione richiede che l'intero file sia ritrasmesso, senza alcun modo di riprendere.
• Se la dimensione del file è maggiore di qualcosa di piccolo (come 4KB), suddividerla in blocchi 4KB e remota, riassemblando il server. Oltre alla complessità di questo, è più lento a causa di continui viaggi di andata e ritorno, anche se un fallimento di un singolo pezzo non perde molto tempo.
• Includendo qualcosa come un server FTP o SFTP con la mia applicazione, il client informerà il server che sta iniziando a utilizzare il servizio remoto, caricherà il file, quindi utilizzerà il servizio remoto per notificare il completamento. Mi piacerebbe contenere tutto nella mia app invece di richiedere un servizio FTP separato, ma sono aperto a questa opzione se è necessario.
• Utilizzare una sorta di connessione TCP dichiarata o WPF o un altro metodo di trasmissione creato per gestire i guasti o in grado di eseguire una sorta di checkpoint/ripresa.
• Gli altri mi mancano?

Qual è il metodo di trasmissione più flessibile/affidabile? Non sono preoccupato per la velocità, ma per l'affidabilità, voglio che il file si muova, anche se lentamente. Poiché il client e il server saranno multi-thread, posso trasmettere più file contemporaneamente se la connessione lo consente.

Grazie per il vostro feedback - fornirò una taglia per ricevere alcune raccomandazioni sui modi in cui le persone lo realizzerebbero.

Answer 1

BITS (background Intelligent Transfer Service) è una buona soluzione. Ha anni di esperienza costruito nel

Alcuni punti di partenza sono

• http://sharpbits.codeplex.com/
• http://www.codeproject.com/KB/cs/Managed_BITS.aspx
• http://msdn.microsoft.com/en-us/magazine/cc188766.aspx
• http://www.simple-talk.com/dotnet/.net-tools/using-bits-to-upload-files-with-.net/

Answer 2

Questo è lo stesso TCP per cui è stato progettato e ottimizzato per decenni o duri test. I servizi remoti sono fatti per chiamate RPC di piccole dimensioni, non per trasferimenti di file di grandi dimensioni. Dovresti semplicemente usare un socket TCP per trasmettere i dati e lasciare che i protocolli di livello inferiore si preoccupino della latenza, finestre di trasmissione, MTU, ecc.

Answer 3

Sebbene calmh risponda alla domanda che stai chiedendo dal lato 4 del livello OSI vita, mi sento più come se tu guardassi di più ai livelli di domanda nella tua domanda. TCP sicuramente gestisce tutto ciò che va dalla latenza, alle finestre di trasmissione, ecc. Sul lato della rete della vita. Tuttavia, non determina direttamente cosa succede se un utente termina prematuramente una sessione di download e poi decide di riprenderlo più tardi da dove erano stati interrotti.

Per rispondere alla tua domanda da un'angolazione diversa, ti consiglio caldamente di dividere il file in sezioni e indicizzandole per tutte le connessioni, indipendentemente dalla velocità. Possono quindi essere riassemblati nuovamente sul client una volta scaricato l'intero file. Ciò consente all'utente di mettere in pausa le sessioni di download e riprendere.

Per quanto riguarda la determinazione della velocità, potrebbero esserci metodi predefiniti per eseguire questa operazione, ma un metodo che è possibile utilizzare è semplicemente creare il proprio test di velocità: Inviare 1 MB al client (upload) e inviarlo una risposta una volta ricevuta. 1100 diviso per il tempo impiegato per ottenere la risposta dal client, è il KB/s che richiede al client di scaricare dal server. E viceversa per testare il caricamento dal client.

Per quanto riguarda la trasmissione, consiglierei di utilizzare le tecnologie esistenti. SFTP supporta il trasferimento dati crittografato autenticato. È fondamentalmente FTP, ma su SSH.Ci dovrebbero essere API disponibili da qualche parte per interagire con questo.

In una nota a margine, non ho mai fatto nulla di cui tu parli, ma spero che le mie idee ti diano almeno un paio di opzioni da considerare.