Domanda Sorgente Metin2 e Controllo File Server

[Rhaenys]

Buonasera,

Inizio subito citando un soggetto che rispetto molto per i suoi release e guide, @iltizio , ovviamente conosco molti nomi noti leggendo le varie discussioni, ma se mi segnalate o taggate voi per me fareste un piacere .

Arrivo al dunque Apro questo post per chiarire alcune cose che mi affliggono, ultimamente ho iniziato a creare un server pure io. E tutti hanno quel desiderio di aprire un server dove le persone ci giocano è una soddisfazione personale ma non tutti hanno le competenze necessarie. Allora si affidano ai Dev che vendono servizi e file server.

La mia domanda è come si fa sapere se i file server che si compra oppure si ha in possesso sono dei file buoni per l'utilizzo?. Questa domanda ovviamente mi è sorta appena ho letto il post del Metin2Step dove nonostante iltizio aveva avvisato dei errori del file o altro avessero tenuto i file. Quindi la domanda è direttamente a il Tizio ma anche agli altri Dev.

1) Quanto sono importanti fixare gli warning che si presentano quando si compila la sorgente?
2) Quali sono cose da controllare prima di aprire un server al pubblico, oltre ai bug che appaiono da Quest, System etc. C'è qualcosa anche prima da controllare?
3) Prima di comprare file + Source ( che ormai sono d'obbligo) oppure dopo aver comprato che cosa c'è da controllare ?

Ovviamente Mi chiedo tutto ciò perché ho visto che molti finanziano il server ma non hanno competenze tecniche , ovviamente un conto fare GM, o modificare file root, pack etc un conto mettere la mano nella sorgente.

Scusatemi se non mi sono spiegato bene, oppure ci sono gli errori . Spero che possa avere le risposte in modo da aiutare me stesso ma anche agli altri.

PS - Questo post non è stato aperto per Esaltare iltizio oppure screditare il GF di metin2step, ma semplicemente vorrei imparare dagli errori dei altri a non fare lo stesso errore.

 

[iltizio]

Non c'è un modo infallibile per capire se un binario è buggato o no. La parola buggato è troppo varia e per scovare i bug e falle di sicurezza bisogna testare per bene, caso per caso, secondo gli strumenti a disposizione.
Nel caso di metin2step io ho trovato e notificato un bug che non permetteva di collegarsi da fuori, nonostante fosse tutto impostato correttamente a livello di rete. Per dimostrare ciò avevo fatto dei test rimanendo in ascolto sulle interfacce con tcpdump e i pacchetti passavano correttamente. Per dimostrare il bug avevo anche creato un semplice servizio di rete che se interrogata una porta TCP restituiva una stringa, e così è stato.

Avrai capito che questo non è un modo per definire se i file hanno bug o meno, ma è un metodo di troubleshooting da eseguire in caso di problemi per escludere possibili cause.

Morale della favola, per capire se dei file sono buggati per le vostre esigenze o meno (i file sono tutti buggati, Metin2 è un bug di per se), l'unico modo efficace è testare.

E per testare intendo prendere un server il più simile possibile a quello che utilizzerai in produzione e far entrare un po' di utenti a giocare, controllando i log e vedendo se tutto funziona, anche dopo i fix.
Alla fine i bug spuntano fuori quando provi.

I warning che vedi in fase di compilazione, solitamente, sono segnalazioni di funzioni deprecate. Significa che i sorgenti che stai utilizzando hanno un codice "vecchio" che può essere migliorato utilizzando del codice più aggiornato, adatto alla nuova versione del compilatore e librerie. I vantaggi, come potrai immaginare, sono simili a quelli di una versione più aggiornata di un software.

Altra cosa che dovresti controllare quando acquisti o comunque vuoi usare dei file, è vedere se sono presenti delle backdoor o potenziali falle di sicurezza, che con i test molto probabilmente non verrebbero fuori. Altra cosa da valutare per capire se i file potrebbero essere di qualità, è capire che competenze reali ha chi li ha fatti, valutando anche in che modo è scritto il codice, come è organizzato e se adotta un atteggiamento professionale. Uno che sviluppa per diletto, per la scuola, università o professione lo noti da molte cose, anche prima dell'acquisto.
Certe cose le noti solo se hai delle competenze di base, anche non specifiche di metin2.
Se tu come compratore non hai delle discrete competenze di base, cerca un secondo parere tecnico da qualcun'altro di competente, esterno o interno allo staff.
In ogni caso, come si è visto con il progetto citato da te, sarebbe utile, se non necessario, avere qualcuno con competenze tecniche anche solo basilari nello staff e disponibile.

In ogni caso non sono uno sviluppatore. Io mi occupo principalmente di tutto quello che ci sta attorno.
Lascio la palla a chi ne sa più di me riguardo ai sorgenti di metin2: @King Gherusio @Ikarus_ @North. @Arves100 @LoLLo©Heartlongju (ce ne sono altri, nhe!).

 

[Ikarus_]

Per la questione di Metin2Step , non mi sono mai espresso in merito e non voglio farlo ora , anche se io ho potuto vedere il "declino" nel suo svolgersi.
Voglio solo dirti che non è stata incompetenza del loro dev , ma solo assenteismo dello stesso (non so quale delle due cose sia maggiormente gravosa).
Le modifiche fatte al codice sorgente , erano in parte modifiche specifiche per il progetto di metin2step e quindi affatto debuggate in precedenza da altri ( diremmo in gergo che si tratta di codice "fresh" ). Quando si ha a che fare con nuove parti di codice mai debuggate da nessuno in precedenza, i problemi si riscontrano facilmente, ma solo perchè è venuta meno una fase essenziale che è quella di "debug" (e con ciò intendo puntualizzare che gli staffer stessi hanno ammesso le loro colpe riguardo il mancato test approfondito degli step).

Per rispondere invece alle tue domande:

1 ) Gli Warning :
Senza dubbio compilare migliaia e migliaia di righe di codice senza ricevere Warning rilascia nel sangue belle quantità di Endorfine.
Alcuni Warning sono però irrilevanti ( in realtà sono autonomamente risolti dal compilatore ) come per il caso delle chiamate deprecate (ma attenzione che non è sempre vero). Inutile dire che ci sono anche Warning che incidono anche sulle prestazioni , e quindi vanno ottimizzati. ( come ad esempio il forzato confronto di booleani).

2 ) Quali sono cose da controllare prima di aprire un server al pubblico ?
Warning a parte , vanno risolte tutte le segnalazioni di errore da parte delle varie componenti di debug (tutti i log).
E attenzione alle guide che propongono di risolvere un errore , commentandone la scrittura in log (le ho viste giuro).
Una cosa che vorrei specificarti , riguarda i file ".core" generati dal crash di un channel.
Purtroppo ho notato che in pochi sanno cosa effettivamente essi siano.
Ebbene sono dei file che ti restituiscono la "traccia" del problema.
Per poterli leggere è necessario eseguire il debug del binario con un debugger (freebsd ha installato di default gdb).
Attenzione alle strippate che date a caso. La strippata sul file binario rimuove tutte le informazioni di debug contenute nello stesso.
Non è possibile eseguire debug con un debugger su un binario strippato (che io sappia almeno) , quindi non strippate se non realmente necessario.

3 ) Cosa controllare prima di comprare file o source?

Non credo tu possa conoscere la qualità di un prodotto senza poterlo esaminare (ammesso che tu ne abbia le capacità per farlo).
Non penso quindi che ci sia un vero metro di giudizio pre-acquisto.
Posso solo dirti di acquistare da persone stimate , e con un bel feedback VERIFICATO alle spalle.
Non fidarti di chi ti dice , ti mando il contatto di un mio cliente per farti confermare che il prodotto è buono (ti manderà il contatto di un suo amico) , è meglio che sia tu a conoscere più di un cliente se possibile. (ho le chat di chi fa queste ruberie , non parlo a caso)

Spero di esserti stato utile , più di questo non saprei cosa aggiungerti.
Spero di non averti suscitato maggiori dubbi

Dubito che ti trovi nella sezione adeguata , non credo che in questa sezione si possano fare domane/richieste.

 

[Rhaenys]

Vi ringrazio per il chiarimento, ovviamente dai vostri commenti ho capito anche cose di cui sottovalutavo.

Ci sono due cose da fare allora da quanto ho capito

1) Lasciare che i giocatori entrino provino tutto quello che vogliono, facciano crashare il server, facciano esplodere, provino tutte le variabili possibili, solo quando avranno mandato off oppure Bloccato avrò la possibilità di trovare un errore e escluderlo prima dell'apertura del server in modo che non si presenti.

2) Provare a leggere tanto, in modo da capire che cosa si ha in mano e come usarli.

 

[Ikarus_]

Vi ringrazio per il chiarimento, ovviamente dai vostri commenti ho capito anche cose di cui sottovalutavo.

Ci sono due cose da fare allora da quanto ho capito

1) Lasciare che i giocatori entrino provino tutto quello che vogliono, facciano crashare il server, facciano esplodere, provino tutte le variabili possibili, solo quando avranno mandato off oppure Bloccato avrò la possibilità di trovare un errore e escluderlo prima dell'apertura del server in modo che non si presenti.

2) Provare a leggere tanto, in modo da capire che cosa si ha in mano e come usarli.

La questione del bloccare spegnere far esplodere , non l'ho capita.
Però in linea di massima si , serve testare per scovare i problemi.
Se non ti rechi da un Dev e decidi di usare file presi da internet, attento a non usare dei file bucati (molti rev 40k hanno una backdoor).
Puoi anche controllare che nei tuoi file siano presenti i fix contro gli exploit auth (che sono più di uno , li trovi in giro).

Ps : non bisogna necessariamente che il channel crashi per ottenere errori dalle componenti di debug.

Pss: Non avevo notato che iltizio avesse già esposto praticamente tutto riguardo warning , backdoor , testing , debug <.<

Inviato dal mio LG-D855 utilizzando Tapatalk

 

[Rhaenys]

Farlo esplodere intendo che la gente provino tutte le variabili in modo che il server crashi, cosi posso capire cosa l'ha causata. Ma per il backdoor come faccio a capire ? o Blocco ip.

 

[Ikarus_]

Farlo esplodere intendo che la gente provino tutte le variabili in modo che il server crashi, cosi posso capire cosa l'ha causata. Ma per il backdoor come faccio a capire ? o Blocco ip.

"Ps : non bisogna necessariamente che il channel crashi per ottenere errori dalle componenti di debug. "

mi auto cito perché hai ripetuto di voler far crashare il channel.


Per la backdoor , dovresti cercarla nel codice sorgente del binario "db".
Trovi online i particolari.

Inviato dal mio LG-D855 utilizzando Tapatalk

 

[Rhaenys]

Ti ringrazio molto. Si può chiudere. Per ora ho già abbastanza informazioni da approfondire.

 

[Ikarus_]

Ehm dovresti chiudere tu

Inviato dal mio LG-D855 utilizzando Tapatalk

 

[martysama0134]

1) Quanto sono importanti fixare gli warning che si presentano quando si compila la sorgente?
2) Quali sono cose da controllare prima di aprire un server al pubblico, oltre ai bug che appaiono da Quest, System etc. C'è qualcosa anche prima da controllare?
3) Prima di comprare file + Source ( che ormai sono d'obbligo) oppure dopo aver comprato che cosa c'è da controllare ?

@iltizio ok:
1) Gli warning (eccetto quelle di terze parti) si risolvono in un nonnulla e sarebbe consigliato risolverli. (alcuni di essi portano ad unknown behavior a runtime)
2) Controllare se non si abbiano delle backdoor nella macchina, nel sito e su mysql (come degli user creati da altri staffer)
Inoltre: testare il gameplay e la sua integratezza
3) L'unica versione dei source stabile che gira è la mia; quindi se uno ti dice che ti vende dei source "fixati" (in tutto il mondo), sta tranquillo che nel 100% dei casi si tratta di vecchie mie versioni (la v3 è di 1 anno e passa fa) a cui hanno inserito system rumeni alquanto instabili.
In caso di server apri-chiudi che durano 1 settimana, non c'è molto da dire; Se vuoi tenere un server on stabile nel tempo, sai che certe cose sarebbe meglio farle come si deve.

@Rhaenys hai la possibilità di chiudere il thread

 

[Max Fridman]

Chiudo io per problema risolto