[Fwd: Re: [Ainulindale-devel] Network Level]

[Andrea Negro]

-----Messaggio Inoltrato-----

> From: Andrea Negro <address@hidden>
> To: Federico 'Derfel' Stella <address@hidden>
> Subject: Re: [Ainulindale-devel] Network Level
> Date: 14 Apr 2002 21:27:13 +0200
> 
> Il dom, 2002-04-14 alle 17:09, Federico 'Derfel' Stella ha scritto:
> > * domenica 14 aprile 2002, alle 15:51, Andrea Negro scrive:
> > 
> > [...]
> > 
> > >   + Prima cosa, che tutto cio' che il server non necessita di sapere, 
> > > potrebbe venirlo a sapere in un secondo momento: si puo' usare una 
> > > specie di buffer nel client in cui mettere eventi secondari da mandare 
> > > al server, e poi mandarli quando un monitoraggio del carico di rete 
> > > comunica che c'e' banda libera per l'invio. Eventualmente, su questi 
> > L'idea più corretta è quella di avere code di priorità per i messaggi da
> > inviare e svuotare (o cercare di) prima le code a priorità maggiore, ma
> > questa è una decisione che spetta al "net-scheduler" o come cavolo lo
> > chiameremo.
> 
> Yep. In linea di massima mi sembra di 'vedere' oggetti <coda>, con
> almeno un metodo per aggiungere un messaggio in coda, e altri metodi per
> settare i parametri della coda. Ad esempio, si puo' settare il livello
> di compressione, la priorita', o che tipo di connessione necessita, in
> modo che il net-scheduler possa gestire questi oggetti e comportarsi
> correttamente.
>  
> > > pacchetti di dati si puo' operare una compressione potente: visto che 
> > > non sono urgenti, il server puo' anche tenerseli compressi finche' non 
> > > ha nulla da fare e scomprimerli quando non ha nulla da fare (o 
> > > eventualmente archiviarli compressi, dipende dal tipo di dato).
> > Forse prima sarebbe il caso di discutere di come trasportare le
> > informazioni. Io pensavo di utilizzare qualcosa di configurabile con
> > handshake iniziale che permetta di scegliere il metodo preferito.
> > All'inizio si potrebbe fornire:
> > * formato binario
> > * formato xml
> > * formato xml compresso
> 
> Se non sbaglio, il formato, binario o xml, e' un livello sopra il
> 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! ;) ).
> 
> > >   + Seconda cosa, si potrebbe pensare ad una gestione raffinata delle 
> > > connessioni p2p. Del tipo: se io faccio gruppo con altre 5 persone, 
> > > potremmo pensare di essere messi in un p2pG (peer-to-peer-group), e 
> > > tutte le comunicazioni "gtell" vengono fatte su questo p2pG 
> > Questa è una bella idea.
> > 
> > > (eventualmente, il client capogruppo invia bufferizzando secondo il 
> > > punto precedente il log delle conversazioni al server, in modo da 
> > > evitare duplicati verso il server. Credo inoltre che un traffico del 
> > Più che il capogruppo quello con la migliore connettività nei confronti del
> > server. Bisogna anche stare attenti a non saturare la banda al povero
> > sfortunato ;-).
> 
> 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.
> 
> > [...]
> > 
> > > Che ne pensate? Che sparate voi? :)
> > Direi che sarebbe bello dare la possibilità di connettersi un un canale
> > crittografato e poter restringere la possibilità di connessione a certi
> > domini/IP.
> 
> Si, mi pare sacrosanto!
> 
> > A me piacerebbe per esempio rendere tutti gli elmenti della mappa/gioco
> > scaricabili in modo che il download delle informazioni non modificate si
> > debba fare una sola volta e non ad ogni sessione.
> > I protocolli per questo potrebbero essere:
> > * HTTP: che permette ai client di sfruttare i proxy esistenti.
> > * rsync: che permette di trasferire solo le modifiche effettuate.
> 
> Ottimo!
>  
> > In conclusione il p2p è interessante, ma bisogna ricordarsi che esistono
> > reti dietro a nat.
> > Se ci sono n client e tutti si trovano dietro a nat non è possibile
> > instaurare un p2p.
> 
> 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
> 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
> gateway per il client; o potremmo prevedere nella struttura p2pG il
> fatto che da uno stesso IP possono connettersi piu' client (per esempio,
> identificando il messaggio con un id del client che lo ha generato),
> anche se verrebbe generato del traffico inutile. Facciamo evolvere sto
> p2pG! =)
>  
> -- 
> Kind Regards,
> Andrea Negro
>  
> IBM Linux Team
> -------------------------
> Mobile: +39 347 4008768
> Office: +39 02 59620441
> Email: address@hidden
> Icq: Nepher, 25458773