Scrivere un protocollo TCP o usare HTTP per il trasferimento di file?

0

Desidero scrivere un'applicazione lato server che consenta a diversi utenti di scambiare file (non oltre 3 MB) nel seguente modo: l'utente A si connette a (server) S. L'utente B si connette a S. Utente C collega S. Utente A invia un file. Gli utenti B e C "vedono" che un file era / è in fase di caricamento e inizia a scaricarlo.

La mia preoccupazione principale è la reattività. Voglio che il file arrivi a B e C non molto tempo dopo che A ha iniziato a caricare.

Ho pensato di farlo usando HTTP: l'utente A invia byte grezzi al server e il server salva il file localmente. A questo punto, gli utenti B e C vedono che è stato caricato un file e iniziano a scaricarlo.

La mia domanda: HTTP è il modo migliore per andare qui? O dovrei scrivere un'app che usa socket TCP e scrivere il mio protocollo? Se vado con le prese. Come posso stimare i requisiti di RAM del VPS in modo che possa consentire connessioni di trasferimento file N contemporaneamente?

    
posta Daniel 24.02.2013 - 09:18
fonte

3 risposte

1

Se questo è quello che vuoi:

(Client A) ---> (Server) ---> (Client B)

quindi la soluzione più semplice è quella di dividere il problema in due parti, fare in modo che il "Client A" invii il file al server, quindi fare in modo che "Client B" preleva il file una volta completamente caricato da "Client A". È possibile farlo facilmente con HTTP, e se i client utilizzano le tipiche connessioni a banda larga economiche asimmetriche disponibili a casa, probabilmente andrebbe bene: il 90% del tempo viene utilizzato dal client A per inviare il file al server, quindi 10 % è usato dal cliente B per prendere il file.

Se i client hanno entrambe connessioni simmetriche, allora la stessa soluzione probabilmente andrebbe ancora bene, dal momento che le connessioni simmetriche sono per lo più viste solo con i migliori provider. L'invio di 3 Mb sarebbe così veloce, non sarebbe nemmeno importante se si tratta di un lavoro a due stadi.

Se sei ambizioso e vuoi che il "Client B" inizi a scaricarlo non appena il primo byte colpisce il server, devi comunque usare HTTP, ma usa qualcosa sul server che ti permette di "bloccare" (es: non uno script PHP o simile). Dovresti comunque utilizzare HTTP perché HTTP è quasi universalmente disponibile, nessuno lo blocca, funziona tramite proxy. Se provi ad implementare il tuo servizio basato su TCP, dovrai risolvere lo stesso problema che dovrai risolvere con HTTP, ma per di più dovrai implementare nuovamente la parte "applicazione" di (come fa il cliente B a dire al server quale file catturare, ecc.). E soprattutto avrai a che fare con tutti i proxy e le porte TCP bloccate!

Un'altra opzione per lo scenario ambizioso è che il server implementa un servizio VPN (o un altro tipo di rete con tunnel), che entrambe le estremità si connettano al server e che il client A invii direttamente al client B.

    
risposta data 24.02.2013 - 22:12
fonte
9

Cosa c'è che non va con la semplice varietà da giardino vecchio FTP (File Transfer Protocol), o anche con TFTP (Trivial File Transfer Protocol)?

Certo, sono più vecchi del ricordo di tuo padre del suo primo bacio, ma funzionano ancora.

Ora, sia FTP che TFTP vogliono che il file sia sul server prima di servirlo per scaricare i client. Se quello che vuoi è far scorrere il file da A direttamente o tramite il tuo server, FTP e TFTP potrebbero non essere la soluzione giusta.

    
risposta data 24.02.2013 - 17:30
fonte
3

Probabilmente farei una dimostrazione del concetto usando http e controllando le prestazioni. Non serve reinventare la ruota se non è necessaria.

    
risposta data 24.02.2013 - 15:56
fonte

Leggi altre domande sui tag