Trasferire file da un pc all'altro

[realtebo]

Ciao !

Mi sto scervellando per decidere quale soluzione è più pratica (e/o realizzabile) per svolgere quanto segue:

- Devo fare un piccolo sw che si occupa SOLO e SOLTANTO di trasferire UN singolo file da UN client ad UN altro. quindi niente multi-cliente, etc.

sto usando con divertimento le classi .NET dei sockets e dei tcp client e listener. tutto ok, il solo problema... è provare il software !!!!

Difatti: la mia idea era di usare una porta TCP solo. Il sw fa da client e da server. Praticamente resta in ascolto e, in caso io mando a prendere un file questo invia la richiesta all'altro client, di cui so sia ip che, appunto, port, altrimenti resta in idle; mentre sono idle, invece, potrei ricevere una richiesta file da un altro client, e in quel caso farei da server.

il mio problema è provare il software. Se eseguo due istanza dello stesso programma, nel momento in cui mi metto in listening con uno su una porta, e l'altro prova a connettersi come TCPclient alla stessa porta, il sistema, giustamente, mi dice che si possono avere solo UNA CONNESSIONE per volta per ogni combinazione di host/porta/protocollo

Al di là di qual'è il mio problema, come lo organizzaereste voi?

[ceccus]

Salve,
Beh, fossi in te, cambierei leggermente architettura :
cioè utilizzerei 2 porte.
La prima in trasmissione e la seconda in ricezione...come fanno tutti i software che fanno queste cose....aprendo 2 thread in ascolto sulle 2 porte.
A questo punto , anche la prova, sarebbe notevolmente semplificata....

Ciao !!

[realtebo]

intanto grazie per la risposta

sarei intenzionato a rimanere sull'unica porta per una questione di limitazione di eventuali configurazioni router / firewall, etc.

Per le prove ho, per ora, 'risolto' lanciando due istanze del software. Devo dire che mi sta venendo benino.

Per quanto riguarda il trasferirmento vero e proprio del file ho pensato, per limitare gli handshake al minimo (per ridurre la banda sprecata, penso anche ai poveri 56k come me...) di far dividere secondo una qualche logica in chunk il file da inviare. Così il server non deve fare nulla: il client gli comunica che chunk gli server, quindi il server lo invia e come ultimo pacchetto ne invia l'md5. i singoli pacchetti avranno un minimo di CRC giusto per farlo.

poi vedrò nella pratica come si comporta nella giungla del web

Penso che quando sarà pronta l'ossatura (quindi con logger di debug, non troppi controlli già fatti sul comportamente degli uTONTI, etc.) lo proporrò per la sezione beta tester.

[ceccus]

SAlve,
Prego...ci mancherebbe....
Il discorso delle 2 porte andava anche nell' ottica di sviluppare il componmente multithread , in modo da avere un thread in ascolto su ogni porta....così da inviare e ricevere contemporaneamente...Per il discorso della banda, hai pensato a comprimere/decomprimere i pacchetti ??

Ciao !!

[realtebo]

il programma prevede comunque un thread per l'applicazione principale, un thread per ascolto/ricezione + thread temporanei aperti a seconda delle necessità (tipo per i tentativi di connesione, con tanto di classe che contiene la sub oggetto del thread, la quale genera um evento con un parametro, rendendo così possibile sapere dal thread se la connessione è filata o meno, non male, vero ?).

L'invio e la ricezione contemporanea ho pensato di eslcuderlli apposta.

ho immaginato la cosa come il semplice recupero di una pagina html. Il server web invia dati solo su richiesta sulla mitica porta 80, se il client (un browser), cambia pagina, ferma l'ascolto e invia una nuova richiesta. Più che altro per semplicità. come dicevo sopra, le analisi sulle prestazioni sono, per ora, ancora lontane. Magari scopro che con un collegamento localhost->localhost va comunque stralento, nel qual caso decido cosa fare.

alla compressione dei dati non avevo pensato... mi chiedo: ma quanti dati è il caso di inviare contemporaneamente?

ho visto che il buffer predefinito è di 8 Kbyte, si può allargare ?

dovendo inviare dei dati binari (file, quasi mai sarà testo) come mi posso organizzare?

PS: sarei interessato all'algoritmo per l'md5, ma non lo trovo...

[ceccus]

Salve,
Per l'algoritmo MD5 , puoi contattarmi in PVT....
Per il buffer....sulle macchine Windows si può allargare....ma , francamente, non te lo consiglio....per ragioni di performances.
Se puoi, cerca di evitare "polling"...troppo dispendioso in termini di risorse...

Ciao !!