Cosa vorresti utilizzare per implementare un file server veloce e leggero?

Question

ho bisogno di avere come parte di un'applicazione desktop un file server, che dovrebbe rispondere il più velocemente possibile presentare le richieste di trasferimento (da client remoti, di solito si trova sulla stessa LAN). Ci saranno molte le richieste di file per i file di piccole dimensioni. Il server dovrebbe essere in grado di fornire sia servizi di upload e download.

Non sono stretti per qualsiasi tecnologia particual quindi sono aperto a qualsiasi linguaggio di programmazione, toolkit, librerie fino a quando si può essere eseguito su Windows.

La mia opinione iniziale è quello di andare con un / C ++ implementazione C utilizzando Windows Sockets o utilizzare i servizi forniti da librerie come Boost (ASIO o simili). Ho anche pensato di Erlang, ma che dovrò imparare e così i vantaggi di prestazioni dovrebbero giustificare l'aumento del tempo di sviluppo a causa di dover imparare la lingua.

DOPO EDIT: Apprezzo le risposte che dicono uso FTP o HTTP o in fondo tutto ciò che è stato già creato, ma considerando che si vuole ancora di scrivere uno da zero, cosa vorresti fare

?

Answer 1

Per frequenti upload di file di piccole dimensioni, il modo più veloce sarebbe quello di implementare il proprio protocollo proprietario, ma che richiederebbe una notevole quantità di lavoro - e anche che sarebbe stato non standard, il che significa l'integrazione futuro sarebbe difficile se non si è in grado di implementare il protocollo in qualsiasi client si sostenere. Se si sceglie di farlo comunque, questo è il mio suggerimento per un semplice protocollo:

1. Comando: 1 byte per identificare ciò che ti può fare:. (0x01 per la richiesta di upload, 0x02 per il download richiesta, 0x11 per la risposta caricati, 0x12 per la risposta download, etc)
nome
2. File: può essere fissato size o preceduto da un byte per la lunghezza (assumendo il nome è inferiore a 255 byte)
3. Checksum, MD5 per esempio (se richiesta di upload o di risposta download)
4. dimensioni del file (se richiesta di upload o di risposta download)
5. payload (se richiesta di upload o di risposta download)

Ciò può essere implementato su un socket TCP semplice. È inoltre possibile utilizzare UDP, evitando il costo di stabilire una connessione, ma in questo caso si hanno a che fare con il controllo di ritrasmissione.

Prima di decidere di implementare il proprio protocollo, un'occhiata a librerie HTTP come libcurl, si potrebbe rendere i vostri comandi HTTP standard di utilizzo del server come GET e POST per il download per il caricamento. Questo permetterebbe di risparmiare un sacco di lavoro e sarete in grado di testare il download con qualsiasi browser web.

Un altro suggerimento per migliorare le prestazioni è quello di utilizzare come archivio di file non è il file system, ma qualcosa di simile SQLite. È possibile creare una singola tabella che contiene una colonna char per il nome del file e una colonna blob per il contenuto del file. Dal momento che SQLite è leggero e fa un caching efficiente, avrete la maggior parte del tempo evitare il sovraccarico di accesso al disco.

Sto assumendo che non è necessario l'autenticazione del client.

Infine: anche se C ++ è la vostra preferenza per darvi prime velocità di codice nativo, raramente questo è il principale collo di bottiglia in questo tipo di applicazione. Molto probabilmente sarà l'accesso al disco e larghezza di banda di rete. Sto citano il presente perché in Java si sarà probabilmente in grado di fare una servlet per fare esattamente la stessa cosa (usando HTTP GET e POST per il download per l'upload) con meno di 100 righe di codice. Utilizzare Derby invece di SQLite in questo caso, che mettere servlet in qualsiasi contenitore (Tomcat, Glassfish, ecc) e il gioco è fatto.

Answer 2

Perché non basta andare con FTP ? Si dovrebbe essere in grado di trovare un server di attuazione adeguata in qualsiasi lingua, e le librerie di accesso client troppo.

E 'suona come un sacco di ruote reinvenzione. Certo, FTP non è l'ideale, e ha pochi punti strano, ma ... è lì, è normale, ben noto, e già molto ampiamente implementato.

Answer 3

Se tutte le macchine sono in esecuzione su Windows sulla stessa LAN, perché avete bisogno di un server a tutti? Perché non è sufficiente utilizzare la condivisione di file di Windows?

Answer 4

Vorrei suggerire di non usare FTP o SFTP, o di qualsiasi altra tecnica di connessione orientata. Invece, andare per un protocollo senza connessione o di tecnica.

La ragione è che, se avete bisogno di un sacco di piccoli file da caricare o scaricare, e la risposta deve essere il più veloce possibile, si vuole evitare il costo della creazione e distruggendo le connessioni.

Vorrei suggerire che si guarda sia utilizzando un'implementazione esistente o implementare il proprio server HTTP o HTTPS / servizio.

Answer 5

I tuoi colli di bottiglia sono probabile che provengono da una delle seguenti fonti:

• Hard Disk I / O - WD VelociRaptor si suppone di avere una velocità di accesso casuale di circa 100MB / s. Inoltre, è importante se lo si imposta come RAID0,1,5 o cosa abbienti. Alcuni leggono veloce ma scrivere lento. Trade-off.

• Rete I / O - Supponendo di avere i hard disk più veloci in una configurazione RAID veloce, a meno che non si utilizza Gbit di I / O, la rete sarà lenta. Se i tubi sono grandi, è ancora necessario per fornirle i dati.

• La cache in memoria - La cache in memoria file system dovrà essere abbastanza grande per tamponare tutta la rete di I / O in modo da non rallentare. Ciò richiederà una grande quantità di memoria per il tipo di lavoro che stai guardando.

• Struttura del file system - Supponendo che avete gigabyte vale la pena di memoria, quindi il collo di bottiglia sarà molto probabilmente la-struttura di dati che si utilizza per il file-system. Se la struttura del file system è ingombrante sarà rallentare se.

Supponendo che tutti gli altri problemi sono risolti, allora Vi preoccupate per la vostra applicazione stessa. Si noti, che la maggior parte dei colli di bottiglia sono di fuori del controllo del software. Pertanto, se si codifica in C / C ++ o utilizzare librerie specifiche, sarà comunque in balia del sistema operativo e l'hardware.

Answer 6

Sembra che si dovrebbe usare un (SSH) del server , è firewall / NAT protetto, sicuro, e già fa quello che vuoi e più. Si potrebbe anche usare SAMBA o Windows file sharing per un effetto ancora più semplice implementazione.

Answer 7

Perché non usare qualcosa di esistente, ad esempio un server Web normale gestisce un sacco di piccoli file (immagini) molto bene e veloce.

E un sacco di persone che già trascorso del tempo per ottimizzare il codice.

Il secondo vantaggio è che il trasferimento è fatto con HTTP che è un protocollo stabilito. Ed è facilmente passato a SSL se avete bisogno di più sicurezza.

Per gli arrivi, sono anche un problema con un modulo di script o personalizzato - con lo stesso metodo è anche possibile aggiungere l'autorizzazione

.

Fino a quando non è necessario cercare in modo dinamico i file Credo che questo sarebbe una delle soluzioni migliori.

Answer 8

Si tratta di una nuova parte a un'applicazione desktop esistente? Qual è l'obiettivo del server? E 'protegge i file che vengono caricati / scaricati e fornendo l'autenticazione e / o autorizzazione? Ha fornire un qualche tipo di struttura per le arrivi agli essere memorizzati in?

Una possibilità potrebbe essere quella di installare Apache HTTP Server sulla macchina e servire il file tramite questo. Utilizzare POST per caricare e arrivare a scaricare.

Se i clienti sono all'interno di una LAN potrebbe non solo condividere un'unità?