ainulindale-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ainulindale-devel] Network Level


From: Federico 'Derfel' Stella
Subject: Re: [Ainulindale-devel] Network Level
Date: Mon Apr 15 15:45:02 2002
User-agent: Mutt/1.3.28i

* lunedì 15 aprile 2002, alle 11:06, Andrea Negro scrive:
> Federico 'Derfel' Stella wrote:

> Intendo dire: per fare chairezza sul livello di network, dovremmo:
> 1) Stabilire quali tipologie di dati vogliamo scambiare, e farne una 
> lista, e per ciascuna indicarne varie caratteristiche, quali priorita', 
> compressione, etc...
Ok per la tipologia di dati, ma già la priorità in alcuni punti può
dipendere dal design adottato. La compressione non si considera a questo
livello.

> 3) Che tipo di formato di dati utilizzare, come dicevi tu: binario, xml, 
> etcetc.
E qui c'è un'inconprensione: Il formato deve essere multiplo.
Facciamo un esempio per semplificare le cose.
Il client C contatta il server S nella lingua universale.
1) C chiede a S di continuare la sessione con un determinato protocollo.
2) S sceglie in base alla propria configurazione se accettare o meno.
3) C continua fino a che non trova un "accordo" con S.
4) Se è stato trovato un accordo C potrà provare ad abilitare opzioni per il
   procollo stabilito.
5) S decide se abilitare le opzioni (tipo compressione, ecc...)
6) C continua fino a che ha opzioni da abilitare.
7) Handshake terminato. Da questo punto gli accordi diventano effettivi.

Tutto questo per avere un framework estensibile e debuggabile in maniera
umana.

> Cerco di formalizzare perche' vorrei entro molto breve che sia possibile 
> scrivere un draft su queste cose, prima di dedicarsi ad altre questioni: 
> tanto da avere una bozza del lavoro, in modo che non vada perduto nelle 
> sabbie del tempo come le nostre passate discussioni.
Ora abbiamo anche google a dare una mano ;-).

A tal proposito sarebbe il caso che si decidesse una politica di backup dei
dati del progetto e delle mailing-list.

>>>Concordo! In effetti se implementiamo un sistema per monitorare la banda
>>>disponibile, si puo' anche pensare che il client che tiene le
[...]
> Si, concordo, in effetti possono essere tutti miglioramenti. Possiamo 
> partire con una versione che sia concettualmente semplice ma che preveda 
> corpose estensioni, ed ampliarla di continuo fino ad arrivare alla 
Pensa ai concetti che stanno dietro ai cluster :).

[...]

> C'hai ragione pure te. Senti, se facessimo che chi e' nattato se lo 
> piazza nel paiolo? O rimandiamo le seghe sulla questione nat a piu' 
> tardi, anche perche' non vedo soluzioni ovvie alla cosa!
Naaa... O si fanno bene i lavori o non si fanno. A questo punto però
preferisco anch'io rimandare la discussione a quando avremo qualcosa di più
concreto.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]