menu di navigazione del network

Tempi di consegna SdI


(Lucio Landi) #342

Cavolo Federico!!! Non aspetti nemmeno di vedere le belle email con i CSV che arriveranno a partire da domani!!! Oltre alla bellissima funzione di download massivo delle ricevute promessa entro gennaio 2019


(Romolo Manfredini) #343

Facevo solo caso ora alla genialata del client sftp di sogei…

Feb  5 22:44:51 fe internal-sftp[55874]: session opened for local user sogei from [217.175.54.31]
Feb  5 22:44:51 fe internal-sftp[55874]: received client version 3
Feb  5 22:44:51 fe internal-sftp[55874]: realpath "."
Feb  5 22:44:51 fe internal-sftp[55874]: realpath "/DatiDaSdI"
Feb  5 22:44:51 fe internal-sftp[55874]: stat name "/DatiDaSdI"
Feb  5 22:44:51 fe internal-sftp[55874]: stat name "/DatiDaSdI/FO.XXXXXXXXXXX.2019035.2220.001.zip"
Feb  5 22:44:51 fe internal-sftp[55874]: sent status No such file
Feb  5 22:44:51 fe internal-sftp[55874]: open "/DatiDaSdI/FO.XXXXXXXXXXX.2019035.2220.001.zip" flags WRITE,CREATE,TRUNCATE mode 0777
Feb  5 22:44:51 fe internal-sftp[55874]: close "/DatiDaSdI/FO.XXXXXXXXXXX.2019035.2220.001.zip" bytes read 0 written 251342
Feb  5 22:44:51 fe internal-sftp[55874]: lstat name "/DatiDaSdI/FO.XXXXXXXXXXX.2019035.2220.001.zip"
Feb  5 22:44:51 fe internal-sftp[55874]: session closed for local user sogei from [217.175.54.31]
Feb  5 22:45:05 fe internal-sftp[55958]: session opened for local user sogei from [217.175.54.31]
Feb  5 22:45:05 fe internal-sftp[55958]: received client version 3
Feb  5 22:45:05 fe internal-sftp[55958]: realpath "."
Feb  5 22:45:05 fe internal-sftp[55958]: realpath "/DatiDaSdI"
Feb  5 22:45:05 fe internal-sftp[55958]: stat name "/DatiDaSdI"
Feb  5 22:45:05 fe internal-sftp[55958]: posix-rename old "/DatiDaSdI/FO.XXXXXXXXXXX.2019035.2220.001.zip" new "/DatiDaSdI/FO.XXXXXXXXXXX.2019035.2220.001.zip.p7m.enc"
Feb  5 22:45:05 fe internal-sftp[55958]: lstat name "/DatiDaSdI/FO.XXXXXXXXXXX.2019035.2220.001.zip.p7m.enc"
Feb  5 22:45:05 fe internal-sftp[55958]: session closed for local user sogei from [217.175.54.31]

Da una disamina del precedente lo deduco che:

  1. Aprono la sessione, copiano il file, verificano che il file sia stato copiato, chiudono la sessione.
  2. Riaprono la sessione (infatti il PID del processo ssh è cambiato), rinominano il file, verificano che sia stato rinominato, richiudono la sessione

Ma porca t…a fare tutto dentro una sessione senza raddoppiare le connessioni e introdurre i ritardi dei vari handshaking era troppo ottimizzato ??? Perdono più tempo a chiudere e riaprire la sessione (dall’analisi dei log in media circa 6sec) che a trasferire il file (praticamente istantaneo).
Ma un po’ di profiling no ???
Notare che questo frullio di connessioni avviene per ogni file trasferito (solo 200 nell’ultima ora)…


(Paolo) #344

Incredibile, senza contare il fatto che se io ‘passo’ dalla cartella nello step1, mi ritrovo il file non ancora rinominato (mi è successo almeno 3 volte)!


(AndreaV) #345

@dscaravaggi Questi codici destinatario che citi sono quelli che avete voi ‘in anagrafica’ oppure c’e’ un modo per vedere quale è stato poi davvero usato da SDI per la consegna ? Perché con il fatto che su area fatture e corrispettivi uno può indicare un destinatario preferenziale associato alla sua P.Iva, il destinatario reale non è noto (a meno che appunto non si veda da qualche parte…).

Da noi il destinatario più presente in anagrafica è 000000 (da noi caldamente suggerito ai clienti).
Ad enorme distanza abbiamo M5UXCR1, poi la metà di quest’ultimo ha KRRH6B9 e i due terzi di quest’ultimo USAL8PV e altrettanti SUBM70N. Segue W7YVJK9 e poi altri minori.


(Diego Scaravaggi) #346

Ciao @avb2b

No è esattamente come dici tu, ma i 7 zeri non si possono classificare, eseguire una statistica sarebbe senza valore, perché vengono instradate ognuna al proprio intermediario scritto su F&C.


(Diego Scaravaggi) #347

Interessante, quindi a voi Aruba KRRH6B9 sta davanti a SUBM70N Zucchetti e USAL8PV Profis Sistemi.


(Vladan Bato) #348

In realtà questo è un bene! Altrimenti rischieresti di leggere un file parziale, mentre ci stanno ancora scrivendo dentro. La rinomina di un file invece è atomica (almeno nei sistemi unix) . Questo trucco del “creo un file temporaneo e solo dopo che ho finito di scriverci lo rinomino” è usatissimo in ambiente unix, proprio per la garanzia di atomicità dell’operazione.
Anche se sarebbe meglio se dal nome del file si capisse chiaramente che è un file temporaneo e comunque non si spiega perché non facciano tutto in un’unica sessione.


(Diego Scaravaggi) #349

veramente in ftp il rename sono 2 operazioni: https://tools.ietf.org/html/rfc959

RENAME FROM (RNFR)

        This command specifies the old pathname of the file which is
        to be renamed.  This command must be immediately followed by
        a "rename to" command specifying the new file pathname.

     RENAME TO (RNTO)

        This command specifies the new pathname of the file
        specified in the immediately preceding "rename from"
        command.  Together **the two commands** cause a file to be
        renamed.

(Vladan Bato) #350

Veramente qui stiamo parlando di SFTP, non di FTP.

La versione del protocollo SFTP attualmente usata (la 3) ha un unico comando per rinominare un file, ma nelle specifiche non c’è scritto se l’operazione debba essere atomica o no, ma all’atto pratico, probabilmente lo è (per il semplice motivo che il sistema operativo implementa questa operazione in modo atomico).
Versioni successivo del protocollo SFTP (rimaste sotto forma di bozze, mai usate nella pratica) prevedono invece dei flag per il comando SSH_FXP_RENAME per specificare se l’operazione debba essere atomica o no.


(Diego Scaravaggi) #351

io non l’ho trovato https://tools.ietf.org/html/rfc4217, sftp aggiunge tutti i dettagli di auth all’RFC FTP
però se sostieni cose diverse ti invito a citare il paragrafo della specifica.

… ora ansi IETF ISO, passano i mesi a disquisire se le formiche si devono radere i peli oppure no, figurati se lasciano libero arbitrio sull’atomività della RENAME…


(Vladan Bato) #352

Quello che citi tu è il protocollo FTPS ovvero “FTP over SSL/TLS”. Quello usato dal SdI è il protocollo SFTP, ovvero “SSH File Transfer Protocol”, che è un’estensione del protocollo SSH e non ha niente a che fare con FTP.
Per citare la pagina di Wikipedia: https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol

Not to be confused with Simple File Transfer Protocol, FTP over SSH, or FTPS.

Per SFTP non c’è un RFC, ma solo una valanga di draft. Quello effettivamente usato è il draft n. 2 (l’ultimo per la versione 3 del protocollo), che trovi qui:
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#section-6.5
Il paragrafo che ti interessa è il 6.5.

MA quello non è il comando effettivamente usato in questo caso. Questo perché, in effetti, il comando SSH_FXP_RENAME non viene implementato in maniera atomica (quantomeno in OpenSSH), dato che la specifica dice che se esiste già un file con il nome nuovo, questo va eliminato.
Se guardi il log di sopra, vedrai che viene usato il comando posix-rename che è un’estensione introdotta da OpenSSH (ma implementata anche da altri server SSH) che invece esegue l’operazione in maniera atomica.
Trovi le specifiche qui: https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL?rev=HEAD

Comunque il mio commento iniziale voleva essere una spiegazione del perché probabilmente fanno le cose in due passaggi (creazione file temporaneo, rinomina). È una tecnica comunemente usata per evitare race condition. Che sia efficace o meno è un altro discorso.


(Romolo Manfredini) #353

Il farlo in due passaggi torna, crei un file con un nome X.Y ma il software deve leggere solo un file che ha nome X.Y.enc.
Se caricassero subito un file con il nome X.Y.enc il software potrebbe andare a leggere un file ancora in fase di scrittura (la cosa andrebbe quindi gestita con semafori).
Quello che non mi torna è la chiusura della sessione fra l’upload e il rename… non capisco come usare due sessioni possa evitare race condition…


(leonardo) #354

Ad oggi, riscontriamo nuovamente qualche problema nelle consegne.
Alcuni file presenti in F&C ma mai consegnati al nostro canale (sono passati più di 7 giorni) DatiDaSdi.
Inoltre alcune fatture (DatiVersoSdi) trascorsi i 5 giorni non hanno ancora ricevuto l’identificativoSdi.
Sta succedendo nuovamente anche a voi?


(Federico Crepaldi) #355

:sob:
C’era d’aspettarselo col fine mese. Supporti inviati il 5/2, secondo F&C inviati il 7/2…
Io comunque mi son lasciato tentare e sto passando al lato oscuro: ho chiesto l’accreditamento SDICoop e sono in attesa dei certificati…


(Paolo) #356

Assolutamente si. Stamattina ho ricevuto esiti del 04/02, mi mancano ancora diversi esiti nonché tantissime ricevute di consegna…


(Diego Scaravaggi) #357

Ciao, lato SDICoop direi “benino”, più indietro del solito ma giusto per darvi un dato
gli invii del 4 Febbraio confermati al 99.8% eccetto…

codice destinatario E06UCUD (Unimatica per CNDCEC Consiglio Nazionale Dott Com etc…)

con 6 fatture ancora non confermate, …però se leggete i vari forum qui siamo ai limiti della barzellatta…

:mask:


(leonardo) #358

A me invece rode il C**O! Se offri un servizio lo offri allo stesso modo, sia che questo sia di una tipologia, sia che sfrutti tecnologie differenti. Non esiste che un servizio funzioni meglio di un’altro, perchè ho perso tempo, fatica, bestemmie e denaro (nel senso del tempo perso da poter dedicare ad altro).
Ho scelto questa “tipologia” (SFTP) perchè ritengo SOAP (ci ho lavorato 13 anni in altri ambiti) una tecnologia vecchia, lenta, inutilmente pesante ed obsoleta (ma è un’opinione personale dettata da anni di esperienza), non che sftp sia più moderna, lungi da me!!!
Ritornando al punto, se decidi di utilizzare tecnologie differenti, lo sviluppo dovrà essere affrontato con la massima accuratezza altrimenti, bisogna avere il coraggio di ammettere le proprie “deficienze” e dire… fino ad ora abbiamo scherzato… da domani si lavora solo con una tecnologia etc etc…
Ovviamente assumendosi le responsabilità legali che questo comporterebbe.


(Diego Scaravaggi) #359

Ciao @leonardo72

se dici che SOAP WSDL è vecchi rispetto a REST microservices posso concordare, ma SFTP non è nemmeno un’alternativa è un canale di transport.

Ora fra: SNA, RPC, Corba, DCOM, JEE, IBM/MQ e soap WDSL,

fra questi qua io rifarei la scelta SOAP., (anche se SNA non e’ male)


(Vladan Bato) #360

Infatti, non c’entra niente. Quando dicevo “due passaggi” mi riferivo solamente alla creazione del file temporaneo e la successiva rinomina (invece che scrivere direttamente nel file finale). Farlo in due sessioni separate non serve assolutamente a nulla. Forse i programmatori SOGEI avevano un buon motivo per farlo così o forse semplicemente non si sono posti il problema.


(leonardo) #361

Ciao @dscaravaggi ,
cosa significa che SFTP non è un’alternativa, ma un canale di Transport?
Il canale SFTP è un’alternativa al canale Soap o almeno così è specificato. Ho due scelte!
Scelsi FTP/SFTP perchè ritenevo l’alternativa più veloce ed immediata.
Poi ovviamente tutto dipende da chi e come lo sviluppa.
PS. ho ben specificato nel dire che tale soluzione (SFTP) non è per nulla moderna, ma se mi dai una scelta, personalmente tendo a scegliere quella che a me sembra più conveniente.