Perché è una lista di clienti ai quali si da un timing che so: a tizio invio alle 6:30 a caio alle 12:15 mentre da pippo ricevo alle 11:30 ecc.
Perché i file vengono generati dall'amministrazione o dal cliente in orari differenti il tutto gestito in un db mysql (circa 500 clienti).
L'eventuale ritardo non mi preoccupa perchè alla scadenza creo un coda di quel che devo fare ed è indipendente dal tempo, l'unica paura che avevo (anche se remota) è di saltare un invio o una ricezione se timer e clock non sono sincronizzati e quindi non creare questa lista di attività da fare ...
Si, ho capito che a Tizio invii alle 06:30 a Caio alle 12:15 e cosi via
Ed anche per le ricezioni, da Toni ricevi alle 07:00 da Mario alle 08:00 e cosi' via per tutti gli altri 500 nomi
Quel che non capisco e' perche' cerchi di sincronizzare il tuo sistema rispetto agli altri
E' molto piu' facile andare di asincrono che non sincronizzare il tutto
Nel senso che io farei una spedizione a Tizio "piu' o meno" alle 06:30, a Caio "piu' o meno" alle 12:15
Ed attenderei che Toni mi mandi i suoi file "grossomodo" alle 07:00 e che Mario mandi i suoi un po' quando vuole lui
Il fatto di far sapere a Tizio che hai mandato qualcosa, non puo' essere sapendo che sono passate le 06:30 (metodo sincrono), ma andando a vedere nella sua directory se c'e' qualcosa (metodo asincrono)
Stessa cosa per le ricezioni, per sapere se Mario mi ha mandato qualcosa posso attendere le 07.00 (metodo sincrono) oppure andare a vedere se nella sua directory c'e' qualcosa (metodo asincrono), e se c'e' gestirla e poi svuotarla pronta per la prossima ricezione
In conclusione, essendo unita' distanti geograficamente e collegate con mezzi non sempre affidabili quale potrebbe essere la linea internet, io userei un sistema asincrono per semplificare la comunicazione e renderla tollerante ad eventuali interruzioni di linea, pc corrispondenti non raggiungibili, e robe simili
In questo senso non capisco la necessita' di spaccare il secondo tra piu' sistemi diversi