[JAVA] Dubbi sul MulticastSocket e un po' di UDP

[kevinpirola]

Ciao a tutti, sto provado ad implementare un piccolo giochetto, ho pensato, per velocizzare la comunicazione tra server e client (soprattutto sui movimenti) che il server potesse inviare i messaggi ai vari client in multicast tramite il socket MulticastSocket che è un estensione del DatagramSocket, questo invece di usare la normale classe Socket e ServerSocket per creare il collegamento client-server (o meglio, non solo). In questo modo nel server era presente un solo MulticastSocket che comunicava con tutti i client che mi interessavano.

Faccio un esempio pratico anche se esula un po' da quello che devo fare io ma è molto simile e poi vi pongo la domanda.

Classico tilemap based game MMORPG.
In ogni mappa ci sono X utenti, quando l'utente x1 si muove manda un messaggio al server (in tcp tramite Socket e ServerSocket), il server lo riceve, lo elabora e lo rigira a tutti i client connessi ad una lista (in questo caso tutti gli X utenti connessi a quella mappa, x1 compreso) in modo che tutti vedano il movimento.

Questo si può fare sia con una ArrayList<Socket> dei vari socket (o meglio ci sarà una classe SocketHandler, ma il concetto è quello) e inviare con un ciclo il messaggio one-to-one ad ogni client, oppure si può fare tramite MulticastSocket.

Sul primo sono abbastanza navigato, sul secondo molto meno.

però a me interesserebbe molto fare arrivare le informazioni ai vari client allo stesso tempo (o almeno tempi confrontabili).

Non sono sicuro però sull'implementazione, infatti, nel TCP normale avevo due classi diverse (ServerSocket e Socket) il Socket si connetteva al ServerSocket in ascolto. Il ServerSocket generava quindi un Socket che "linkava" al Socket del client stabilendo la comunicazione in andata e ritorno.

Con il MulticastSocket invece mi ritrovo una singola classe, perciò non c'è nessuno che fa da server rispetto ad un altro così ho fatto una prova di implementazione mooolto basilare e volevo avere la vostra opinione:

public class Multicast{

	public static void main(String[] arg) {
		byte[] buffer = new byte[65535];
		try {
			int port = 5000;
			MulticastSocket sock = new MulticastSocket(5000);
			InetAddress addr = InetAddress.getByName("235.0.0.1");
			sock.joinGroup(addr);
			while (true) {
				DatagramPacket packet = new DatagramPacket(buffer, buffer.length, addr, port);
				sock.receive(packet);
				String address = packet.getAddress().toString();
				InetAddress client = packet.getAddress();
				int client_port = packet.getPort();
				System.out.println("Received : '" + new String(buffer).trim() + "' from " + address + "\n");
				// send information to the client, questa parte al momento non è utilizzata, i messaggi sono inviati dallo shooter
				//String message = "RECEIVED";
				//buffer = message.getBytes();
				//packet = new DatagramPacket(buffer, buffer.length, client, client_port);
				//sock.send(packet);
			}
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

	}
}

public class MulticastMessageShooter {
	public static void main(String[] arg) {
		MulticastSocket s1;
		byte[] buffer = new byte[65535];
		try {
			s1 = new MulticastSocket(5000);
			int port = 5000;
			InetAddress addr = InetAddress.getByName("235.0.0.1");
			s1.joinGroup(addr);
			while (true) {
				DatagramPacket packet = new DatagramPacket(buffer, buffer.length, addr, port);
String(buffer).trim() + "' from " + address + "\n");
				String message = "RECEIVED";
				buffer = message.getBytes();
				packet = new DatagramPacket(buffer, buffer.length, addr, 5000);
				s1.send(packet);
			}
		} catch (IOException e) {
			// DONOTHING
		}


	}
}

Io lancio 3 o 4 istanze della prima classe e poi faccio andare per un tot la classe shooter che mi spara qualche messaggio Multicast. Se poi vado a leggere, tutte le istanze hanno ricevuto i messaggi.

Il fatto è che non ho differenze tra client e server, l'unica cosa che mi viene in mente è che magari il server invia e basta (perciò non implemento il ciclo in ascolto) e il client riceve e basta, le altre comunicazioni che dovrebbero avvenire singole (il client manda le coordinate al server e solo al server, poi il server le checka, se sono buone manda il comando di movimento alle gui e perciò anche alla gui di colui che ha inviato il messaggio, facendo muovere il personaggio, altrimenti non manda alcun messaggio (e il personaggio non si muove)) avvengono tramite ServerSocket e Socket in TCP.

Sono giusto con i ragionamenti? Mi sembra un po' troppo aperta la MulticastSocket, e poi quell'IP là che sta nel famoso range tra 224.0.0.0 e 239.255.255.255 come lo scelgo? non c'è possibilità che tra quegli ip ci sia qualcuno che invia messaggi? devo codificare ogni messaggio?


Attendo vs risposte di qualsiasi tipo, anche se sono critiche sul codice sono molto ben accette

[banryu79]

Ciao, credo che questa trail potrebbe chiarire i tuoi dubbi.
In particolare la terza parte, quella titolata "Broadcasting to Multiple Recipients".

Edit:
Poi non so se fa al caso tuo, ma potresti valutare l'uso di canali non bloccanti tra i client e il server.
Su questo forum c'è un eccellente tutorial in merito, ecco il link

[kevinpirola]

Ti ringrazio, la lettura sui Socket non bloccanti è stata veramente piacevole inoltre è fatta veramente bene, fossero tutte così le lezioni dell'università

Quello che innanzitutto mi viene da pensare riguardo al socket non bloccante (che l'autore consiglia perchè ottimizza le prestazioni e minimizza i tempi morti sui singoli thread) è che la mole di informazioni che avrò io è diversa, perciò il singolo thread non è proprio sprecato, nel senso, come minimo in ingresso dal singolo client avrò circa 3/4 messaggi al secondo dovuti allo spostamento sulla mappa, aggiungici la chat, le azioni e le interazioni del gioco... il tutto diventa abbastanza pesante, per tale motivo mi trovo un po' scettico sull'utilizzo di un singolo thread e un singolo serversocket...

Per quanto riguarda invece il Multicasting UDP mi fa paura la frase:

A datagram is an independent, self-contained message sent over the network whose arrival, arrival time, and content are not guaranteed.

Cioè non so se arriva nè quando nè se quello che contiene è giusto?.. stica....

Nel senso, se la differenza di arrivo tra due messaggi è minima posso anche accettarlo, ma se sono tempi discreti potrebbe essere un problema, immaginate, prima lo sprite del giocatore si muove di tre caselle in avanti poi da solo torna 2 caselle indietro perchè riceve il messaggio vecchio.....lol

[banryu79]

Ti ringrazio, la lettura sui Socket non bloccanti è stata veramente piacevole inoltre è fatta veramente bene, fossero tutte così le lezioni dell'università

Vero? Secondo me PGI ha un talento naturale, spiega benissimo, e si fa leggere volentieri.

Beh, partiamo considerando il fatto che, tra tutti i tipi di giochi che si possono programmare i MMORPG, come tipologia, sono forse i più complessi in assoluto (leggi: bagno di sangue).

Solo la questione del networking nei giochi (TCP vs UDP) merita un discorso a parte. Se per te tutto quest'ambito è nuovo, forse è il caso che ti prendi un po' di tempo per setacciare informzioni in giro e capire con cosa avrai a che fare.
Se sei curioso, leggiti questo:
[The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter -- By Peter Lincroft]
Anche questa discussione potrebbe interessarti:
[UDP vs TCP/IP - Java]

Poi, ti segnalo questo forum come ottima fonte di info riguardo al fare giochi in Java, al fatto di voler fare un MMORPG, e a TCP/UDP per i giochi (visita la sezione "Networking and Multiplayer"):
Java-Gaming.org
Ti assicuro che il tempo la speso non sarà buttato via

Per finire:

Cioè non so se arriva nè quando nè se quello che contiene è giusto?.. stica....

Esatto, sì, ma è il protocollo UDP ad essere così: nessuna garanzia ne sul fatto che i pacchetti arrivino a destinazione ne sul fatto che arrivino in ordine. Ci sono pro e contro. Se invece vuoi dette garanzie, c'è il protocollo TCP. Anche qua: pro e contro, bisogna conoscerli.

[kevinpirola]

Ti dirò, l'idea del gioco è veramente molto più complessa di quanto io possa immaginare, perchè l'idea non è solo di fare un normale mmorpg ma implementare molte altre funzionalità come ad esempio il gioco con il mouse e tante tante altre cose.

Sto partendo dalla parte però principale ovviamente, al momento di scritto ho solo interfacce e poco più, perchè voglio assolutamente delineare le cose come si deve.

Sul networking non sono nuovo, ho avuto moltissimo a che fare con il TCP e il famoso Socket e ServerSocket (sto sviluppando con l'università un grosso progetto di un programma peertopeer di cui gestisco il server IRC distribuito al momento), di UDP avevo studiato la teoria (*poca*) ma mai implementato. Sono a digiuno di networking applicato al gaming, quello si, ma sono proprio qui per informarmi, io sono molto dell'idea -> poche prove tanti libri, ed è quello che sto facendo, ho trovato anche un libro (mi sfugge il titolo ma l'ho tra i preferiti e sarà il prossimo acquisto) dedicato alla programmazione di giochi in java.

Ti ringrazio veramente moltissimo per il materiale che hai fornito, quello però al momento non posso (non devo, domani ho un esame, devo concentrarmi sul VHDL!) leggerlo, lo guarderò domani con calma.


L'idea però è di mettere su un team di sviluppatori che lavori su features separate in modo da diluire il lavoro e meno si fa, in teoria, lo si dovrebbe far meglio. Il fatto è che io sarò il responsabile del progetto, e secondo il mio punto di vista se uno deve essere il responsabile le cose deve sapersele fare tutte da solo, per poi delegare, ed eventualmente controllare che tutto vada bene alla fine...

Al momento ho messo al lavoro un grafico per le ambientazioni e ho "prenotato" un programmatore per settembre. In settembre però vorrei già uscire con la prima alpha di prova con le funzionalità minimali... speriamo bene

[kevinpirola]

ho letto i vari articoli che mi sono stati consigliati, non sono però riuscito ancora a tirare fuori una conclusione, alla fine si va a gusti, a prove e a culo?

l'idea mia era

il giocatore invia un messaggio tcp al server che riceve elabora e multicasta un messaggio udp a tutti quelli della mappa

altre comunicazioni invece sempre tramite tcp che non hanno bisogno di gran realtime

[banryu79]

Ciao, ti ho postato i link perchè è il massimo che potevo fare per aiutarti, io non mi sono mai cimentato direttamente con la realizzazione di un gioco che faccia uso dei socket, quindi di più non so dirti, anche se, credo come al solito, la scelta tra tcp o udp e con che strategia implementativa dipende dai dettagli della tua applicazione.

Certo consigli e indiciazioni da chi ha esperienza di prima mano in questo campo sarebbero di aiuto... comunque il forum linkato ti potrà servire, proprio in tal senso, è frequentato da gente in gamba.

L'unica "massima" che ho letto era una del tipo "vai con tcp all'inizio e se poi non funziona passa a udp".
Magari nel tuo caso la tua strategia è già un filo più raffinata, comunque ti resta il "problema" di gestire l'eventuale drop dei pacchetti udp... una strategia naive potrebbe essere quella che ogni datagramma spedito contiene anche quello spedito precedentemente, però bisogna vedere se è adatta al tuo caso.

Alla fine saranno le prove sul campo che dimostreranno la validità di una soluzione piuttosto che un'altra.

[kevinpirola]

si può essere una idea, ti ringrazio molto per l'aiuto, ora sto scrivendo fogli su fogli di idee, schemi, prove... prima o poi comincerò anche a buttar giù codice .D

[banryu79]

Originariamente inviato da kevinpirola

si può essere una idea, ti ringrazio molto per l'aiuto, ora sto scrivendo fogli su fogli di idee, schemi, prove... prima o poi comincerò anche a buttar giù codice .D

Se hai 10 minuti, leggiti il seguente link (è breve), ti può dare uno spunto eccellente (non che devi usare quell'approccio, ma che conoscendo il proprio sistema/engine/applicativo e con un po' di "insight" si può trovare la soluzione giusta, magari confrontandosi anche con altri che hanno avuto esperienze simili):
http://trac.bookofhook.com/bookofhoo...ake3Networking