ainulindale-devel
[Top][All Lists]
Advanced

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

Re: [Ainulindale-devel] Network Level


From: Andrea Negro
Subject: Re: [Ainulindale-devel] Network Level
Date: Tue Apr 16 05:00:02 2002
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313

Federico 'Derfel' Stella wrote:
* 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.

Io infatti, con questo discorso, non sono solo a basso livello, il mio era gia' un discorso giu' ampio. Intendo dire: noi abbiamo disponibili varie tecnologie di networking, come tcp, udp, multicast, p2p, etcetcetc; poi , a livello piu' alto, possiamo mandare i dati in binario, in xml, possiamo comprimere o meno, assegnare priorita' o meno, etcetcetc. Ora: ho da mandare i dati di aggiornamento sulla posizione dei personaggi, come li mando? Vediamo: se sono inerenti a pg che stanno combattendo col poverino, posso pensare di fare un multicast ai pg nell'area con udp, e usare un formato che sia il piu' compatto possibile, e mandare aggiornamenti con una frequenza superiore; se invece sono dati di log delle conversazioni tra pg sus p2pG, possono essere mandati con calma, e allora avranno bassa priorita', saranno mandati in xml, in tcp unicast.

3) Che tipo di formato di dati utilizzare, come dicevi tu: binario, xml, etcetc.

E qui c'è un'inconprensione: Il formato deve essere multiplo.
[...]
Tutto questo per avere un framework estensibile e debuggabile in maniera
umana.

Come sopra: ho capito che a basso livello dovrebbe essere cosi', io parlavo nell'ottica della logica del gioco...

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 :).

Guarda, se penso a quelli, non ne usciamo veramente piu' da sta cosa! :)

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.

Allora la mozione e' approvata. Il protocollo p2p lo reinventiamo piu' in la'! :)

--
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




reply via email to

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