Il modo migliore per spostare i file di varie dimensioni in tutta lenta rete utilizzando .NET

Question

Sto costruendo una client / server .NET Remoting che saranno trasmette migliaia di file, di varie dimensioni (tutto da pochi byte a centinaia di MB), e mi piacerebbe un feedback sul miglior metodo per raggiungere Questo. Come la vedo io, ci sono un paio di opzioni:

• serializzare l'intero file nel mio oggetto i servizi remoti e trasmettere a tutti in una volta, indipendentemente dalle dimensioni. Questo sarebbe probabilmente il più veloce, ma un fallimento durante la trasmissione richiede che l'intero file essere ri-trasmesso, senza la possibilità di riprendere.
• Se la dimensione del file è più grande di qualcosa di piccolo (come 4KB), romperlo in pezzi da 4KB e remota quelli, ri-assemblaggio sul server. Oltre alla complessità di questo, è più lento a causa dei continui viaggi di andata e riconoscimenti, anche se un fallimento di qualsiasi un pezzo non perde molto tempo.
• Tra cui qualcosa di simile a un server FTP o SFTP con la mia domanda - il cliente notificherà il server che si comincia con i servizi remoti, caricare il file, quindi utilizzare i servizi remoti di comunicare di completamento. Mi piacerebbe contenere tutto nella mia app invece di richiedere un servizio FTP separato, ma sono aperto a questa opzione se è necessario.
• utilizzare un qualche tipo di connessione TCP dichiarato o WPF o qualche altro metodo di trasmissione che è costruito per gestire i fallimenti o è capace di fare una sorta di checkpoint / resume.
• Tutti gli altri mi manca?

Qual è il metodo di trasmissione più flessibile / affidabile? Non sono così preoccupati per la velocità, ma più su affidabilità - Voglio il file di muoversi, anche se è lentamente. Dal momento che il client e il server sarà multi-threaded, posso trasmettere più file allo stesso tempo se la connessione lo permette.

Grazie per il tuo feedback - mi butto in una taglia per ottenere alcune raccomandazioni sui modi la gente dovrebbe raggiungere questo obiettivo

.

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

Anche se calmh fa risponde alla domanda che stai chiedendo dal livello OSI 4 lato della vita, mi sento più come se stessi guardando più ai livelli dell'applicazione nella sua interrogazione. TCP fa sicuramente gestire tutto ciò che vanno dalla latenza, finestre di trasmissione, ecc sul lato rete della vita. Tuttavia, non determina direttamente cosa succede se un utente termina una sessione scaricare prematuramente e poi decide di prenderlo in seguito dove avevano lasciato.

Per rispondere alla tua domanda da una diversa angolazione, consiglio vivamente la suddivisione in blocchi il file in sezioni e indicizzazione per tutte le connessioni, indipendentemente dalla velocità. Essi possono quindi essere ri-assemblati di nuovo sul client una volta che l'intero file viene scaricato. Questo permette all'utente di mettere in pausa e riprendere sessioni di download.

Per quanto riguarda la determinazione della velocità, ci possono essere metodi di pre-costruite per fare questo, ma un metodo che si potrebbe usare è solo costruire il proprio test di velocità: Invia 1 MB al client (upload) e lo hanno inviare una risposta, una volta ricevuta. 1100 diviso per il tempo impiegato per ottenere la risposta indietro dal client, è la kb / s prende il client per scaricare dal server. E viceversa per testare caricati dal client.

Per quanto riguarda la trasmissione, mi sento di raccomandare utilizzando tecnologie esistenti. SFTP supporta il trasferimento di dati crittografati autenticato . Si tratta essenzialmente di FTP, ma su SSH. Non ci dovrebbero essere le API disponibili da qualche parte per l'interazione con questo.

Una nota a parte, non ho mai fatto niente nella misura in cui si parla, ma si spera mie idee almeno dare un paio di opzioni da considerare.

Answer 3

Questo è ciò che il protocollo TCP si è fatto per, e messo a punto per il corso di decenni o di prova difficile. Remoting è fatto per piccole chiamate RPC, non trasferisce i file di grandi dimensioni. Si dovrebbe semplicemente utilizzare un socket TCP per la trasmissione dei dati, e lasciare che i protocolli di livello inferiore si preoccupano di latenza, le finestre di trasmissione, MTU, ecc.