Re: [Ainulindale-devel] Re: Network Level

[Andrea Negro]

Federico 'Derfel' Stella wrote:
> * domenica 14 aprile 2002, alle 21:28, Andrea Negro scrive:
>
> > Il dom, 2002-04-14 alle 17:09, Federico 'Derfel' Stella ha scritto:
> >
> > > * domenica 14 aprile 2002, alle 15:51, Andrea Negro scrive:
>
> [...]
>
>
> > livello di trasporto; comunque mi sembra una buona cosa, ogni tipo di
> > connessione potrebbe essere identificata logicamente da una coppia
> > transport[protocol, format] (la sintassi e' casuale, non vuole
> > sottintendere nessuna struttura... e' un meta linguaggio! ;) ).
>
> Scusa potresti spiegarti un po' meglio?

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...
2) Che tipi di connessioni possiamo e vogliamo usare, uni/multicast, 
tcp, udp, etc etc
3) Che tipo di formato di dati utilizzare, come dicevi tu: binario, xml, 
etcetc.

Quello che volevo dire e' che il passo finale e' assegnare ciascuna 
tipologia di cui al punto 1 :) ad una combinazione dei punti 2 e 3; nel 
senso che usare xml/uni.tcp ha proprieta' diverse da un bin/multi.udp, e 
quindi la tipologia di dati da assegnare e' diversa, secondo le esigenze.
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.

> [...]
>
> > Concordo! In effetti se implementiamo un sistema per monitorare la banda
> > disponibile, si puo' anche pensare che il client che tiene le
> > comunicazioni con il server sia scelto in modo trasparente dalla rete
> > p2pG stessa, a seconda di chi al momento ha piu' banda.
>
> Hai capito quello che pensavo io, ma vado più avanti. Se il gruppo è
> particolarmente nutrito anzichè lasciare l'onore ad un solo client o non
> distribuire affatto il carico si può utilizzare la connettività dei client
> migliori.

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 
versione complessa: a quel punto pero' dovremmo fare un po' di testing 
per capire se l'aumentata complessita' porta un reale vantaggio in 
termini di prestazioni, altrimenti e' inutile farsi seghe mentali! :)

> [...]
>
>
> > Vero, potrebbe essere un problema. Come prima ideuzza in merito mi
> > verrebbe da pensare che ciascun client debba essere informato (tramite
> > configurazione dall'utente) se e' nattato, e nel caso prendere
>
> È un'opzione che non utilizzerebbe nessuno.

Beh, se ci fosse, chiunque fosse nattato! :)

> > contromisure. Per esempio, potremmo pensare che per queste particolari
> > esigenze il server venga in aiuto, aprendo una connessione diretta con
> > il client nattato e inserendosi esso stesso nel p2pG, facendo quindi da
>
> Veramente questo è proprio quello che non puoi fare. Quando un client è
> nattato non ha la possibilità di ricevere connessioni dall'esterno.

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!

--
Kind Regards,
Andrea Negro

IBM Linux Team
----------------
Mobile: +39 347 4008768
Office: +39 02 59620441
Work Email: address@hidden
Home Email: address@hidden
Icq: Nepher, 25458773