[Gfoss] Aprire postgres verso l'esterno con indirizzo IP statico.

Francesco Paolo Lovergine frankie a debian.org
Sab 15 Maggio 2010 11:20:10 CEST


On Fri, May 14, 2010 at 11:09:03AM +0200, Niccolo Rigacci wrote:
> On Fri, May 14, 2010 at 08:30:33AM +0200, Andrea Peri wrote:
> > 
> > Infatti far viaggiare su internet pacchetti di dati progettati per viaggiare
> > su una rete sicura e con dei fail-over bassissimi (una rete interna),
> > comporta che viaggiano con un supporto di sicurezza ridotto perche' nato per
> > viaggiare su una rete affidabile (la rete interna).
> 
> A dire il vero si utilizza TCP/IP che invece è nato proprio per 
> garantire connessioni affidabili su canali poco affidabili.
> 
> Il tutto funziona con il meccanismo degli acknowledgment e 
> ritrasmissione in caso di errore.
> 
> Quindi è sufficiente che il client, durante la trasmissione dati, 
> verifichi le condizioni di errore, il canale TCP/IP è garantito 
> che le segnala.
> 

Senza perdersi nei Massimi Sistemi di galileiana memoria, il problema 
principale sono i timeout di connessione e connessi a questi il problema 
di garantirsi contro modifiche parziali (-> inconsistenti) del DB. 
Questo puo' essere fatto se si adotta in modo rigoroso una policy
strettamente transazionale nell'effettuare le modifiche (con rollback
automatico in caso di mancato commit esplicito). Tuttavia ci sono
sempre corner case e possibilita' di imbroccare situazioni
in cui la transazione non e' unica per errore o per motivi validissimi
e ci si espone quindi alla possibilita' di inconsistenza.
Gli stessi problemi comunque vanno considerati su WAN o LAN (non c'e'
scritto da nessuna parte che la LAN sia 'affidabile'...) quindi 
il problema e' solo uno: scrivere applicazioni intrinsecamente
corrette dal punto di vista transazionale.

Poi potremmo parlare di OLTP e delle tecniche necessarie a garantire
che le transazioni *distribuite* (i.e. anche fra DB diversi) siano sempre 
consistenti (se no staremmo freschi), ma per quello rimando a :
http://en.wikipedia.org/wiki/Online_transaction_processing
e penso che siamo ampiamente fuori dei termini.


-- 
Francesco P. Lovergine


Maggiori informazioni sulla lista Gfoss