Menu
▾
▴
openpec-devel — OpenPEC developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(17) |
May
(22) |
Jun
(9) |
Jul
(8) |
Aug
(8) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2008 |
Jan
|
Feb
(8) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Fanton F. <fa...@ks...> - 2004-06-15 14:03:05
|
Possibili soluzioni Per mantenere la mail in coda ed effettuare nuovi tentativi in caso di = errore dobbiamo tenere traccia delle fasi che la mail supera con = successo. Cio' implica: 1. aggiungere ad OpenPec una coda 2. associare ad ogni mail un identificativo che ci permetta di tracciare = le=20 fasi dell'elaborazione per non replicarle in caso di insuccesso =20 La prima ipotesi implica ripensare l'architettura di base ed aggiungere = un=20 processo che sovrintende all'amministrazione della coda: OpenPec = comincerebbe ad assomigliare sempre piu' ad un MTA vero e proprio ed = avrebbe un overhead da considerare. La seconda ipotesi non e' cosi' banale: trovare un ID che mi permetta di = identificare la mail in maniera univoca e di riconoscerla quando l'MTA = la=20 ripropone. Consideriamo che la mail arriva ad OpenPec tramite, per adesso, = transazione=20 SMTP quindi, per costruirci l'ID, non abbiamo altre informazioni che = quelle=20 contenute nella mail stessa. Ricordiamoci che non possiamo basarci su "Message-ID" visto che non e' = reso=20 obbligatorio da nessun RFC e se viene aggiunto dal MUA, l'MTA non lo = tocca. Lo stesso riguarda il campo "Date". Una soluzione potrebbe essere far aggiungere un header fittizio dal MTA = ma=20 per alcuni di loro potrebbe implicare un costo: per Sendmail credo basti = smanettare un po' con sendmail.cf mentre per Postfix dobbiamo usare un=20 programma esterno (con content_filter). Il problema pero' e' limitato solo alle mail provenienti dal MUA = (direttamente dal mittente) ossia al punto di accesso mentre per i = rimanenti casi avremmo a che fare con documenti di trasporto che, da = specifiche, hanno l'header "Message-ID" garantito univoco sul dominio. Tutto sommato sembra che la seconda soluzione sia la migliore: . l'MTA dovra' aggiungere a tutte le mail provenienti dal canale sicuro = un header fittizio (andrebbe bene un timestamp) . OpenPec si crea un ID dal haeder e lo utilizza per ricordarsi i passi = compiuti dalla mail -----Messaggio originale----- Da: Fanton Flavio=20 Inviato: marted=EC 15 giugno 2004 16.01 A: ope...@li... Oggetto: R: [Openpec-devel] Ridondanza dei messaggi Una semplice soluzione al problema e' restituire al MTA un codice = d'errore di tipo 5 che manifesta il verificarsi di un problema non = risolvibile con la=20 conseguenza di eliminare la mail dalla coda. Facciamo pero' un'ulteriore considerazione: un sistema di posta certificata e' un sistema a valore legale che = garantisce=20 il mittente dall'inalterabilita' del messaggio e lo tutela nei confronti = della consegna dello stesso: il sistema deve essere affidabile. Affidabilita' significa anche operare il massimo sforzo affinch=E8 la = mail=20 raggiunga il destinatario. -----Messaggio originale----- Da: Fanton Flavio=20 Inviato: marted=EC 15 giugno 2004 16.00 A: ope...@li... Oggetto: [Openpec-devel] Ridondanza dei messaggi Salve, vorrei esporre un problema che =E8 venuto fuori durante l'analisi=20 dell'architettura di OpenPec: la possibile ridondanza dei messaggi. Il punto della situazione: l'MTA inoltra a OpenPec le mail che arrivano in ingresso; OpenPec riceve la mail e tiene aperta la connessione con l'MTA fino a = che non=20 ha terminato l'elaborazione. Le situazioni a cui ci possiamo trovare davanti possono essere cosi'=20 sintetizzate: 1. punto di accesso . emissione ricevuta di accettazione (sempre locale) . generazione doc. di trasp. . delivery doc. di trasp. 2. punto di ricezione . emissione (eventuale) ricevuta di presa in carico (sempre remota) . emissione (eventuale) anomalia di trasp. 3. punto di consegna . consegna doc. di trasp. (sempre locale) . emissione ricevuta di avv. cons. Il problema Supponiamo che (punto 1) la ric. di acc. venga emessa correttamente e si = verifichi=20 un errore nella generazione o nel delivery del doc. di trasp.;=20 se restituiamo al MTA un errore di tipo 4 la mail viene mantenuta in = coda e=20 ripresentata successivamente provocando una nuova emissione della = ricevuta fino a=20 problema concluso: il risultato finale e' che il mittente si ritrovera' = un numero di=20 ricevute di acc. pari al numero dei problemi + 1. A parte la confusione del mittente ricordiamo che ogni ricevuta ha = valore legale. Lo stesso problema si presenta nel punto di ricezione e consegna: = soprattutto in=20 quest'ultimo potrebbe ingenerarsi una ben piu' grave emissione anomala = di=20 documenti di trasporto identici non coerenti con le ric. di avv. cons.. Ricordiamo inoltre che OpenPec non scinde "fisicamente" i tre punti = summenzionati per=20 ottimizzare le prestazioni:=20 per mail locali->locali i punti 1 e 3 utilizzano la stessa connessione = con MTA, lo stesso per mail remote->locali (punto 2 e 3). Questo significa che se il problema si verifica nell'ultima fase tutte = quelle precedenti=20 vengono nuovamente eseguite non appena l'MTA ripropone la mail. flazan ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Openpec-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openpec-devel ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Openpec-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openpec-devel |
|
From: Fanton F. <fa...@ks...> - 2004-06-15 14:00:16
|
Una semplice soluzione al problema e' restituire al MTA un codice = d'errore di tipo 5 che manifesta il verificarsi di un problema non = risolvibile con la=20 conseguenza di eliminare la mail dalla coda. Facciamo pero' un'ulteriore considerazione: un sistema di posta certificata e' un sistema a valore legale che = garantisce=20 il mittente dall'inalterabilita' del messaggio e lo tutela nei confronti = della consegna dello stesso: il sistema deve essere affidabile. Affidabilita' significa anche operare il massimo sforzo affinch=E8 la = mail=20 raggiunga il destinatario. -----Messaggio originale----- Da: Fanton Flavio=20 Inviato: marted=EC 15 giugno 2004 16.00 A: ope...@li... Oggetto: [Openpec-devel] Ridondanza dei messaggi Salve, vorrei esporre un problema che =E8 venuto fuori durante l'analisi=20 dell'architettura di OpenPec: la possibile ridondanza dei messaggi. Il punto della situazione: l'MTA inoltra a OpenPec le mail che arrivano in ingresso; OpenPec riceve la mail e tiene aperta la connessione con l'MTA fino a = che non=20 ha terminato l'elaborazione. Le situazioni a cui ci possiamo trovare davanti possono essere cosi'=20 sintetizzate: 1. punto di accesso . emissione ricevuta di accettazione (sempre locale) . generazione doc. di trasp. . delivery doc. di trasp. 2. punto di ricezione . emissione (eventuale) ricevuta di presa in carico (sempre remota) . emissione (eventuale) anomalia di trasp. 3. punto di consegna . consegna doc. di trasp. (sempre locale) . emissione ricevuta di avv. cons. Il problema Supponiamo che (punto 1) la ric. di acc. venga emessa correttamente e si = verifichi=20 un errore nella generazione o nel delivery del doc. di trasp.;=20 se restituiamo al MTA un errore di tipo 4 la mail viene mantenuta in = coda e=20 ripresentata successivamente provocando una nuova emissione della = ricevuta fino a=20 problema concluso: il risultato finale e' che il mittente si ritrovera' = un numero di=20 ricevute di acc. pari al numero dei problemi + 1. A parte la confusione del mittente ricordiamo che ogni ricevuta ha = valore legale. Lo stesso problema si presenta nel punto di ricezione e consegna: = soprattutto in=20 quest'ultimo potrebbe ingenerarsi una ben piu' grave emissione anomala = di=20 documenti di trasporto identici non coerenti con le ric. di avv. cons.. Ricordiamo inoltre che OpenPec non scinde "fisicamente" i tre punti = summenzionati per=20 ottimizzare le prestazioni:=20 per mail locali->locali i punti 1 e 3 utilizzano la stessa connessione = con MTA, lo stesso per mail remote->locali (punto 2 e 3). Questo significa che se il problema si verifica nell'ultima fase tutte = quelle precedenti=20 vengono nuovamente eseguite non appena l'MTA ripropone la mail. flazan ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Openpec-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openpec-devel |
|
From: Fanton F. <fa...@ks...> - 2004-06-15 13:58:59
|
Salve, vorrei esporre un problema che =E8 venuto fuori durante l'analisi=20 dell'architettura di OpenPec: la possibile ridondanza dei messaggi. Il punto della situazione: l'MTA inoltra a OpenPec le mail che arrivano in ingresso; OpenPec riceve la mail e tiene aperta la connessione con l'MTA fino a = che non=20 ha terminato l'elaborazione. Le situazioni a cui ci possiamo trovare davanti possono essere cosi'=20 sintetizzate: 1. punto di accesso . emissione ricevuta di accettazione (sempre locale) . generazione doc. di trasp. . delivery doc. di trasp. 2. punto di ricezione . emissione (eventuale) ricevuta di presa in carico (sempre remota) . emissione (eventuale) anomalia di trasp. 3. punto di consegna . consegna doc. di trasp. (sempre locale) . emissione ricevuta di avv. cons. Il problema Supponiamo che (punto 1) la ric. di acc. venga emessa correttamente e si = verifichi=20 un errore nella generazione o nel delivery del doc. di trasp.;=20 se restituiamo al MTA un errore di tipo 4 la mail viene mantenuta in = coda e=20 ripresentata successivamente provocando una nuova emissione della = ricevuta fino a=20 problema concluso: il risultato finale e' che il mittente si ritrovera' = un numero di=20 ricevute di acc. pari al numero dei problemi + 1. A parte la confusione del mittente ricordiamo che ogni ricevuta ha = valore legale. Lo stesso problema si presenta nel punto di ricezione e consegna: = soprattutto in=20 quest'ultimo potrebbe ingenerarsi una ben piu' grave emissione anomala = di=20 documenti di trasporto identici non coerenti con le ric. di avv. cons.. Ricordiamo inoltre che OpenPec non scinde "fisicamente" i tre punti = summenzionati per=20 ottimizzare le prestazioni:=20 per mail locali->locali i punti 1 e 3 utilizzano la stessa connessione = con MTA, lo stesso per mail remote->locali (punto 2 e 3). Questo significa che se il problema si verifica nell'ultima fase tutte = quelle precedenti=20 vengono nuovamente eseguite non appena l'MTA ripropone la mail. flazan |
|
From: Fanton F. <fa...@ks...> - 2004-05-27 09:06:38
|
Salve, aggiornato CVS con le seguenti modifiche: - In caso di errori sul delivery delle ricevute di accettazione e presa in carico la mail originale viene mantenuta nella coda del MTA e rielaborata successivamente - Opec::LMTP - verifica che il server supporti LMTP - Opec::Sign - rivisto il modulo per migliorare le prestazioni - aggiornata la sintassi e le stampe di start/stop - aggiunto il supporto per il profiling Saluti, flazan |
|
From: Giovanni F. <gi...@fa...> - 2004-05-20 20:14:28
|
E' stato approvato oggi, in Conferenza Unificata, lo schema del decreto che contiene il regolamento riguardante le disposizioni per l'utilizzo della posta elettronica certificata. http://www.ansa.it/fdg02/200405201952150800/200405201952150800.html Mancano ancora molti passaggi perche' finisca il suo iter, ma e' un'altro passo in avanti. --Gio' |
|
From: Fanton F. <fa...@ks...> - 2004-05-20 09:26:46
|
Prendendo esempio da Amavis, ho aggiunto il modulo Opec::Timing che =
consente di aggiungere dei "paletti" nel codice e in fondo riportare il =
tempo totale e i vari intertempi anche in percentuale.
Ecco i risultati ottenuti con una mail di 4721768 BYTE:
- FIRMA
init: 1 (0%),=20
IN::SMTP: 1150 (12%)
sanity_check: 5 (0%)
ldap_validateRecipt: 161 (2%)
gen_AcceptanceReceipt: 29 (0%)
sign_AcceptanceReceipt: 95 (1%)
del_AcceptanceReceipt: 385 (4%)
gen_DocTransport: 38 (0%)
sign_DocTransport: 5500 (56%)
del_DocTransport: 2519 (25%)
corePec: 13 (0%)
rundown: 2 (0%)
- VERIFICA
TIMING [total 62159 ms] - init: 6 (0%)
IN::SMTP: 1314 (2%)
--> verify: 48549 (78%) <--
gen_LoadReceipt: 39 (0%)
sign: 79 (0%)
delivery: 229 (0%)
del_DocTransp: 1605 (3%)
gen_DeliveryReceipt: 31 (0%)
sign: 7772 (13%)
del_AcceptReceipt: 2533 (4%)
corePec: 1 (0%)
rundown: 2 (0%)
* del_: delivery
gen_: generazione
Queste info mi sembrano + significative; da notare:
. quanto incide la verifica in confronto con la firma
. ricevere una mail costa meno che spedirla: qualcosa da migliorare?
. altro?
Direi di aggiungere alla distribuzione ufficiale Opec::Timing: che ne =
dite?
Mi pare un'ottima idea anche per valutare le prestazioni sulla macchina =
d'installazione.
flazan
-----Messaggio originale-----
Da: Fanton Flavio=20
Inviato: gioved=EC 20 maggio 2004 10.44
A: ope...@li...
Oggetto: R: [Openpec-devel] Profiling: howto
In realta' quello che mi interessava era analizzare il tempo impiegato =
dalla firma/verifica rispetto al resto ma non ho pensato che queste =
ultime vengono chiamate come processo esterno e DProf rimane nel parent =
in waitpid:
da Opec::Sign::_exec()
defined($child =3D open(OUT, '-|'))
or return (-1);
if($child) {
$res =3D join('', <OUT>);
close(OUT) or not $! or return(-1);
} else {
select(STDERR); $| =3D 1;
select(STDOUT); $| =3D 1;
open(STDERR, ">&STDOUT") or die "Impossibile redirigere STDERR =
su STDOUT";
exec(@arg) or die "Impossibile eseguire exec";
}
return($?, $res);
Per non complicarmi troppo la vita direi di aggiungere dei "bookmark" =
nei punti caldi del codice e alla fine calcolare il tempo trascorso fra =
due "bookmark" consecutivi.
flazan
|
|
From: Fanton F. <fa...@ks...> - 2004-05-20 08:42:43
|
In realta' quello che mi interessava era analizzare il tempo impiegato =
dalla firma/verifica rispetto al resto ma non ho pensato che queste =
ultime vengono chiamate come processo esterno e DProf rimane nel parent =
in waitpid:
da Opec::Sign::_exec()
defined($child =3D open(OUT, '-|'))
or return (-1);
if($child) {
$res =3D join('', <OUT>);
close(OUT) or not $! or return(-1);
} else {
select(STDERR); $| =3D 1;
select(STDOUT); $| =3D 1;
open(STDERR, ">&STDOUT") or die "Impossibile redirigere STDERR =
su STDOUT";
exec(@arg) or die "Impossibile eseguire exec";
}
return($?, $res);
Per non complicarmi troppo la vita direi di aggiungere dei "bookmark" =
nei punti caldi del codice e alla fine calcolare il tempo trascorso fra =
due "bookmark" consecutivi.
flazan
-----Messaggio originale-----
Da: Fanton Flavio=20
Inviato: gioved=EC 20 maggio 2004 10.33
A: ope...@li...
Oggetto: R: [Openpec-devel] Profiling: howto
I risultati
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* Dall'output di dprofpp ho tolto le varie chiamate BEGIN visto che a =
regime non influiscono.
Le prove sono state effettuate sulla solita opec1 (caratteristiche su =
http://www.openpec.org/doc_test.shtml) e divise per firma e verifica e =
cambiando la dimensione della mail (1398 - 25914 - 4721768 BYTE).
Log al massimo livello (5) su file.
Ecco i tempi:
* Firma + ricevuta di accettazione
- MAIL DA 1398 BYTE
Total Elapsed Time =3D 10.55452 Seconds
User+System Time =3D 2.174525 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
6.58 0.143 0.142 918 0.0002 0.0002 =
Convert::ASN1::parser::yylex
5.47 0.119 -0.000 55 0.0022 - Exporter::export
3.82 0.083 0.225 1 0.0831 0.2254 =
Convert::ASN1::parser::yyparse
3.13 0.068 0.117 171 0.0004 0.0007 Exporter::import
1.79 0.039 0.039 83 0.0005 0.0005 vars::import
1.20 0.026 0.026 248 0.0001 0.0001 =
Convert::ASN1::parser::compile_one
0.92 0.020 0.069 1 0.0199 0.0693 =
Opec::Out::Dispatcher::new
0.92 0.020 0.057 1 0.0199 0.0573 Net::LDAP::search
0.92 0.020 0.020 34 0.0006 0.0006 =
Mail::Header::_tidy_header
0.92 0.020 0.020 62 0.0003 0.0003 =
Mail::Header::_fold_line
0.46 0.010 0.010 1 0.0100 0.0100 Time::HiRes::bootstrap
0.46 0.010 0.010 1 0.0100 0.0100 AutoLoader::AUTOLOAD
0.46 0.010 0.010 1 0.0100 0.0100 Opec::Conf::read_config
0.46 0.010 0.010 2 0.0050 0.0050 Opec::Xml::_openData
0.46 0.010 0.010 2 0.0050 0.0050 =
MIME::Body::Scalar::init
- MAIL DA 25914 BYTE
Total Elapsed Time =3D 5.147072 Seconds
User+System Time =3D 2.187072 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
7.45 0.163 0.224 1 0.1626 0.2245 =
Convert::ASN1::parser::yyparse
5.40 0.118 0.177 171 0.0007 0.0010 Exporter::import
4.98 0.109 -0.000 55 0.0020 - Exporter::export
2.83 0.062 0.062 918 0.0001 0.0001 =
Convert::ASN1::parser::yylex
1.55 0.034 0.037 3 0.0112 0.0123 =
MIME::Decoder::NBit::encode_it
1.37 0.030 0.030 34 0.0009 0.0009 Mail::Header::_tidy_header
1.33 0.029 0.029 83 0.0004 0.0004 vars::import
0.91 0.020 0.020 6 0.0033 0.0033 Net::LDAP::Constant::_find
0.91 0.020 0.069 1 0.0199 0.0693 Opec::Out::Dispatcher::new
0.91 0.020 0.019 59 0.0003 0.0003 Exporter::as_heavy
0.91 0.020 0.020 62 0.0003 0.0003 Mail::Header::_fold_line
0.87 0.019 0.018 2 0.0097 0.0090 Mail::Header::read
0.87 0.019 0.019 181 0.0001 0.0001 Mail::Header::_tag_case
0.78 0.017 0.011 100 0.0002 0.0001 Opec::Log::writeLog
0.73 0.016 0.026 248 0.0001 0.0001 =
Convert::ASN1::parser::compile_one
- MAIL DA 4721768 BYTE
Total Elapsed Time =3D 23.00064 Seconds
User+System Time =3D 6.400647 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
27.4 1.759 1.759 61413 0.0000 0.0000 IO::Wrap::getline
24.4 1.567 4.024 3 0.5223 1.3412 =
MIME::Decoder::NBit::encode_it
14.3 0.920 6.151 1 0.9195 6.1506 =
Opec::In::SMTP::process_request
10.9 0.698 0.698 61486 0.0000 0.0000 IO::Wrap::print
7.23 0.463 0.468 295 0.0016 0.0016 Net::Cmd::datasend
6.56 0.420 4.519 2 0.2098 2.2596 Opec::Sign::_sign
2.39 0.153 0.224 1 0.1526 0.2245 =
Convert::ASN1::parser::yyparse
1.86 0.119 -0.000 55 0.0022 - Exporter::export
1.69 0.108 0.157 171 0.0006 0.0009 Exporter::import
1.12 0.072 0.072 918 0.0001 0.0001 =
Convert::ASN1::parser::yylex
0.67 0.043 0.553 1 0.0426 0.5527 =
Opec::Out::SMTP::_mailViaSmtpSingle
0.59 0.038 0.038 296 0.0001 0.0001 IO::Handle::read
0.45 0.029 0.029 83 0.0004 0.0004 vars::import
0.41 0.026 0.026 248 0.0001 0.0001 =
Convert::ASN1::parser::compile_one
* Firma + ricevuta di presa in carico e avvenuta consegna
- MAIL DA 1398 BYTE
Total Elapsed Time =3D 6.970199 Seconds
User+System Time =3D 2.270199 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
6.30 0.143 0.214 1 0.1426 0.2145 =
Convert::ASN1::parser::yyparse
6.12 0.139 -0.000 55 0.0025 - Exporter::export
3.88 0.088 0.167 172 0.0005 0.0010 Exporter::import
3.17 0.072 0.072 918 0.0001 0.0001 =
Convert::ASN1::parser::yylex
1.67 0.038 0.038 236 0.0002 0.0002 Mail::Header::_tag_case
1.32 0.030 0.029 35 0.0008 0.0008 Net::Cmd::getline
1.15 0.026 0.026 248 0.0001 0.0001 =
Convert::ASN1::parser::compile_one
0.88 0.020 0.069 1 0.0199 0.0693 Opec::Out::Dispatcher::new
0.88 0.020 0.020 8 0.0025 0.0024 Mail::Field::_require_dir
0.88 0.020 0.020 45 0.0004 0.0004 Convert::ASN1::_decode_tl
0.88 0.020 0.019 59 0.0003 0.0003 Exporter::as_heavy
0.84 0.019 0.025 15 0.0013 0.0017 =
MIME::Parser::Reader::read_chunk
0.79 0.018 0.036 85 0.0002 0.0004 Mail::Header::_fmt_line
0.44 0.010 0.010 1 0.0100 0.0100 =
IO::WrapTie::Master::PRELOAD
- MAIL DA 25914 BYTE
Total Elapsed Time =3D 9.650885 Seconds
User+System Time =3D 2.400885 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
5.96 0.143 0.215 1 0.1431 0.2154 =
Convert::ASN1::parser::yyparse
5.37 0.129 -0.000 55 0.0023 - Exporter::export
3.04 0.073 0.072 918 0.0001 0.0001 =
Convert::ASN1::parser::yylex
2.42 0.058 0.137 172 0.0003 0.0008 Exporter::import
1.58 0.038 0.038 297 0.0001 0.0001 Mail::Header::_tag_case
1.54 0.037 0.056 106 0.0004 0.0005 Mail::Header::_fmt_line
1.54 0.037 0.037 370 0.0001 0.0001 IO::Wrap::read
1.08 0.026 0.026 248 0.0001 0.0001 =
Convert::ASN1::parser::compile_one
1.08 0.026 0.029 127 0.0002 0.0002 Opec::Log::writeLog
0.83 0.020 0.030 3 0.0067 0.0100 vars::BEGIN
0.83 0.020 0.020 6 0.0033 0.0033 Net::LDAP::Constant::_find
0.83 0.020 0.020 4 0.0050 0.0050 Errno::BEGIN
0.83 0.020 0.069 1 0.0199 0.0693 Opec::Out::Dispatcher::new
0.83 0.020 0.020 30 0.0007 0.0007 Mail::Header::_tidy_header
- MAIL DA 4721768 BYTE
Total Elapsed Time =3D 82.25980 Seconds
User+System Time =3D 8.769809 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c Name
24.2 2.123 5.815 13 0.1633 0.4473 =
MIME::Decoder::Base64::encode_it
17.9 1.578 1.578 77604 0.0000 0.0000 IO::Wrap::read
17.2 1.516 1.516 77834 0.0000 0.0000 IO::Wrap::print
10.9 0.960 10.139 1 0.9596 10.138 =
Opec::In::SMTP::process_request
10.8 0.947 0.988 587 0.0016 0.0017 Net::Cmd::datasend
8.87 0.778 0.789 40 0.0194 0.0197 =
MIME::Parser::Reader::read_chunk
7.27 0.638 0.638 77622 0.0000 0.0000 MIME::Base64::encode_base64
5.59 0.490 6.401 2 0.2448 3.2003 Opec::Sign::_sign
2.36 0.207 0.375 13 0.0159 0.0288 =
MIME::Decoder::Base64::decode_it
1.86 0.163 0.225 1 0.1631 0.2254 =
Convert::ASN1::parser::yyparse
1.69 0.148 0.187 172 0.0009 0.0011 Exporter::import
1.47 0.129 1.840 13 0.0099 0.1415 Opec::BEGIN
1.41 0.124 0.124 753 0.0002 0.0002 IO::Handle::read
1.13 0.099 -0.000 55 0.0018 - Exporter::export
flazan
|
|
From: Fanton F. <fa...@ks...> - 2004-05-20 08:31:39
|
I risultati =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Dall'output di dprofpp ho tolto le varie chiamate BEGIN visto che a = regime non influiscono. Le prove sono state effettuate sulla solita opec1 (caratteristiche su = http://www.openpec.org/doc_test.shtml) e divise per firma e verifica e = cambiando la dimensione della mail (1398 - 25914 - 4721768 BYTE). Log al massimo livello (5) su file. Ecco i tempi: * Firma + ricevuta di accettazione - MAIL DA 1398 BYTE Total Elapsed Time =3D 10.55452 Seconds User+System Time =3D 2.174525 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 6.58 0.143 0.142 918 0.0002 0.0002 = Convert::ASN1::parser::yylex 5.47 0.119 -0.000 55 0.0022 - Exporter::export 3.82 0.083 0.225 1 0.0831 0.2254 = Convert::ASN1::parser::yyparse 3.13 0.068 0.117 171 0.0004 0.0007 Exporter::import 1.79 0.039 0.039 83 0.0005 0.0005 vars::import 1.20 0.026 0.026 248 0.0001 0.0001 = Convert::ASN1::parser::compile_one 0.92 0.020 0.069 1 0.0199 0.0693 = Opec::Out::Dispatcher::new 0.92 0.020 0.057 1 0.0199 0.0573 Net::LDAP::search 0.92 0.020 0.020 34 0.0006 0.0006 = Mail::Header::_tidy_header 0.92 0.020 0.020 62 0.0003 0.0003 = Mail::Header::_fold_line 0.46 0.010 0.010 1 0.0100 0.0100 Time::HiRes::bootstrap 0.46 0.010 0.010 1 0.0100 0.0100 AutoLoader::AUTOLOAD 0.46 0.010 0.010 1 0.0100 0.0100 Opec::Conf::read_config 0.46 0.010 0.010 2 0.0050 0.0050 Opec::Xml::_openData 0.46 0.010 0.010 2 0.0050 0.0050 = MIME::Body::Scalar::init - MAIL DA 25914 BYTE Total Elapsed Time =3D 5.147072 Seconds User+System Time =3D 2.187072 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 7.45 0.163 0.224 1 0.1626 0.2245 = Convert::ASN1::parser::yyparse 5.40 0.118 0.177 171 0.0007 0.0010 Exporter::import 4.98 0.109 -0.000 55 0.0020 - Exporter::export 2.83 0.062 0.062 918 0.0001 0.0001 = Convert::ASN1::parser::yylex 1.55 0.034 0.037 3 0.0112 0.0123 = MIME::Decoder::NBit::encode_it 1.37 0.030 0.030 34 0.0009 0.0009 Mail::Header::_tidy_header 1.33 0.029 0.029 83 0.0004 0.0004 vars::import 0.91 0.020 0.020 6 0.0033 0.0033 Net::LDAP::Constant::_find 0.91 0.020 0.069 1 0.0199 0.0693 Opec::Out::Dispatcher::new 0.91 0.020 0.019 59 0.0003 0.0003 Exporter::as_heavy 0.91 0.020 0.020 62 0.0003 0.0003 Mail::Header::_fold_line 0.87 0.019 0.018 2 0.0097 0.0090 Mail::Header::read 0.87 0.019 0.019 181 0.0001 0.0001 Mail::Header::_tag_case 0.78 0.017 0.011 100 0.0002 0.0001 Opec::Log::writeLog 0.73 0.016 0.026 248 0.0001 0.0001 = Convert::ASN1::parser::compile_one - MAIL DA 4721768 BYTE Total Elapsed Time =3D 23.00064 Seconds User+System Time =3D 6.400647 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 27.4 1.759 1.759 61413 0.0000 0.0000 IO::Wrap::getline 24.4 1.567 4.024 3 0.5223 1.3412 = MIME::Decoder::NBit::encode_it 14.3 0.920 6.151 1 0.9195 6.1506 = Opec::In::SMTP::process_request 10.9 0.698 0.698 61486 0.0000 0.0000 IO::Wrap::print 7.23 0.463 0.468 295 0.0016 0.0016 Net::Cmd::datasend 6.56 0.420 4.519 2 0.2098 2.2596 Opec::Sign::_sign 2.39 0.153 0.224 1 0.1526 0.2245 = Convert::ASN1::parser::yyparse 1.86 0.119 -0.000 55 0.0022 - Exporter::export 1.69 0.108 0.157 171 0.0006 0.0009 Exporter::import 1.12 0.072 0.072 918 0.0001 0.0001 = Convert::ASN1::parser::yylex 0.67 0.043 0.553 1 0.0426 0.5527 = Opec::Out::SMTP::_mailViaSmtpSingle 0.59 0.038 0.038 296 0.0001 0.0001 IO::Handle::read 0.45 0.029 0.029 83 0.0004 0.0004 vars::import 0.41 0.026 0.026 248 0.0001 0.0001 = Convert::ASN1::parser::compile_one * Firma + ricevuta di presa in carico e avvenuta consegna - MAIL DA 1398 BYTE Total Elapsed Time =3D 6.970199 Seconds User+System Time =3D 2.270199 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 6.30 0.143 0.214 1 0.1426 0.2145 = Convert::ASN1::parser::yyparse 6.12 0.139 -0.000 55 0.0025 - Exporter::export 3.88 0.088 0.167 172 0.0005 0.0010 Exporter::import 3.17 0.072 0.072 918 0.0001 0.0001 = Convert::ASN1::parser::yylex 1.67 0.038 0.038 236 0.0002 0.0002 Mail::Header::_tag_case 1.32 0.030 0.029 35 0.0008 0.0008 Net::Cmd::getline 1.15 0.026 0.026 248 0.0001 0.0001 = Convert::ASN1::parser::compile_one 0.88 0.020 0.069 1 0.0199 0.0693 Opec::Out::Dispatcher::new 0.88 0.020 0.020 8 0.0025 0.0024 Mail::Field::_require_dir 0.88 0.020 0.020 45 0.0004 0.0004 Convert::ASN1::_decode_tl 0.88 0.020 0.019 59 0.0003 0.0003 Exporter::as_heavy 0.84 0.019 0.025 15 0.0013 0.0017 = MIME::Parser::Reader::read_chunk 0.79 0.018 0.036 85 0.0002 0.0004 Mail::Header::_fmt_line 0.44 0.010 0.010 1 0.0100 0.0100 = IO::WrapTie::Master::PRELOAD - MAIL DA 25914 BYTE Total Elapsed Time =3D 9.650885 Seconds User+System Time =3D 2.400885 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 5.96 0.143 0.215 1 0.1431 0.2154 = Convert::ASN1::parser::yyparse 5.37 0.129 -0.000 55 0.0023 - Exporter::export 3.04 0.073 0.072 918 0.0001 0.0001 = Convert::ASN1::parser::yylex 2.42 0.058 0.137 172 0.0003 0.0008 Exporter::import 1.58 0.038 0.038 297 0.0001 0.0001 Mail::Header::_tag_case 1.54 0.037 0.056 106 0.0004 0.0005 Mail::Header::_fmt_line 1.54 0.037 0.037 370 0.0001 0.0001 IO::Wrap::read 1.08 0.026 0.026 248 0.0001 0.0001 = Convert::ASN1::parser::compile_one 1.08 0.026 0.029 127 0.0002 0.0002 Opec::Log::writeLog 0.83 0.020 0.030 3 0.0067 0.0100 vars::BEGIN 0.83 0.020 0.020 6 0.0033 0.0033 Net::LDAP::Constant::_find 0.83 0.020 0.020 4 0.0050 0.0050 Errno::BEGIN 0.83 0.020 0.069 1 0.0199 0.0693 Opec::Out::Dispatcher::new 0.83 0.020 0.020 30 0.0007 0.0007 Mail::Header::_tidy_header - MAIL DA 4721768 BYTE Total Elapsed Time =3D 82.25980 Seconds User+System Time =3D 8.769809 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 24.2 2.123 5.815 13 0.1633 0.4473 = MIME::Decoder::Base64::encode_it 17.9 1.578 1.578 77604 0.0000 0.0000 IO::Wrap::read 17.2 1.516 1.516 77834 0.0000 0.0000 IO::Wrap::print 10.9 0.960 10.139 1 0.9596 10.138 = Opec::In::SMTP::process_request 10.8 0.947 0.988 587 0.0016 0.0017 Net::Cmd::datasend 8.87 0.778 0.789 40 0.0194 0.0197 = MIME::Parser::Reader::read_chunk 7.27 0.638 0.638 77622 0.0000 0.0000 MIME::Base64::encode_base64 5.59 0.490 6.401 2 0.2448 3.2003 Opec::Sign::_sign 2.36 0.207 0.375 13 0.0159 0.0288 = MIME::Decoder::Base64::decode_it 1.86 0.163 0.225 1 0.1631 0.2254 = Convert::ASN1::parser::yyparse 1.69 0.148 0.187 172 0.0009 0.0011 Exporter::import 1.47 0.129 1.840 13 0.0099 0.1415 Opec::BEGIN 1.41 0.124 0.124 753 0.0002 0.0002 IO::Handle::read 1.13 0.099 -0.000 55 0.0018 - Exporter::export flazan -----Messaggio originale----- Da: Fanton Flavio=20 Inviato: gioved=EC 20 maggio 2004 10.19 A: ope...@li... Oggetto: [Openpec-devel] Profiling: howto Ecco come ho effettuato il profiling di OpenPec. Naturalmente e' stato necessario ritoccare il codice: . [opec.pl] escluso Net::Server (il modulo che sovrintende il multi process) . [opec.pl] aggiunto e incapsulato un server TCP: my $self =3D {}; bless($self,'Opec'); use IO::Socket; $self->{server}->{peeraddr} =3D '127.0.0.1'; $self->{server}->{sockport} =3D 10024; $self->{server}->{sockaddr} =3D '127.0.0.1'; my $listen_socket =3D IO::Socket::INET->new( LocalPort =3D> 10024, Type =3D> SOCK_STREAM, Reuse =3D> 1, Listen =3D> 1 ) # or SOMAXCONN or die "Couldn't be a tcp server on port 10024: $@\n"; # in attesa di connessione $self->{server}->{client} =3D $listen_socket->accept(); . [opec.pl] modificato opportunamente le chiamate $sock->NS_proto . [Opec::IN::SMTP] reso $sock il socket di default: select($sock); Spero di non essermi dimenticato qualcosa. flazan ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. = Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Openpec-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openpec-devel |
|
From: Fanton F. <fa...@ks...> - 2004-05-20 08:17:27
|
Ecco come ho effettuato il profiling di OpenPec.
Naturalmente e' stato necessario ritoccare il codice:
. [opec.pl] escluso Net::Server (il modulo che sovrintende il multi
process)
. [opec.pl] aggiunto e incapsulato un server TCP:
my $self =3D {};
bless($self,'Opec');
use IO::Socket;
$self->{server}->{peeraddr} =3D '127.0.0.1';
$self->{server}->{sockport} =3D 10024;
$self->{server}->{sockaddr} =3D '127.0.0.1';
my $listen_socket =3D IO::Socket::INET->new(
LocalPort =3D> 10024,
Type =3D> SOCK_STREAM,
Reuse =3D> 1,
Listen =3D> 1 ) # or SOMAXCONN
or die "Couldn't be a tcp server on port 10024: $@\n";
# in attesa di connessione
$self->{server}->{client} =3D $listen_socket->accept();
. [opec.pl] modificato opportunamente le chiamate $sock->NS_proto
. [Opec::IN::SMTP] reso $sock il socket di default:
select($sock);
Spero di non essermi dimenticato qualcosa.
flazan
|
|
From: Giovanni F. <gi...@fa...> - 2004-05-14 10:10:35
|
OK. Riprodotta la "lentezza". I miei tempi su un P4-2Ghz sono: Firma: real 0m0.502s user 0m0.340s sys 0m0.050s Verifica: Verification successful real 0m9.934s user 0m9.390s sys 0m0.070s E' la dim della mail che fa' la differenza. Entro nel codice di openssl e guardo cosa fa'. (ci vorra' un po' di tempo) --Gio' |
|
From: Giovanni F. <gi...@fa...> - 2004-05-14 10:03:53
|
On Fri, 14 May 2004, Luca Manganelli wrote: > [dopec@opec2 openpec-verify-speed]$ ./check > Verification successful > > real 0m0.032s > user 0m0.020s > sys 0m0.020s > Verification successful > > real 0m0.083s > user 0m0.030s > sys 0m0.000s > Verification failure > 1694:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:803: > 1694:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:265: > > real 0m0.032s > user 0m0.030s > sys 0m0.000s Hmmm... Quindi non e' openssl in se', ma sono i dati che gli passiamo. Riuscireste ad aggiungere un paio di vostri files "lenti" il vostro CAcert ed i comandi relativi a ./check, ed a rispedirmi il tar.gz che provo a riprodurre la lentezza anche da me' ? --Gio' |
|
From: Luca M. <man...@ks...> - 2004-05-14 09:59:00
|
Ho fatto anche io questa prova (allego l'email, il certificato e la = chiave privata) su una macchina PIII-550: *** FIRMA *** [dopec@opec2 dopec]$ time openssl smime -sign -in email.txt -out = email.sign -signer cert.pem -inkey key.pem real 0m2.740s user 0m1.440s sys 0m0.160s *** VERIFICA *** [dopec@opec2 dopec]$ time openssl smime -verify -in email.sign -out = /dev/null -CAfile cert.pem Verification successful real 1m22.298s user 0m43.350s sys 0m0.120s provate voi stessi... (p.s. anche la 0.9.7a da' gli stessi tempi = all'incirca) p.s. il gestore delle ml di sourceforge accetta allegati fino a 1mb... = il mio era 3mb... lo potete scaricare da qui: http://www.ariadnecms.it/~luca/test.zip |
|
From: Luca M. <man...@ks...> - 2004-05-14 09:56:25
|
> -----Messaggio originale----- > Da: Giovanni Faglioni [mailto:gi...@fa...] > Inviato: venerd=EC 14 maggio 2004 11.49 > A: ope...@li... > Oggetto: Re: [Openpec-devel] Problemi durante la verifica >=20 > Potreste fare, con il file allegato, > sulla stessa macchina che vi da' dei problemi: >=20 > tar xvfz openpec-verify-speed.tar.gz > cd openpec-verify-speed > ./check 2> results.out >=20 > ed inviarmi il risultato ? [dopec@opec2 openpec-verify-speed]$ ./check Verification successful real 0m0.032s user 0m0.020s sys 0m0.020s Verification successful real 0m0.083s user 0m0.030s sys 0m0.000s Verification failure 1694:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest = failure:pk7_doit.c:803: 1694:error:21075069:PKCS7 routines:PKCS7_verify:signature = failure:pk7_smime.c:265: real 0m0.032s user 0m0.030s sys 0m0.000s |
|
From: Giovanni F. <gi...@fa...> - 2004-05-14 09:55:06
|
Sono uno statistico piuttosto improvvisato.
Ho lanciato i tests sullo 0.9.7d UNA volta
sola, con il results che vi ho allegato nella
mail precedente.
Rilanciandoli piu' volte, i risultati della
0.9.7a e della 0.9.7d sono praticamente IDENTICI:
0.9.7.d:
[giova@river openpec-verify-speed]$ ./check
Verification successful
real 0m0.014s
user 0m0.010s
sys 0m0.000s
Verification successful
real 0m0.012s
user 0m0.010s
sys 0m0.000s
Verification failure
22815:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest
failure:pk7_doit.c:803:
22815:error:21075069:PKCS7 routines:PKCS7_verify:signature
failure:pk7_smime.c:265:
real 0m0.013s
user 0m0.010s
sys 0m0.000s
Si vede che quando ho lanciato il check la prima
volta il server era carico per i cavoli suoi.
On Fri, 14 May 2004, Giovanni Faglioni wrote:
> On Fri, 14 May 2004, Luca Manganelli wrote:
>
> > Impiega tanto tempo quando chiama openssl con _exec. Nella _verify
> > vengono preparati i parametri per l'esecuzione (i vari push) e poi
> > viene invocato _exec.
> >
> > Anche se esegui dalla linea di comando a mano, ci mette tanto tempo.
> >
> > Un esempio:
> >
> > openssl smime -verify -in email.txt -out /dev/null -CAfile certificato.pem
>
> Ho preso 2 mail di madwolf, firmate in smime con cert del polito,
> (che e' sotto europki/it/polito, quindi ha una chain)
> prova1.smime e prova2.smime.
>
> una di queste l'ho modificata e messa in bad1.smime (per fare in
> modo che la verifica desse errore)
>
> Allego il tar con il necessario per riprodurre l'esperimento.
> (ho l'OK di max a divulgare le sue due mails)
>
> Su un P4 2.0Ghz, OpenSSL 0.9.7a Feb 19 2003, i comandi:
>
> time openssl smime -verify -noverify -in prova1.smime -out /dev/null -CAfile ca_cert_polito.pem
> time openssl smime -verify -noverify -in prova2.smime -out /dev/null -CAfile ca_cert_polito.pem
> time openssl smime -verify -noverify -in bad1.smime -out /dev/null -CAfile ca_cert_polito.pem
>
> (il -noverify serve ad impedire la ricerca dei certificati nella
> chain del path-of-trust, non a disabilitare la -verifiy. E' che
> sono pigro e non voglio installare le ca di europki/it/polito
> nei miei openssl)
>
> Danno come result:
>
> Verification successful
>
> real 0m0.011s
> user 0m0.010s
> sys 0m0.000s
> Verification successful
>
> real 0m0.031s
> user 0m0.010s
> sys 0m0.000s
> Verification failure
> 14114:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest
> failure:pk7_doit.c:804:
> 14114:error:21075069:PKCS7 routines:PKCS7_verify:signature
> failure:pk7_smime.c:265:
>
> real 0m0.010s
> user 0m0.010s
> sys 0m0.000s
>
>
> ------------------------------------------------------------------
> Stessi comandi, sulla stessa macchina, ma con OpenSSL 0.9.7d 17 Mar 2004:
>
> Verification successful
>
> real 0m0.046s
> user 0m0.020s
> sys 0m0.000s
> Verification successful
>
> real 0m0.078s
> user 0m0.000s
> sys 0m0.010s
> Verification failure
> 22793:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest
> failure:pk7_doit.c:803:
> 22793:error:21075069:PKCS7 routines:PKCS7_verify:signature
> failure:pk7_smime.c:265:
>
> real 0m0.160s
> user 0m0.010s
> sys 0m0.000s
>
> ------------------------------------------------------------------
>
> Openssl 0.9.7d e' _PARECCHIO_ piu' lento di
> Openssl 0.9.7a, ma comunque dovrebbe reggere
> piu' di 10 verifiche corrette al secondo e
> piu' di 5 verifiche errate al secondo.
>
> Non so' se questa differenza giustifica
> 8-10 secondi su un PIII-550Mgz.
>
> Potreste fare, con il file allegato,
> sulla stessa macchina che vi da' dei problemi:
>
> tar xvfz openpec-verify-speed.tar.gz
> cd openpec-verify-speed
> ./check 2> results.out
>
> ed inviarmi il risultato ?
>
> --Gio'
>
|
|
From: Giovanni F. <gi...@fa...> - 2004-05-14 09:49:13
|
On Fri, 14 May 2004, Luca Manganelli wrote: > Impiega tanto tempo quando chiama openssl con _exec. Nella _verify > vengono preparati i parametri per l'esecuzione (i vari push) e poi > viene invocato _exec. > > Anche se esegui dalla linea di comando a mano, ci mette tanto tempo. > > Un esempio: > > openssl smime -verify -in email.txt -out /dev/null -CAfile certificato.pem Ho preso 2 mail di madwolf, firmate in smime con cert del polito, (che e' sotto europki/it/polito, quindi ha una chain) prova1.smime e prova2.smime. una di queste l'ho modificata e messa in bad1.smime (per fare in modo che la verifica desse errore) Allego il tar con il necessario per riprodurre l'esperimento. (ho l'OK di max a divulgare le sue due mails) Su un P4 2.0Ghz, OpenSSL 0.9.7a Feb 19 2003, i comandi: time openssl smime -verify -noverify -in prova1.smime -out /dev/null -CAfile ca_cert_polito.pem time openssl smime -verify -noverify -in prova2.smime -out /dev/null -CAfile ca_cert_polito.pem time openssl smime -verify -noverify -in bad1.smime -out /dev/null -CAfile ca_cert_polito.pem (il -noverify serve ad impedire la ricerca dei certificati nella chain del path-of-trust, non a disabilitare la -verifiy. E' che sono pigro e non voglio installare le ca di europki/it/polito nei miei openssl) Danno come result: Verification successful real 0m0.011s user 0m0.010s sys 0m0.000s Verification successful real 0m0.031s user 0m0.010s sys 0m0.000s Verification failure 14114:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:804: 14114:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:265: real 0m0.010s user 0m0.010s sys 0m0.000s ------------------------------------------------------------------ Stessi comandi, sulla stessa macchina, ma con OpenSSL 0.9.7d 17 Mar 2004: Verification successful real 0m0.046s user 0m0.020s sys 0m0.000s Verification successful real 0m0.078s user 0m0.000s sys 0m0.010s Verification failure 22793:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:803: 22793:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:265: real 0m0.160s user 0m0.010s sys 0m0.000s ------------------------------------------------------------------ Openssl 0.9.7d e' _PARECCHIO_ piu' lento di Openssl 0.9.7a, ma comunque dovrebbe reggere piu' di 10 verifiche corrette al secondo e piu' di 5 verifiche errate al secondo. Non so' se questa differenza giustifica 8-10 secondi su un PIII-550Mgz. Potreste fare, con il file allegato, sulla stessa macchina che vi da' dei problemi: tar xvfz openpec-verify-speed.tar.gz cd openpec-verify-speed ./check 2> results.out ed inviarmi il risultato ? --Gio' |
|
From: Luca M. <man...@ks...> - 2004-05-14 07:37:25
|
> -----Messaggio originale----- > Da: Giovanni Faglioni [mailto:gi...@fa...] > Inviato: gioved=EC 13 maggio 2004 19.48 > A: ope...@li... > Oggetto: Re: R: R: R: [Openpec-devel] Problemi durante la verifica >=20 >=20 > Non riesco a seguire il codice per via dei timers, > che non ho ancora studiato a fondo. >=20 > Flavio, hai dei dati di profiling che dicano > _dove_ impiega tanto tempo ? Impiega tanto tempo quando chiama openssl con _exec. Nella _verify vengono preparati i parametri per l'esecuzione (i vari push) e poi viene invocato _exec. Anche se esegui dalla linea di comando a mano, ci mette tanto tempo. Un esempio: openssl smime -verify -in email.txt -out /dev/null -CAfile = certificato.pem |
|
From: Giovanni F. <gi...@fa...> - 2004-05-13 17:48:36
|
On Thu, 13 May 2004, Massimiliano Pala wrote: > Bisogna verificare meglio il codice. Il codice non e' complesso: Dai un okkio in Opec-0.10/lib/Opec/Sign.pm sub Verify: estrae il cert dall'attach e poi chiama sub _verify (Molto simile a quella di OpenCA SMIME.pm) Non riesco a seguire il codice per via dei timers, che non ho ancora studiato a fondo. Flavio, hai dei dati di profiling che dicano _dove_ impiega tanto tempo ? (se nella chiamata di openssl o prima, nella _verify mentre scompatta l'attach, o altrove ?) Non avendo una installaz. funzionante non posso profilare. Ho una consegna a Trieste il 17, il 18 dormo, il 19 rientro tra i vivi e provo ad installare OpenPEC su monchio.faglioni.it. --Gio' |
|
From: Massimiliano P. <mas...@po...> - 2004-05-13 15:32:28
|
Luca Manganelli wrote:
[...]
> l'applicazione della firma e' svariate volte piu' veloce della verifica della firma,
> mentre dovrebbe essere il contrario, in quanto la verifica "legge" soltanto e non
> dovrebbe produrre output come l'applicazione firma (che, come ben noto, produce la
> mail "firmata"). Tanto per farti vedere la differenza delle prestazioni, guarda qui:
[...]
La cosa e' strana perche' in RSA la verifica della firma e' molto piu' veloce
della firma stessa. In effetti in test fatti su 9,5s con diverse lunghezze
di chiavi, utilizzando OpenSSL, i risultati sono i seguenti:
sign verify sign/s verify/s
rsa 512 bits 0.0009s 0.0001s 1107.4 12163.9
rsa 1024 bits 0.0044s 0.0002s 228.2 4222.1
rsa 2048 bits 0.0265s 0.0008s 37.8 1310.9
rsa 4096 bits 0.1733s 0.0026s 5.8 382.3
Quindi come vedete siamo MOLTO al di la' di quello che sono le possibilita'
offerte. Sicuramente molto del tempo impiegato e' legato all'interazione
openssl-perl e un po' legato all'utilizzo dei certificati, ma il tempo vero
di verifica della firma dovrebbe essere ininfluente.
Bisogna verificare meglio il codice.
--
Best Regards,
Massimiliano Pala
--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] mas...@po...
Tel.: +39 (0)11 564 7081
http://security.polito.it Fax: +39 178 270 2077
Mobile: +39 (0)347 7222 365
Politecnico di Torino (EuroPKI)
Certification Authority Informations:
Authority Access Point http://ca.polito.it
Authority's Certificate: http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List: http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------
|
|
From: Luca M. <man...@ks...> - 2004-05-13 12:23:06
|
> -----Messaggio originale----- > Da: Giovanni Faglioni [mailto:gi...@fa...] > Inviato: gioved=EC 13 maggio 2004 13.32 > A: ope...@li... > Oggetto: Re: R: R: [Openpec-devel] Problemi durante la verifica >=20 > Le routines crittografiche sono spesso molto pesanti. Beh una cosa strana e' questa: l'applicazione della firma e' svariate volte piu' veloce della verifica = della firma, mentre dovrebbe essere il contrario, in quanto la verifica "legge" = soltanto e non dovrebbe produrre output come l'applicazione firma (che, come ben noto, = produce la mail "firmata"). Tanto per farti vedere la differenza delle prestazioni, = guarda qui: http://www.openpec.org/test.shtml vai alla prima tabella intitolata "Risultati". Vedrai che la firma = impiega 2,6 secondi per mail mentre la verifica 14 secondi. La verifica = e' da 5 a 7 volte piu' lenta! Mi pare molto strano questo. Anche Outlook 2000/Express deve verificare le mail, ma non ci mette poi = cosi' tanto: massimo 20/30 secondi... Secondo me c'e' qualcosa che non va nel modulo smime-verify di OpenSSL. Ho provato a guardare i sorgenti di OpenSSL per cercare di ottimizzare = qualcosa: purtroppo ci ho capito poco, sono incasinatissimi... |
|
From: Giovanni F. <gi...@fa...> - 2004-05-13 11:32:11
|
On Thu, 13 May 2004, Fanton Flavio wrote: > Una questione ancora aperta =E8 la velocit=E0: openssl=20 > consuma molto durante la verifica quindi stiamo valutando ottimizzazion= i=20 > e alternative (http://www.mozilla.org/projects/security/pki/nss/smime/=20 > ma abbiamo qualche dubbio sulla compatibilit=E0 della licenza - consigl= i?). Le routines crittografiche sono spesso molto pesanti. Openssl e' parecchio ottimizzato, dubito che si possa fare qualcosa di _molto_ piu' performante. Potreste considerare un acceleratore hardware=20 (che vada con openssl). Sotto OpenBSD io ho visto usare questi (per fare VPN): http://www.soekris.com/vpn1401.htm Il vantaggio di questa scheda e' che costa poco: 80 Euro (+Spese di spedizione, +IVA). La puoi acquistare su: http://kd85.com/soekris.html Verifica magari che gli algoritmi che utilizza openpec siano tra quelli che vengono accelerati. Svantaggi: questa scheda NON funziona (ancora) sotto linux, quindi se la vuoi utilizzare devi poi installare openpec sotto FreeBSD od OpenBSD.=20 (non che sia un grosso problema) Per Linux ne esistono parecchie altre. (pero' cosi' ad occhio direi che costano tutte un po' piu' di 80 Euro, e probabilmente vanno anche molto piu' piano) Dal README.ENGINE di openssl-0.9.7d: There are currently built-in ENGINE implementations for the following crypto devices: = =20 o CryptoSwift o Compaq Atalla o nCipher CHIL o Nuron o Broadcom uBSec --Gio' |
|
From: Fanton F. <fa...@ks...> - 2004-05-13 11:04:54
|
Riguardo al codice, lo sviluppo =E8 sostanzialmente fermo e ci stiamo = concentrando sui test. Con l'aggiornamento di openssl non abbiamo avuto = pi=F9 alcun problema. Una questione ancora aperta =E8 la velocit=E0: = openssl consuma molto durante la verifica quindi stiamo valutando = ottimizzazioni e alternative = (http://www.mozilla.org/projects/security/pki/nss/smime/ ma abbiamo = qualche dubbio sulla compatibilit=E0 della licenza - consigli?). Purtroppo abbiamo speso meno tempo sulla questione LDAP che rimane = comunque un punto da verificare quanto prima. Saluti, flazan -----Messaggio originale----- Da: Giovanni Faglioni [mailto:gi...@fa...]=20 Inviato: gioved=EC 13 maggio 2004 12.35 A: ope...@li... Oggetto: Re: R: [Openpec-devel] Problemi durante la verifica On Tue, 11 May 2004, Fanton Flavio wrote: > Il problema =E8 stato risolto sostituendo la versione di openssl=20 > (0.9.7a) con una pi=F9 aggiornata (0.9.7d). Devo proprio riconoscere che lavorate molto bene. Mi sento un po' in "colpa" per non partecipare di piu', ma non e' facile comprendere il codice tutto=20 in una volta...=20 Per la parte di codice che ho scritto io=20 (AggiornaLDAP), avete poi avuto problemi ? --Gio' ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62&alloc_ida84&op=3Dick _______________________________________________ Openpec-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openpec-devel |
|
From: Giovanni F. <gi...@fa...> - 2004-05-13 10:35:17
|
On Tue, 11 May 2004, Fanton Flavio wrote: > Il problema =E8 stato risolto sostituendo la versione di openssl=20 > (0.9.7a) con una pi=F9 aggiornata (0.9.7d). Devo proprio riconoscere che lavorate molto bene. Mi sento un po' in "colpa" per non partecipare di piu', ma non e' facile comprendere il codice tutto=20 in una volta...=20 Per la parte di codice che ho scritto io=20 (AggiornaLDAP), avete poi avuto problemi ? --Gio' |
|
From: Fanton F. <fa...@ks...> - 2004-05-11 13:24:55
|
Il problema =E8 stato risolto sostituendo la versione di openssl=20 (0.9.7a) con una pi=F9 aggiornata (0.9.7d). Sono stati effettuati nuovamente i test di affidabilit=E0 con la = versione=20 aggiornata di openssl e non =E8 emerso alcun problema. Tengo a precisare che il problema riguardava il fallimento della = verifica=20 di mail firmate correttamente e quindi non particolarmente critico:=20 veniva generata l'anomalia di trasporto e, sia la ricevuta di avvenuta = consegna che di presa in carico non venivano comunque spedite. Saluti, flazan -----Messaggio originale----- Da: Fanton Flavio=20 Inviato: venerd=EC 7 maggio 2004 18.37 A: ope...@li... Oggetto: [Openpec-devel] Problemi durante la verifica Salve, durante i test di affidabilit=E0 sono emersi problemi nella verifica. Dati due sistemi di PEC (Postfix-OpenPec-Cyrus) abbiamo spedito 1226 = mail di vario genere verso il primo sistema e 637 mail verso il secondo. Alla fine su entrambi i sistemi abbiamo trovato rispettivamente 20 e 11 = messaggi di anomalia di trasporto che non avrebbero dovuto esserci:=20 i messaggi sono stati firmati correttamente dal sistema di origine ma la = verifica sul sistema destinatario =E8 fallita. Ripetendo il test il problema si =E8 verificato sempre su mail diverse = ed il numero e' cambiato solo di alcune unit=E0 in pi=F9 o in meno. Facendo un dump del messaggio passato a openssl per la verifica e = ripetendo l'operazione manualmente il messaggio viene verificato = correttamente. OpenPec e' eseguito con un solo processo. La verifica fallisce con un codice d'errore 11 (che significa crypto lib = failed) e nessuna stringa su STDOUT o STDERR. La versione di openssl usata =E8 0.9.7a Qualche idea? Saluti, flazan ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to = deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=3Ddnemail3 _______________________________________________ Openpec-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openpec-devel |
|
From: Fanton F. <fa...@ks...> - 2004-05-07 16:35:38
|
Salve, durante i test di affidabilit=E0 sono emersi problemi nella verifica. Dati due sistemi di PEC (Postfix-OpenPec-Cyrus) abbiamo spedito 1226 = mail di vario genere verso il primo sistema e 637 mail verso il secondo. Alla fine su entrambi i sistemi abbiamo trovato rispettivamente 20 e 11 = messaggi di anomalia di trasporto che non avrebbero dovuto esserci:=20 i messaggi sono stati firmati correttamente dal sistema di origine ma la = verifica sul sistema destinatario =E8 fallita. Ripetendo il test il problema si =E8 verificato sempre su mail diverse = ed il numero e' cambiato solo di alcune unit=E0 in pi=F9 o in meno. Facendo un dump del messaggio passato a openssl per la verifica e = ripetendo l'operazione manualmente il messaggio viene verificato = correttamente. OpenPec e' eseguito con un solo processo. La verifica fallisce con un codice d'errore 11 (che significa crypto lib = failed) e nessuna stringa su STDOUT o STDERR. La versione di openssl usata =E8 0.9.7a Qualche idea? Saluti, flazan |
|
From: Fanton F. <fa...@ks...> - 2004-05-04 14:48:17
|
Chiarimenti: - Postfix non =E8 un LMTP server quindi non pu=F2 gestire il traffico LMTP in ingresso; quanto ho scritto precedentemente =E8 sbagliato. Postfix gestisce solo il traffico LMTP in uscita (pu=F2 fare da LMTP = client). - La tua soluzione non =E8 cmq conforme alle direttiva CNIPA (come ha gi=E0 chiarito Dex) - Perch=E9 allora la tua modifica funziona? Ci=F2 =E8 dovuto ad un bug nel modulo LMTP.pm: non viene controllato = il ritorno del comando di identificazione LHLO: infatti Postfix ritorna = un'errore di tipo 502. Il flusso prosegue con i comandi consueti e visto = che LMTP e SMTP sono praticamente identici, in caso di mail ad un solo = destinatario, la transazione va a buon fine. Il bug sar=E0 risolto nella prossima release: non sar=E0 possibile = forzare connessioni SMTP per mail locali certificate. Saluti, flazan -----Messaggio originale----- Da: Fanton Flavio=20 Inviato: marted=EC 4 maggio 2004 11.34 A: ope...@li... Oggetto: R: [Openpec-users] opec e LMTP Purtroppo la soluzione che hai scelto non rispetta le specifiche CNIPA. Vediamo il significato di alcuni parametri del file di configurazione = (opec.conf) - %receiveTCP =3D ( 10024, 'SMTP'); Imposta la porta ed il protocollo del canale di ingresso verso openpec. - $forward_canonical =3D 'SMTP:127.0.0.1:10025'; Stabilisce il protocollo, l'host e la porta sulla quale verranno inviate = le=20 mail a destinatari remoti. - $forward_pec =3D 'server.lmtp.it:24'; Stabilisce l'host e la porta (ma non il protocollo che da specifiche =E8 = obbligatoriamente LMTP) sulla quale verranno inviate le mail a = destinatari=20 locali quindi dovranno coincidere con il punto di ingresso del server = LMTP=20 (nello schema indicato con "mail local"). Quello che tu hai fatto =E8 redirigere quest'ultimo traffico verso il = punto di=20 ingresso di Postfix utilizzato solo per la posta remota. Postfix, se opportunamente configurato, gestisce anche il traffico LMTP = ma in=20 maniera non conforme a RFC 2033 (visto che utilizza le code mentre RFC = 2033=20 le vieta). Per evitare problemi noi consigliamo di utilizzare un LMTP esterno = perfettamente=20 coerente con RFC 2033. Cyrus, oltre essere un LMTP server RFC 2033 compliant, ha anche pop3, = pop3-s,=20 impap e imap-s quindi pu=F2 risultare conveniente. Saluti, flazan ________________________________________ Da: al...@in... [mailto:al...@in...]=20 Inviato: luned=EC 3 maggio 2004 20.36 A: ope...@li... Oggetto: Rif: [Openpec-users] opec e LMTP Sono riuscito a farlo andare!!!!!!! Circa....=20 L'accrocchio che ho usato =E8 quello di escludere il server LMTP, = modificando la corrispondente riga di opec.conf con "$forward_pec =3D = '127.0.0.1:10025';".=20 Cos=EC sembra funzionare (arriva l'e-mail al destrinatario e al mittente = ritornano le due mail di conferma, per=F2 non so cosa questo possa = implicare.=20 Mi confermate che la soluzione che ho adottato funzioni?=20 Grazie mille,=20 ------------------------------------------------- Alberto Zuin - Technical Manager Consigliere Nazionale di Assoprovider Socio ISOC.IT - ISOC.ORG Global member INTEnet S.r.l. via Valsugana, 52/A 35010 San Giorgio in Bosco (PD) Tel. e Fax +39 049 9450970 Tel. VoIP 6122 000000 www.intenet.net - al...@in... Azienda associata ad Assoprovider=20 ope...@li... scritti il 03/05/2004 18.33.00 >=20 > Sto tentando una configurazione particolare di openpec:=20 > sostanzialmente vorrei utilizzare un DB MySQL per gestire via web=20 > gli account invece di usare i file di sistema. Pertanto, visto che=20 > sembra che Cyrus sia un punto fisso (per me =E8 un guaio visto che=20 > conosco solo Courier IMAP), ho fatto l'installazione di cyrus- > postfix-webcyradm come da howto. Una volta installato il tutto e=20 > verificato il corretto funzionamento, sono passato all'installazione > di openpec: negli esempi di configurazione si fa cenno che nel file=20 > cyrus.conf bisogna attivare lmtp al posto di lmtpunix, per=F2 facendo=20 > questo il sistema non ne vuole sentire di andare...=20 > Ho tentato di far partire opec in questa situazione e, in effetti,=20 > mi visualizza un errore in quanto non riesce a collegarsi con il=20 > server LMTP. La posta viene recapitata all'email del destinatario,=20 > per=F2 non partono le ricevute di dispaccio. Secondo la mia logica=20 > dovrebbe accadere il contrario (non doveva arrivare l'email al=20 > destinatario per=F2 dovevano arrivare le ricevute) per=F2 chiedo lumi = a Voi.=20 > Avete qualche idea per rendere funzionante questa configurazione? Se > non =E8 proprio possibile, come posso fare a gestire domini multipli e > avere una interfaccia web?=20 > Grazie,=20 >=20 > ------------------------------------------------- > Alberto Zuin - Technical Manager > Consigliere Nazionale di Assoprovider > Socio ISOC.IT - ISOC.ORG Global member >=20 > INTEnet S.r.l. > via Valsugana, 52/A > 35010 San Giorgio in Bosco (PD) > Tel. e Fax +39 049 9450970 > Tel. VoIP 6122 000000 > www.intenet.net - al...@in... > Adienda associata ad Assoprovider ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. = Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick _______________________________________________ Openpec-users mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openpec-users |
5 messages has been excluded from this view by a project administrator.
