Luigi Auriemma

scusate se chiedo forse l' ovvio, ma in rete non trovo info

dunque, se con uno sniffer VB leggo i pacchetti che mi arrivano da un qualsiasi server di America's Army... c' ?? modo di capire il concetto seguito dal motore UT nell' invio dei pacchetti?

cio??, immagino in quei pacchetti ci saranno info sul numero di players, punteggi, flag di fine match ecc ecc...

c' ?? modo di approfondire la conoscenza su come sono organizzati e come leggere questi dati (non parlo di programmazione in s??, nessun problema su sniffare e leggere con VB6 o VB2008), ma prorio di capire dove andare a cercare questi dati nei pacchetti... se non so cosa leggere, non posso leggere :)

insomma, questi sono dati standard e conoscibili, o sono un segreto del motore UT?

lo sniffer non serve a molto con il protocollo usato da Unreal in quanto il modo in cui sono letti/scritti i dati e' decisamente complesso.

prima di tutto fa' ampio uso di bits (ecco perche' non vedi nulla se provi a sniffare) e metodi atti a usare meno bytes/bits del normale, tipo far occupare un solo byte ad un numero a 32 bit che dovrebbe occuparne 4.

poi e' diviso in vari canali, che sono Control (1), Actor (2) e File (3) piu' se non sbaglio vari sottocanali (ChIndex).

ora, mentre per i canali Control e File non ci sono assolutamente problemi in quanto il loro formato e' abbastanza standard, lo stesso non vale per l'Actor che e' quello che contiene tutti i dati di gioco (movimenti, azioni, messaggi e cosi' via) ed e' non solo incasinato ma anche abbastanza differente per ogni gioco basato sul motore di Unreal.
Qualche mese fa' difatti provai a gestire questo canale che e' costituito da circa 228 tipi di dati ma arrivato a circa 80 mi sono rotto le palle anche perche' la cosa non mi sembrava un granche' per vari motivi.

Comunque il plugin sperimentale che feci per sudppipe (un proxy udp) e' disponibile al link seguente e permette di vedere il contenuto dei canali Control e File e dumpare il contenuto grezzo del canale Actor:

http://aluigi.org/papers.htm#unreal
http://aluigi.org/mytoolz.htm#sudppipe

comunque ripeto che e' sperimentale, difatti non implementa alcuna funzione di riconoscimento dei vecchi canali (quelli gia' aperti) che quindi vengono classificati come canale 0 (anziche' 1, 2 o 3).
esempio d'uso:

per l'help: sudppipe -l unreal_sudp -L "" SERVER 7777 1234
per America's Army: sudppipe -l unreal_sudp -L "-a -x" xp 7777 1234

dopodiche' collega il tuo client al server 127.0.0.1:1234 ed il tool sparera' a video tutto quello che riceve e riesce a parsare.

ciao luigi e grazie della risposta velocissima

in realt?? sniffando non ?? che non vedo nulla, vedo i pacchetti di dati in esadecimale... ma se ho ben capito me ne faccio poco o nulla senza prima averli decodificati

cercher?? di capire qualcosa dai tuoi programmi, anche se usi un linguaggio "per adetti ai lavori" un p?? ostico per me, che so programmare in VB ma so poco o nulla di reti

ad esempio, quando dici "dopodiche' collega il tuo client al server 127.0.0.1:1234 ed il tool sparera' a video tutto quello che riceve e riesce a parsare" ?? un p?? come se avessi parlato in arabo :)

qualche info in pi?? in italiano, se hai tempo e voglia, pls?

beh e' normale che sia un po' difficile la cosa, se fosse stata semplice il mio tool non sarebbe in stato "sperimentale" :)

comunque con quella cosa del collegamento intendevo dire che lanci il client, apri la console (~) e digiti "open 127.0.0.1:1234" cosi' il tuo client si collega a sudppipe il quale si collega al vero server (SERVER 7777) e cosi' puo' leggere tutti i pacchetti in entrambe le direzioni e visualizzarne il contenuto.

per il resto, non ho altre info... anzi al momento ho abbandonato lo studio del protocollo di unreal.

mi arrendo :)

dopo mesi di (ovviamente saltuaria) ricerca affermo, confermo, preciso e ribadisco di non capirci niente

tutto quello che vorrei capire in quei MALEDETTI pacchetti UDP ?? quale ?? la maledetta serie di Bytes (sempre che CI SIA una maledetta serie di bytes) che indicano ai PC client che una gara ?? finita e di mostrare il tabellone dei risultati...

ora, premesso che in rete non trovo nulla a riguardo, tu che evidentemente ne sai di pi??... hai idea di dove posso informarmi o chiedere??

chiederei direttamente sul sito dell' engine (pur con la certezza di una non risposta)... se solo ci fosse un solo indirizzo email in tutto il sito

farlo usando il protocollo grezzo e' decisamente arduo anche perche' sicuramente sara' sul canale Actor che e' un SPAM impossibile da gestire.

per quanto riguarda i bytes nulla da fare visto che vengono usati solo i bits.

invece per i contatti secondo me dovresti prima chiarire bene che soluzione adottare.
il client customizzato (sullo stile di unrealfp) e' da scartare quindi ti rimane l'idea di un mod per AA che faccia esattamente quello che ti server e nel qual caso devi discuterne nel forum del gioco.
un'altra idea sarebbe trovare un modo di interfacciarsi con il motore di AA ma non la vedo di facile realizzazione (penso che ad ogni modo serva un SDK)

il mio programma, AA Watcher, funziona gi?? ed ?? noto, avendo migliaia di downloads nelle varie versioni (per intenderci, su quasi 10.000 downloads ho ricevuto 0 euro 0 di donazioni) :)

solo che funziona in modo secondo me "artigianale": lancio una query alla query port del server ogni secondo e leggo la risposta del server stesso, risposta che essendo "in chiaro" la leggo direttamente come variabile stringa, senza problemi

In pratica "aggiungo" nel mio piccolo un carico sul server che potrei evitare leggendo i dati direttamente dai pacchetti UDP che il server comunque invia al PC client

ora sto rivedendo AA Watcher da VB6.0 a VB.net e volevo fare qualcosa di pi?? professionale, adottando appunto il secondo metodo

leggere bit invece che bytes non dovrebbe essere un problema insormontabile in VB.net, ma rimarrebbe comunque la domanda: quale sar?? mai la maledetta serie di bit che dice al Client che ogni singolo match ?? finito??

se lo chiedo sul server del gioco, secondo me, ?? come se lo chiedessi in ostrogoto a dei turchi... a mio parere ?? pi?? domanda da fare agli sviluppatori del netcode... ma a chi e dove????

beh dai una query ogni secondo non e' un carico cosi' tremendo, fai conto che i servers dei giochi piu' utilizzati devono rispondere a migliaia di queries piu' tutti i pacchetti dei giocatori.

inoltre l'idea di raccogliere dati esternamente al server ha svariati vantaggi come la compatibilita' con piu' giochi (la query penso sia la classica gamespy 2 se non erro quindi stra-usata), il non pesare sul server (l'idea del client occupa uno slot e per di piu' ci sono problemi con il protocollo se non e' chiaro al 100% come in questo caso) e soprattutto essere piu' semplice da gestire ed aggiornare.

se il problema e' solo sapere quando il match e' davvero finito penso che cio' possa essere visibile o almeno azzeccata nella normale query.
io non ho mai giocato ad AA pero' ad esempio ho notato il campo mission_time e mission_time_remaining che gia' ti possono essere d'aiuto e poi c'e' sempre il controllo definitivo quando vedi che i precedenti punteggi sono diminuiti.
effettuando la query ogni secondo hai un ampio margine di beccare gli ultimi risultati visto che il nuovo match (che io sappia) non inizia mai immediatamente ma sempre dopo 5 o 10 secondi

si, me ne rendo conto, il carico non ?? tremendo e controllando i time_ il programma funziona perfettamente, anche perch?? come dici giustamente ci sono quasi 10 secondi prima che parta una nuova gara

solo, dato che devo comunque sniffare per leggere l' IP del server di gioco a cui mandare le query, volevo prendere due piccioni con una fava, evitando oltretutto di inserire un controllo Timer nel programma

poi tra poco il gioco verr?? aggiornato alla versione UT3.0 del motore grafico... e che io sia dannato se riesco a trovare sul web le queries relative, che probabailmente sono diverse da quelle del motore UT2.5

esatto, l'UT3 usa le query gamespy3

scusa luigi, ma cedo le armi e non trovando nulla chiedo a te:

hai idea della serie di bytes da inviare per interrogare un server Gamespy 3??

anche questo sembra il terzo segreto di fatima... per le query precedenti trovavi info ovunque...

non e' che sia segreto, e' che e' stato reso complesso.
io l'ho implementato parzialmente in gslist ed e' ok.

praticamente prima richiedi al server un numero usato come "challenge", il contenuto del pacchetto e':

dopodiche' parti con la richiesta che e' lo stesso pacchetto che si usava nella query gamespy 2 ma ovviamente con in piu' il challenge:

ovviamente leggere da piu' pacchetti puo' essere una bella rottura di palle.

comunque ti do' qualche link con alcuni esempi in C, python, php che di sicuro ti possono spiegare meglio:
- http://sourceforge.net/project/showfile ... e_id=51888
- http://www.undermined.org/projects/pages/view/1
- http://manuel.mausz.at/gsquery.phps

per il resto fai riferimento al gamespy 2, in quanto a parte lo split ed il challenge dovrebbe essere lo stesso

grazie mille luigi, sempre utilissimo :)

mi ci metto dietro, grz ancora