[winsock] Test multiplayer ECCELLENTE!

[okay]

Ho finito di testare il multiplayer con winsock per me winsock batte Directplay.

Download per il test:
http://www.twork.it/work/Oki_Winsock_Multiplayer.zip
sono solo 72kb

Funzionamento:
- Lanciare il server che rimane in ascolto
- Lanciare tanti client quanti si vogliono (io ne ho testati 8 con fluidità di send e recv pazzesca!!)
- Per ogni client immettere il nome del player, per migliore lettura/visualizzazione dei dati di ricezione nella console server o client è meglio digitare il nome con uguali caratteri su tutti i client tipo:
okay
ciao
pixe
ecc ecc.

Se uscite con un client esso rientrearà nel giusto id.

Vorrei sapere le vostre impressioni

grazie amici

[MEMon]

Ciao ho provato, dopo che inserisco i nomi mi viene fuori una sfilza di ricevuto:0

[okay]

Originariamente inviato da MEMon

Ciao ho provato, dopo che inserisco i nomi mi viene fuori una sfilza di ricevuto:0

Ho provato anche io per vedere se avevo sbagliato a zippare.

devi lanciare il server e non digitare nulla su di esso.
Poi lanci 2 client in uno scrivi okay e premi return, i dati con un solo cient non arrivano, perchè chi invia i dati non li riceve dal server. Poi lanci l'altro client e scrivi memo e premi return.

dovresti vedere i dati in arrivo sul server e il client

[MEMon]

Ok, credevo fosse una chat

[MEMon]

Ma poi che metodo userai per spedire i dati dei vari cliants? Cioè pensi di spedire ad ogni cilco di gioco?

io ci sto pensando proprio in questi giorni per il mio giochino, e in effetti è un bel problema, se spedissi ad ogni ciclo occuperei gran parte della banda, ma se spedissi meno volte potrei vedere un giocatore dove effettivamente non sta!
E' un bel casino...

I tuoi dati da spedire quanto sono grandi grosso modo?

[okay]

Originariamente inviato da MEMon

Ok, credevo fosse una chat

Hai visto gli ms... e pazzesco!!!

con Directplay (in Game) con solo 3 clients loggati gli ms oscillano in un range tra 0.50/140 ms
con questo netcode fatto con winsock (il mio test con 10 client) gli ms oscillano tra: 0.000 (ho dovuto aggingere %3f forse serve anche %4f) e 0.003f ms... ma non è incredibile?

Ma poi la fluidità dello scorrimento dei dati e secondo me imbarazzante

[okay]

Originariamente inviato da MEMon

Ma poi che metodo userai per spedire i dati dei vari cliants? Cioè pensi di spedire ad ogni cilco di gioco?

io ci sto pensando proprio in questi giorni per il mio giochino, e in effetti è un bel problema, se spedissi ad ogni ciclo occuperei gran parte della banda, ma se spedissi meno volte potrei vedere un giocatore dove effettivamente non sta!
E' un bel casino...

I tuoi dati da spedire quanto sono grandi grosso modo?

Il test che stai facendo già invia i dati del multi essi sono di 172 bytes ogni invio i 172 bytes inviato sono così composti:

int id // id del giocatore
char nome // nome del player
tBikeData Data //dati della posizione del giocatore
char mess //messaggio che può essere inviato a tutti o al gruppo di gioco
//tipo blu contro bianchi solo i blu si inviano i messaggi per le proprie strategie nel game

Prova a lanciare 10 client e poi scollegane qualcuno e poi riconnettili come vuoi. I dati , che puoi monitorare, sono di una fluidità pazzesca. Ogni client non perde un colpo.

Non capisco il tuo modo di sincronizzare i client.
Io non sincronizzo nessun client.

Pensa che non uso thread. Hai notato che sincronia idati ricevuti sul server? e che velocità?

Mentre sul client i dati cmq arrivano sempre molto velocemente. Alle volte tutti in fila sono mostrati i client alle volte no. Ma la posizione del giocatore è sempre aggiornata perfettamente.


Io uso TCP, come ti dissi molto + affidabile del' UDP dove devi fare troppi controlli a mano e i dati di UDP sono inviati in sequenza non ordinata insomma è di difficile gestione.

[okay]

scusa mi sono dimenticato...

si invio i dati per frame/rate

[MEMon]

Ma hai provato a usare questo codice realmente in rete? Provarlo in locale è estramente diverso che provarlo in rete.
Ma come lo conti il tempo? perchè mi sembra un po' improbabile che hai un ritardo di 0 ms tondi tondi.
Comunque nel server noto che a volte non riceve in ordine(sto provando con 4 clients) ma ad esempio 0110 0122 0123 0233 è normale o ti aspetti che riceva sempre con ordine 0123?

[MEMon]

Io non sincronizzo i client mi limito solo a spedire la posizione del giocatore, comunque i miei dati sono all'incirca un centinaio di bytes(per ora ma penso di calare) e la banda occupata è davvero tanta se spedissi per ogni ciclo.
Suppongo che te non hai ancora fatto prove relai in rete...altrimenti te ne saresti accorto!

[MEMon]

Comunque a vederlo così sembra molto buono! complimenti!
Sopratutto per il fatto che non hai usato i thread, suppongo che non hai nessun metodo bloccante.

[okay]

Originariamente inviato da MEMon

Comunque a vederlo così sembra molto buono! complimenti!
Sopratutto per il fatto che non hai usato i thread, suppongo che non hai nessun metodo bloccante.

esatto nessun thread.
il metodo è il non-block.

cmq Directplay in locale 25/50 ms in rete 90/150 ms
winsock asincrono in locale 25/50 ms in rete 90/150 ms
winsock non-block in locale 0.000/0.003 (come hai visto) in rete lo devo provare prossimamente ti faccio sapere... ma se tanto mi dà tanto!!

sul server:
0123 sempre
sul client
0123 0123 poi può accadere sul client
0111 0011 2222 2222 2222 1111 1233 1233 poi di nuovo in sequenza 0123

ma questo è normale le posizioni e qualsiasi altro dato sul client sono mantenute, c'è lo eravamo detto.

Una cosa interessante è il server che mantiene sempre la sequenza ciò vuol dire che i dati arrivano ok.

Verso i client il server smista con if for per tutti penso che il recv sul cient sia normale che faccia così l'importante è che le posizioni siano rispettate sul client e questo è dovuto sempre ad un netcode veloce di ms come il non-block.

Ti faccio sapere in rete per il non-block ma sono fiducioso anche con pareccho client. vediamo