[Spike] Multiplayer e Netcode

[fek]

Ovvero, vi lasciamo i compiti per le vacanze e per lo sviluppo principale ci risentiamo all'inizio dell'anno prossimo

Quindi io e Vic vi proponiamo un bello Spike corposo e divertente: Multiplayer e Netcode.

Prendete qualche branch del gioco e vedete se riuscite a connettervi ad un gioco in esecuzione e a duplicare la sua griglia di gemme in locale.

Punti da tenere ben presente sul netcode:

- L'architettura dovra' essere il piu' possibile peer-to-peer, quindi entrambi i giocatori fanno contemporaneamente da server e da client, ovvero nessuno deve essere avvantaggiato dalla latenza.

- Sarebbe bello funzionare anche dietro ad una NAT...

- ... e magari usando il protocollo HTTP

- Eventualmente studiare l'uso di un protocollo di trasporto basato su UDP o TCP.

In pratica, vorrei che il livello di trasporto fosse il piu' possibile astratto e ben separato dalla logica del netcode.

Studiateci un po' e diteci qualche possibile soluzione a questi problemi.

[71104]

possiamo eventualmente creare una nostra versione del gioco aggiungendo qualche pezzo non TDD per gestire il networking da mettere poi nella cartella degli spikes? ovviamente senza affezionarci troppo a quello che scriviamo

[fek]

Originariamente inviato da 71104

possiamo eventualmente creare una nostra versione del gioco aggiungendo qualche pezzo non TDD per gestire il networking da mettere poi nella cartella degli spikes? ovviamente senza affezionarci troppo a quello che scriviamo

Quando crei un branch nel quale fare gli spike puoi fare quello che pare a te

[cionci]

Originariamente inviato da fek

- Sarebbe bello funzionare anche dietro ad una NAT...

Impossibile se almeno un client non ha una porta aperta...

[fek]

Originariamente inviato da cionci

Impossibile se almeno un client non ha una porta aperta...

So che appoggiandosi ad un server esterno solo per la connessione, si puo' iniziare in qualche modo il canale e poi prosegue senza bisogno del server. Ma non domandarmi di piu'

[cionci]

Passando da un server esterno è facile...riguardo al fatto che c'è il server che inizia le connessioni e poi i client continuano da soli: non ho mai sentito di questa cosa, ma presumo che sia una possibilità di UDP (magari facendo uno spoofing dell'indirizzo sorgente), ma sicuramente non del TCP...

[fek]

Originariamente inviato da cionci

Passando da un server esterno è facile...riguardo al fatto che c'è il server che inizia le connessioni e poi i client continuano da soli: non ho mai sentito di questa cosa, ma presumo che sia una possibilità di UDP (magari facendo uno spoofing dell'indirizzo sorgente), ma sicuramente non del TCP...

Si', credo di ricordare che sia una cosa che si puo' fare con pacchetti UDP, ma la mia preparazione in merito e' davvero minimale, di piu' non so' dirti.

[BlueDragon]

Bello questo Spike di Natale!
Mi sa che farò qualche prova nel periodo di ferie...

Originariamente inviato da fek

- ... e magari usando il protocollo HTTP

A che ci serve il protocollo HTTP? Pensi che il netcode necessario per Diamonds sia affine?

Originariamente inviato da fek

- Eventualmente studiare l'uso di un protocollo di trasporto basato su UDP o TCP.

Perché eventualmente? Direi che è quasi scontato che andremo ad usare UDP o TCP A meno che qualcuno di noi non conosca ed abbia dei motivi per usare altri protocolli a livello di trasporto tipo AEP,AMTP,ATP,IL,NBP,NetBEUI,RTMP,SMB,SPX,SCTP,RTP...
(vi confesso, ho fatto copia-incolla da Wiki, della maggior parte di questi protocolli non conoscevo manco la sigla.. )

Originariamente inviato da fek

- Sarebbe bello funzionare anche dietro ad una NAT...

Se uno dei due giocatori non è dietro ad un NAT, dovrebbe essere "semplice": basta che sia il giocatore dietro il NAT a contattare l'altro.
Altrimenti se sono entrambi nascosti dietro NAT servirebbe un 3o pc d'appoggio non dietro a NAT, che potrebbe essere permanente per tutto il gioco (soluzione "semplice", ma necessita di un pezzo di software sul 3o pc no?) oppure necessario solo alla connessione iniziale (più difficile, come ha detto cionci forse con IP spoofing oppure forse con alcune cose particolari del protocollo FTP con cui erano stati creati dei programmi per aggirare il problema NAT da parte degli utenti Fastweb... ma non sono per niente ferrato in questo campo . Anche in quest'ultimo caso però servirebbe un software installato sul 3o pc..come minimo un finto server FTP ).

[^TiGeRShArK^]

mmmm...non ho idea come funzionino i nat di fastweb...
ma ad esempio se la richiesta di connessione arrivasse DALLA macchina che è dietro il NAT all'altra non penso ci debbano essere grossi problemi....
o meglio... se i NAT di fastweb usano l'ip masquerading e qdi mappano ogni host su una particolare porta del server non ci dovrebbero essere problemi FINCHE' questi NAT accettino connessioni che non giungano dalle porte normali (HTTP, STMP, FTP)...
se non accettano queste connessioni... mi sa che ci dovremmo informare per vedere come superare il prob...

[^TiGeRShArK^]

Originariamente inviato da BlueDragon

A che ci serve il protocollo HTTP? Pensi che il netcode necessario per Diamonds sia affine?

me lo chiedevo anch'io...
penso che UDP sia + indicato visto ke è + snello...

Perché eventualmente? Direi che è quasi scontato che andremo ad usare UDP o TCP A meno che qualcuno di noi non conosca ed abbia dei motivi per usare altri protocolli a livello di trasporto tipo AEP,AMTP,ATP,IL,NBP,NetBEUI,RTMP,SMB,SPX,SCTP,RTP...
(vi confesso, ho fatto copia-incolla da Wiki, della maggior parte di questi protocolli non conoscevo manco la sigla.. )
Se uno dei due giocatori non è dietro ad un NAT, dovrebbe essere "semplice": basta che sia il giocatore dietro il NAT a contattare l'altro.
Altrimenti se sono entrambi nascosti dietro NAT servirebbe un 3o pc d'appoggio non dietro a NAT, che potrebbe essere permanente per tutto il gioco (soluzione "semplice", ma necessita di un pezzo di software sul 3o pc no?) oppure necessario solo alla connessione iniziale (più difficile, come ha detto cionci forse con IP spoofing oppure forse con alcune cose particolari del protocollo FTP con cui erano stati creati dei programmi per aggirare il problema NAT da parte degli utenti Fastweb... ma non sono per niente ferrato in questo campo . Anche in quest'ultimo caso però servirebbe un software installato sul 3o pc..come minimo un finto server FTP ).

infatti... lo pensavo pure io...
ma se questi due utenti sono tutti e due dentro fastweb... non usano in quel caso il loro indirizzo privato senza passare dal NAT?

[fek]

Originariamente inviato da ^TiGeRShArK^

me lo chiedevo anch'io...
penso che UDP sia + indicato visto ke è + snello...

Se non ci fossero grossi problemi di latenze, a me giocare anche dietro ad un proxy non dispiacerebbe affatto, sempre che fosse possibile

Ma e' una wishlist, ho buttato solo qualche idea, non conosco con precisione le implicazioni tecniche di tutto cio', ho giusto un'infarinatura sui vari protocolli.

Voi provate a farmi vedere il gioco che si connette ad un altro gioco e mostra la sua griglia e per ora e' gia' grasso che cola.

[Ufo13]

Bello questo spike!!! Mi ci metto pure io!!! Se cercate informazioni su questa storia del NAT e il tool che usava FTP vi consiglio di guardare qui: http://www.s0ftpj.org/bfi/bfi-it.html


C'è anche un programmino che si chiama mozzarella.c da qualche parte nel sito che dovrebbe tornare utile

[BlueDragon]

Originariamente inviato da ^TiGeRShArK^

me lo chiedevo anch'io...
penso che UDP sia + indicato visto ke è + snello...

Allora, innanzitutto bisogna precisare che HTTP, TCP ed UDP sono 3 protocolli ma non sono intercambiabili tra di loro...
TCP ed UDP sono protocolli di trasporto (livello 4), e quindi puoi usare uno o l'altro, ma l'HTTP è un protocollo applicativo (livello 7) e non è sostitutivo di TCP ed UDP.
Esistono vari livelli per la comunicazione tra due PC ed ogni livello ha un suo protocollo che si occupa di una parte della comunicazione... si parte dal basso, con il livello fisico, che si occupa di come i singoli bit vengano trasmessi a livello fisico sulla fibra ottica o doppino o quel che sia, salendo poi verso l'alto con il livello di collegamento (Ethernet ad esempio), il livello di rete (IPv4, IPv6...), il livello di trasporto (UDP, TCP..) fino ad arrivare all'ultimo livello che è quello applicativo (protocolli HTTP, POP3, SMTP, SSH, FTP...).
I livelli sono 7 in tutto e c'è di che farsi una cultura..basta fare una ricerchina su Wikipedia

Quindi quando noi ci connettiamo ad un sito tramite HTTP stiamo automaticamente usando non solo il protocollo HTTP, ma anche tutti i protocolli che ci sono sotto, tra cui ad esempio TCP o UDP.

Per quanto riguarda la questione dei NAT, è vero gli utenti Fastweb tra di loro usano l'IP di rete interna Fastweb, ma hanno comunque dei problemi nell'utilizzare applicazioni che dialogano con utenti non Fastweb, in particolare quando devono fare da server

Vi racconto un po' quello che so, così magari qualcuno più esperto mi corregge se ho delle conoscenze errate

Gli utenti Fastweb fanno tutti parte della rete interna Fastweb, come se fossero collegati ad un enorme LAN. Per uscire su internet, devono attraversare i router NAT. Come conseguenza di ciò, gli utenti Fastweb non hanno un IP personale su internet ma vengono visti con l'IP del router NAT da cui sono usciti. I loro IP sono nascosti all'esterno, quindi se un utente FW decide di tirare su un server, dall'esterno della rete non si può accedere al suo server perché l'ip della rete interna su cui sta il server non è visibile da fuori.
Se un utente fosse padrone del proprio NAT, potrebbe semplicemente dire al NAT "tutte le connessioni che ti arrivano su una certa porta, ad esempio 9999, mandale verso il mio IP di rete interna alla porta 5555".
In questo modo ci si potrebbe collegare dall'esterno alla porta IP-interno:5555 semplicemente usando l'indirizzo IP-NAT:9999.
Purtroppo però gli utenti Fastweb non sono padroni dei router NAT né possono chiedere un forward personalizzato (cioé quel reindirizzamento di cui sopra).
Per cui, si sono messi alla ricerca di soluzioni alternative...
Una di queste soluzioni prevedeva l'uso di un programma particolare che si connetteva a ripetizione verso un server FTP esterno. Tramite l'uso di particolari comandi del protocollo FTP (che io non conosco), era possibile fare in modo che il server NAT in mezzo tra PC Fastweb e Server FTP, tenesse costantemente aperta una sua porta con reindirizzamento per il PC Fastweb, creando quindi una sorta di forward personale permanente (finché girava il programma).
Questa tecnica però aveva due brutti effetti collaterali:
1) Il programma in questione si connetteva a ripetizione verso un Server FTP. Se il server FTP è di una persona consenziente, tutto apposto.. ma se il server FTP è un server pubblico, connettercisi a ripetizione e per giunta per scopi non collegati al normale utilizzo FTP è quantomento sconveniente no? Se non proprio illegale.
2) Con questo programma si otteneva un forward al proprio interno che io ho definito "personale".... e se qualcun'altro avesse avuto bisogno della porta 9999 sul NAT? Con che diritto si può tenere occupata la porta di un server NAT che viene condiviso da più utenti?
Quest'ultima è una mia speculazione, non so se effettivamente usando quel programma il forward sul NAT escludesse totalmente l'uso di quella porta per gli altri utenti..... le mie conoscenze non vanno molto lontano in questo campo
Magari dopo lo spike di Natale ne saprò di più :P

Cmq nel nostro caso non si tratterebbe di un uso continuativo che potrebbe sfociare in abuso, ma di una breve apertura di pochi secondi per permettere ai due client che fossero dietro due NAT di reti diverse (non tutti e due FW quindi) di "vedersi" per il tempo necessario a stabilire una connessione permanente (TCP?) tra di loro.
Mi immagino quindi questo scenario, che non so se sia fattibile...

* PC A dietro Fastweb
* PC B dietro ProviderStraniero
Entrambi con problema NAT.
* PC C senza NAT di un loro amico.

il PC C contiene un software (magari Diamond stesso) che permette una connessione di tipo FTP o cmq che abbia la logica necessaria ad effettuare quel forward temporaneo di cui sopra.

1) PC A si connette a PC C e tramite FTP ottiene un forward dal suo NAT al suo indirizzo interno.
2) PC B si connette a PC C e tramite FTP ottiene un forward dal suo NAT al suo indirizzo interno.
3) il PC C comunica a PC A e PC B gli indirizzi NAT-A:Porta e NAT-B:Porta dei forward tramite cui si possono parlare.
4) PC A e PC B effettuano grazie ai forward una connessione TCP tra di loro
5) PC A e PC B lasciano la loro connessione "FTP" verso PC C, ringraziandolo

Cionci? Che ne dici?

[BlueDragon]

Aggiungo che mi sentirei abbastanza volontario da seguire il seguente tipo di Spike, da solo o in compagnia:

- protocollo di trasporto TCP
(da tramutare eventualmente in UDP..o forse direttamente UDP, ci devo pensare un po'/vedere cosa c'è di già pronto in Java)
- protocollo applicativo: DiamondsCrush (un protocollo tutto nostro )
- Soluzione al problema NAT: utilizzo permanente di un "Diamonds proxy", software integrato a Diamonds oppure separato (a scelta).

In pratica quando due PC si trovano entrambi dietro NAT di due LAN diversi, si connettono ad un 3o PC esterno non dietro a NAT che funge da ponte per tutta la durata del gioco

[Ufo13]

Per il protocollo applicativo posso darti una mano... Non ho mai lavorato con java in rete però mi pare che si possano serializzare oggetti facilmente ed inviarli ad un host... Penso che il protocollo, se fosse così, starebbe nel trovare il migliore oggetto da utilizzare per il trasporto delle informazioni di sincronizzazione delle griglie tra gli host... Inoltre sarebbe una buona cosa cercare di rendere sicuro il protocollo

[cionci]

Anche io anche io

Lo facciamo test driven ? Secondo me si evita di fare molti errori

Anche io non ho mai programmato queste cose su Java (anzi, a dirla tutta, non mai programmato in Java prima di Diamonds, se non nel lontano 1994)...

Concordo su TCP...visto che è orientato alla connessione è sicuramente preferibile rispetto ad UDP... In teoria la latenza introdotta da UDP dovrebbe essere leggermente minore, ma per ora possiamo fregarcene...

Direi che la prima cosa da fare sia un metodo per la stima del RTT...in questo modo possiamo anche sincronizzare i timer dei due giochi...

[cdimauro]

A lavoro uso questo: http://www.zeroc.com/ice.html per realizzare applicazioni client/server e mi trovo benissimo.
E' chiaro che, in questo caso, ognuno dovrebbe fare da server e client contemporaneamente, ma non c'è problema.

Tra l'altro server e client ICE si possono realizzare anche in Java, che dopo il C++ è la "piattaforma" più supportata.

[fek]

Originariamente inviato da cionci

Anche io anche io

Lo facciamo test driven ? Secondo me si evita di fare molti errori

Anche io non ho mai programmato queste cose su Java (anzi, a dirla tutta, non mai programmato in Java prima di Diamonds, se non nel lontano 1994)...

Va benissimo scrivere lo spike test-driven ma tenete ben presente che tutto quello che scriverete nello spike sara' buttato e si ripartira' da zero per il codice di produzione. Quindi, come al solito, non attaccatevi troppo al codice che scriverete

Comunque il codice dello Spike non dev'essere robusto o privo di difetti, deve piu' o meno funzionare ed esplorare piu' soluzioni possibile ed incontrare piu' potenziali problemi possibile.

Direi che la prima cosa da fare sia un metodo per la stima del RTT...in questo modo possiamo anche sincronizzare i timer dei due giochi...

Assolutamente si', questo e' sicuramente il primo problema da affrontare.

[DioBrando]

Originariamente inviato da BlueDragon

cut

inrealtà i livelli sn 4 perchè si considera la suite TCP/IP, 7 per il modello OSI che però è troppo ridondante ( visto che suddivide inutilmente il livello applicativo in + sottolivelli) ed infatti n ha avuto successo

Se utilizzate il TCP, avrete la possibilità di maggiore affidabilità e del controllo degli errori, con l'UDP, mancando questa caratteristica ( e visto che il QoS viene implementato soprattutto a livello TCP), risulta un protocollo di trasporto + leggero ed infatti è quello che usano parecchi SW P2P decentralizzati ( Bit Torrent per es, nella connessione al tracker).

IMHO dovete provare a vedere quant'è l'effettiva larghezza di banda che occupate giocando in multiplayer e poi decidere se preferite qlc di + snello o qlc di + "reliable" come si dice


Cmq n mi scosterei tanto da questi due, che sn già supportati in tutti i SO ( ed il gioco nasce per essere portabile giusto?)...

[cisc]

ragazzi, per i giochi in java ho sentiito molto parlare di RMI, anche se sono abbastanza ignorante in materia, cerco di documentarmi e vi faccio sapere, cmq, sarei anche interessato a collabborare allo spike che usi udp....