Dubious Connection e il server VIAF che resta in mappa
Inviato: 18/03/2013, 15:54Come la maggior parte di voi sa già dall'ultima versione di Battle For Sinai è stato implementata lato server un'opzione che rifiuta le connessioni cosiddette "dubbie".
In sostanza rifiuta la connessione ai client che non sono configurati correttamente (non hanno aperto correttamente le porte sui loro router) o hanno un router che svolge il NAT in modo scorretto (anche solo parzialmente) o che non riesce a gestire il modo creativo in cui si comporta l'implementazione di rete del codice di BMS.
Questo ha comportato l'esclusione di chi non ha configurato in modo idoneo le sue porte o ha un router non compatibile con BMS, che normalmente causano problemi al funzionamento in MP di BMS e crashando server e quant'altro.
All'inizio non ero convinto delle spiegazioni degli admin e dei sviluppatori di BMS ed ero molto in dubbio sulle effettive cause della mancata connessione, e istintivamente mettevo in dubbio che la causa del problema fosse l'implementazione NAT dei router come da loro dichiarato, ma i fatti mi hanno smentito, e il problema è effettivamente causato da come si comportano i router, specialmente quelli poco costosi, eccessivamente semplici o bloccati (tutte caratteristiche dei router forniti di default dalle compagnie di telecomunicazioni).
Sono quindi andato a rompere le pa..e come al solito a chi di dovere, perchè non mi accontentavo delle spiegazioni date col contagocce e volevo saperne di più, come al solito (beh, non proprio
) sono stato accolto con cortesia ma alla fine mi è stato spiegato nei dettagli il funzionamento dell'intera faccenda e di come funziona RAKNET e un server in BMS, purtroppo ci voleva Prophecy perchè in alcuni punti devo dire che mi hanno un po' perso, specialmente nei dettagli di come viene composto, instradato, ricevuto e letto un pacchetto preparato da RAKNET (il codice di rete di Falcon BMS).
In sostanza senza scendere nell'eccessivamente tecnico riguardo alla tecnologia di rete (come dicevo a me per primo non è tutto completamente chiaro) il problema è che i router non riescono a eseguire correttamente il NAT dei pacchetti inviati da RAKNET in quanto BMS tende a "forzare" le regole del protocollo, e alcuni router o li droppano direttamente perchè li ritengono errati (e non li instradano proprio) o li "correggono", impendendone però il riconoscimento o pertanto la ricezione quando arrivano dal destinatario (il server).
RAKNET
Essa si occupa di sincronizzare la partita su tutti i pc connessi, inviando degli update (cioè degli aggiornamenti, che possono essere di posizione, di stato, di velocità, ecc.ecc.) che riguardano un oggetto (cioè un missile, un veicolo, un aereo, ecc.).
In Falcon BMS gli oggetti sono TUTTI di proprietà del server, a parte i velivoli dei giocatori (che invece sono di proprietà del pc client del giocatore che li pilota).
I server di BMS funzionano con una rete a stella (il server al centro e tutti i client connessi a lui) per quanto riguarda la trasmissione degli update, così:
dove il server invia a tutti i client connessi gli update riguardo tutti i SUOI oggetti, che come visto sono la stragrande maggioranza degli oggetti in gioco, ecco perchè esso ha bisogno di avere una connessione veloce, perchè deve comunicare contemporaneamente con TUTTI i client e inviare a quest'ultimi gli aggiornamenti di TUTTI i suoi oggetti.
Gli oggetti di proprietà dei client (i velivoli pilotati dai giocatori) vegono aggiornati anch'essi tramite degli update, che però vengono inviati a tutti gli altri client, senza passare dal server, per avere il minimo lag possibile.
In sostanza la rete risultante per quanto riguarda gli oggetti di proprietà dei client è di tipo mesh, ovvero così:
Come vedete alcuni client non sono proprio conessi al server per quanto riguarda la trasmissione degli aggiornamenti riguardanti i velivoli "umani", e si affidano unicamente a altri client.
Questo è sempre fatto per ridurre la latenza e i consumi di banda, ed è standard nei giochi online moderni.
Compreso ciò si evince che se uno dei client funziona "male" dal punto di vista di BMS ciò è un grosso problema, in quanto i client "sfortunati" connessi a lui vedranno gli oggetti del server in modo perfetto (in quanto gli aggiornamenti riguardo questi ultimi arrivano agli "sfortunati" direttamente dal server quindi unità di terra, aeroporti, IA, ecc. non avranno problemi) ma i velivoli "umani" pilotati degli altri clienti potrebbero averne parecchi perchè non arrivano tutti gli aggiornamenti di quest'ultimi ai client "sfortunati".
Pertanto quando un client si connette al server quest'ultimo controlla che esso sia in grado di connettersi anche agli altri client, come previsto dalla rete mesh di RAKNET.
Se l'esito è negativo la connessione con questo client viene marcata come "dubbia" dal server, e quest'ultimo cercherà di instradare tutto il traffico di questo client, oggetti propri e non, tramite sè stesso, ma siccome RAKNET non è stata progettata per funzionare così e il codice di BMS non riesce a far fronte completamente al compito si verificano numerosi occasionali problemi, il più evidente e classico è il fatto che alcuni giocatori non compaiano nella chat (attenzione, non tutti quelli che scompaiono sono "colpevoli", potrebbero infatti scomparire perchè fanno parte del gruppo di quegli "sfortunati" connessi a uno dei client "colpevoli").
Gli sviluppatori dichiarano che eliminando le connessioni "dubbie" l'esperienza multiplayer ne tragga non poco giovamento, infatti i problemi che abbiamo imparato a "sopportare" svanirebbero, fra i tanti:
- aerei invisibili in 3D o invisibili sul radar, ma i loro missili no
- l'aereo esplode appena si entra in cockpit
- quando si entra in cockpit l'aereo compare non sulla pista ma "nei campi"
- RWR che non comunica l'avvenuto lock di un radar
- Datalink non funzionante o parzialmente non funzionante (l'ho sperimentato innumerevoli volte e non capivo perchè diavolo succedesse, adesso so perchè!)
- lag spikes (le scritte blu e sim in pausa)
- in alcune situazioni crash del server o (raramente) crash di uno o più client
- i missili attraversano gli aerei senza scoppiare
- ecc.ecc. (la lista è lunga, ho scritto solo quelli più "famosi" qui fra di noi)
Io come altri non comprendevo appieno come funzionava RAKNET e BMS, e avevo seri dubbi sul fatto che questa opzione di rifiutare le connessioni dubbie avesse qualche utilità, e non fosse invece l'ennesima trovata fantasiosa di qualche "stregone" di BMS.
Pertanto su mia richiesta mi sono state presentate le prove che non solo fare ciò aumenta la stabilità del server (i log parlavano chiaro), ma secondo le testimonianze dei numerosi tester riduce fino quasi a eliminarli del tutto i problemi qui sopra elencati.
Ovviamente non è un'opzione magica che cura tutto, i crash ogni tanto avvengono lo stesso, e qualche stramberia capita ancora, però è decisamente prassi, e lo sarà nel futuro, abilitare questa opzione in tutti i server "seri".
PROBLEMA
L'inghippo nasce dal fatto che come scrivevo sopra non tutti i router sono compatibili con la particolare implementazione di RAKNET di BMS, e pertanto alcuni (non pochi) giocatori si vedono rifiutare la connessione e vengono esclusi.
Il punto è che quegli stessi giocatori sono quelli che avrebbero causato in primo luogo problemi ai server e incasinato l'esperienza degli altri giocatori, in alcuni casi rovinandola.
IL SERVER VIAF e le "DUBIOUS CONNECTION"
Lungi da me l'intenzione di escludere qualcuno, in un mondo perfetto se attiviamo l'opzione sul server VIAF per godere dei benefici esposti sopra tutti si potrebbero connettere senza problemi, ma sono certo non sarà così.
Propongo però una prova, magari stasera, per vedere chi non è in grado di connettersi con l'opzione attivata, da lì sapremo chi ha problemi nella configurazione del router (anche chi non ha fatto correttamente il forward delle porte viene rifiutato dal server) o ha un router incompatibile.
Gli "sfortunati" sapranno che anche in caso poi disattiviamo l'opzione per permettere anche a loro di partecipare saranno la quasi certa causa di eventuali crash, problemi, ecc.ecc. al server VIAF (posizione decisamente non invidiabile)
Per evitare agli "sfortunati" di avere le orecchie che fischiano ogniqualvolta si verifica un problema sul server la "cura" è procurarsi un router compatibile con BMS (ad es. NetGear DGN 2000 o DGN 2200, che si aggirano sugli 80€ nuovi, 40€ usati), quindi purtroppo spendere soldi.
Ho provato in tutte le maniere e collaborato con più persone possibile, ma veramente non c'è verso di far funzionare i router di cacca che fornisce telecom, i thompson invece c'è una flebile speranza, ma io consiglio se possibile un cambio di router, è più sicuro e più semplice.
LE PORTE
In particolare le porte usate da Falcon BMS e da RAKNET sono solo la 2934 (usata dall'host per inviare dati ai client in assenza di connessione "dubbia") e 2935 (usata dal client per inviare dati all'host in assenza di connessione "dubbia") unicamente tramite protocollo UDP e teoricamente sarebbe sufficente aprire solo quelle se il router funziona correttamente.
In realtà per evitare problemi è meglio aprire anche il protocollo TCP perchè alcuni router aprendo solo l'UDP filtrano il pacchetto (per "errori" o alcune "features" nella gestione nel firewall, tipo alcuni Thompson) quindi è una buona idea aprire sia TCP che UDP per evitare problemi.
Le famose 2936-2937 che sembrano non utilizzate sono, di fatto, non utilizzate.
Venivano usate dalla versione di IVC, quella basata su directplay, ora obsoleta.
Infine le porte 9987 and 9988 (sempre UDP) vengono utilizzate solo dal server IVC, non è invece necessario aprire porte per il client IVC.
Quindi riepilogando un client deve aprire:
2935-2935 UDP (anche TCP se il router e "scarso")
LA GESTIONE DEL SERVER VIAF
Questa faccenda della "connessioni dubbie" come dicevo mi ha portato a avere un dialogo diretto con alcune delle "teste d'uovo" di BMS.
Parlando con loro ho scoperto che la nostra attuale gestione del server è gravemente errata, e causa di probabili desincronizzazioni, i cui sintomi sono:
- i classici carrelli che sono giù ma si vedono su o viceversa
- appena si entra in cockpit di un aereo in volo questo si trova in stallo profondo e/o precipita
- datalink parzialmente o non funzionante (causato anche da connessioni "dubbie")
- aerei che esplodono appena entrati in cockpit (causato anche da connessioni "dubbie")
- aerei che partono nei "campi" (causato anche da connessioni "dubbie")
Il punto è che il server DEVE ESSERE SEMPRE NEL MONDO 3D, NON DEVE MAI RIMANERE IN MAPPA!!!
Quando me l'hanno spiegato mi hanno preso solo parzialmente di sorpresa, avevo già sentito questa notizia prima, ma non ero sicuro fosse effettivamente necessario e neppure come effettivamente compiere correttamente l'operazione di entrata in volo.
Quello che è CERTO è che il server dedicato 2D è bacato, e non supportato in BMS dagli sviluppatori, e crea innumerevoli problemi.
In sostanza il server deve entrare nel mondo 3D come tutti, e deve farlo per primo.
Il problema che si viene a creare è che ovviamente se il server entra nel mondo 3D avrà ovviamente un calo di prestazioni in termini di FPS e il server deve avere almeno 60 FPS per essere affidabile, pertanto è consigliabile farlo entrare in cockpit in una zona molto distante da dove si svolgerà l'azione, entrare in ramp start e lasciare il cockpit "freddo", senza attivare alcun sistema.
Inoltre vi sono alcune modifiche da mettere in pratica a livello di configurazione, che svolgerò e spiegherò nel dettaglio agli interessati, in particolare è necessario fra le altre cose aumentare il timeout dei velivoli non IA per evitare che il server venga ricacciato sulla mappa 2D a causa del fatto che rimane immobile e inattivo.
CONCLUSIONE (finalmente)
Ora si tratta di fare prove e esperimenti per arrivare a 60fps con il server, speriamo sia possibile!
Adesso però avendo tutte queste nuove informazioni abbiamo la possibilità di offrire un server serio e affidabile se come abbiamo previsto apriremo la red-flag o altre iniziative a altri gruppi, offrendo un server al pari di quello di Archer & Co. per Battle For Sinai.
Complimenti a chi ha letto tutto!![[grin-1.gif]](./images/smilies/grin-1.gif "[grin-1.gif]")
In sostanza rifiuta la connessione ai client che non sono configurati correttamente (non hanno aperto correttamente le porte sui loro router) o hanno un router che svolge il NAT in modo scorretto (anche solo parzialmente) o che non riesce a gestire il modo creativo in cui si comporta l'implementazione di rete del codice di BMS.
Questo ha comportato l'esclusione di chi non ha configurato in modo idoneo le sue porte o ha un router non compatibile con BMS, che normalmente causano problemi al funzionamento in MP di BMS e crashando server e quant'altro.
All'inizio non ero convinto delle spiegazioni degli admin e dei sviluppatori di BMS ed ero molto in dubbio sulle effettive cause della mancata connessione, e istintivamente mettevo in dubbio che la causa del problema fosse l'implementazione NAT dei router come da loro dichiarato, ma i fatti mi hanno smentito, e il problema è effettivamente causato da come si comportano i router, specialmente quelli poco costosi, eccessivamente semplici o bloccati (tutte caratteristiche dei router forniti di default dalle compagnie di telecomunicazioni).
Sono quindi andato a rompere le pa..e come al solito a chi di dovere, perchè non mi accontentavo delle spiegazioni date col contagocce e volevo saperne di più, come al solito (beh, non proprio
) sono stato accolto con cortesia ma alla fine mi è stato spiegato nei dettagli il funzionamento dell'intera faccenda e di come funziona RAKNET e un server in BMS, purtroppo ci voleva Prophecy perchè in alcuni punti devo dire che mi hanno un po' perso, specialmente nei dettagli di come viene composto, instradato, ricevuto e letto un pacchetto preparato da RAKNET (il codice di rete di Falcon BMS).In sostanza senza scendere nell'eccessivamente tecnico riguardo alla tecnologia di rete (come dicevo a me per primo non è tutto completamente chiaro) il problema è che i router non riescono a eseguire correttamente il NAT dei pacchetti inviati da RAKNET in quanto BMS tende a "forzare" le regole del protocollo, e alcuni router o li droppano direttamente perchè li ritengono errati (e non li instradano proprio) o li "correggono", impendendone però il riconoscimento o pertanto la ricezione quando arrivano dal destinatario (il server).
RAKNET
Essa si occupa di sincronizzare la partita su tutti i pc connessi, inviando degli update (cioè degli aggiornamenti, che possono essere di posizione, di stato, di velocità, ecc.ecc.) che riguardano un oggetto (cioè un missile, un veicolo, un aereo, ecc.).
In Falcon BMS gli oggetti sono TUTTI di proprietà del server, a parte i velivoli dei giocatori (che invece sono di proprietà del pc client del giocatore che li pilota).
I server di BMS funzionano con una rete a stella (il server al centro e tutti i client connessi a lui) per quanto riguarda la trasmissione degli update, così:
dove il server invia a tutti i client connessi gli update riguardo tutti i SUOI oggetti, che come visto sono la stragrande maggioranza degli oggetti in gioco, ecco perchè esso ha bisogno di avere una connessione veloce, perchè deve comunicare contemporaneamente con TUTTI i client e inviare a quest'ultimi gli aggiornamenti di TUTTI i suoi oggetti.
Gli oggetti di proprietà dei client (i velivoli pilotati dai giocatori) vegono aggiornati anch'essi tramite degli update, che però vengono inviati a tutti gli altri client, senza passare dal server, per avere il minimo lag possibile.
In sostanza la rete risultante per quanto riguarda gli oggetti di proprietà dei client è di tipo mesh, ovvero così:
Come vedete alcuni client non sono proprio conessi al server per quanto riguarda la trasmissione degli aggiornamenti riguardanti i velivoli "umani", e si affidano unicamente a altri client.
Questo è sempre fatto per ridurre la latenza e i consumi di banda, ed è standard nei giochi online moderni.
Compreso ciò si evince che se uno dei client funziona "male" dal punto di vista di BMS ciò è un grosso problema, in quanto i client "sfortunati" connessi a lui vedranno gli oggetti del server in modo perfetto (in quanto gli aggiornamenti riguardo questi ultimi arrivano agli "sfortunati" direttamente dal server quindi unità di terra, aeroporti, IA, ecc. non avranno problemi) ma i velivoli "umani" pilotati degli altri clienti potrebbero averne parecchi perchè non arrivano tutti gli aggiornamenti di quest'ultimi ai client "sfortunati".
Pertanto quando un client si connette al server quest'ultimo controlla che esso sia in grado di connettersi anche agli altri client, come previsto dalla rete mesh di RAKNET.
Se l'esito è negativo la connessione con questo client viene marcata come "dubbia" dal server, e quest'ultimo cercherà di instradare tutto il traffico di questo client, oggetti propri e non, tramite sè stesso, ma siccome RAKNET non è stata progettata per funzionare così e il codice di BMS non riesce a far fronte completamente al compito si verificano numerosi occasionali problemi, il più evidente e classico è il fatto che alcuni giocatori non compaiano nella chat (attenzione, non tutti quelli che scompaiono sono "colpevoli", potrebbero infatti scomparire perchè fanno parte del gruppo di quegli "sfortunati" connessi a uno dei client "colpevoli").
Gli sviluppatori dichiarano che eliminando le connessioni "dubbie" l'esperienza multiplayer ne tragga non poco giovamento, infatti i problemi che abbiamo imparato a "sopportare" svanirebbero, fra i tanti:
- aerei invisibili in 3D o invisibili sul radar, ma i loro missili no
- l'aereo esplode appena si entra in cockpit
- quando si entra in cockpit l'aereo compare non sulla pista ma "nei campi"
- RWR che non comunica l'avvenuto lock di un radar
- Datalink non funzionante o parzialmente non funzionante (l'ho sperimentato innumerevoli volte e non capivo perchè diavolo succedesse, adesso so perchè!)
- lag spikes (le scritte blu e sim in pausa)
- in alcune situazioni crash del server o (raramente) crash di uno o più client
- i missili attraversano gli aerei senza scoppiare
- ecc.ecc. (la lista è lunga, ho scritto solo quelli più "famosi" qui fra di noi)
Io come altri non comprendevo appieno come funzionava RAKNET e BMS, e avevo seri dubbi sul fatto che questa opzione di rifiutare le connessioni dubbie avesse qualche utilità, e non fosse invece l'ennesima trovata fantasiosa di qualche "stregone" di BMS.
Pertanto su mia richiesta mi sono state presentate le prove che non solo fare ciò aumenta la stabilità del server (i log parlavano chiaro), ma secondo le testimonianze dei numerosi tester riduce fino quasi a eliminarli del tutto i problemi qui sopra elencati.
Ovviamente non è un'opzione magica che cura tutto, i crash ogni tanto avvengono lo stesso, e qualche stramberia capita ancora, però è decisamente prassi, e lo sarà nel futuro, abilitare questa opzione in tutti i server "seri".
PROBLEMA
L'inghippo nasce dal fatto che come scrivevo sopra non tutti i router sono compatibili con la particolare implementazione di RAKNET di BMS, e pertanto alcuni (non pochi) giocatori si vedono rifiutare la connessione e vengono esclusi.
Il punto è che quegli stessi giocatori sono quelli che avrebbero causato in primo luogo problemi ai server e incasinato l'esperienza degli altri giocatori, in alcuni casi rovinandola.
IL SERVER VIAF e le "DUBIOUS CONNECTION"
Lungi da me l'intenzione di escludere qualcuno, in un mondo perfetto se attiviamo l'opzione sul server VIAF per godere dei benefici esposti sopra tutti si potrebbero connettere senza problemi, ma sono certo non sarà così.
Propongo però una prova, magari stasera, per vedere chi non è in grado di connettersi con l'opzione attivata, da lì sapremo chi ha problemi nella configurazione del router (anche chi non ha fatto correttamente il forward delle porte viene rifiutato dal server) o ha un router incompatibile.
Gli "sfortunati" sapranno che anche in caso poi disattiviamo l'opzione per permettere anche a loro di partecipare saranno la quasi certa causa di eventuali crash, problemi, ecc.ecc. al server VIAF (posizione decisamente non invidiabile)
Per evitare agli "sfortunati" di avere le orecchie che fischiano ogniqualvolta si verifica un problema sul server la "cura" è procurarsi un router compatibile con BMS (ad es. NetGear DGN 2000 o DGN 2200, che si aggirano sugli 80€ nuovi, 40€ usati), quindi purtroppo spendere soldi.
Ho provato in tutte le maniere e collaborato con più persone possibile, ma veramente non c'è verso di far funzionare i router di cacca che fornisce telecom, i thompson invece c'è una flebile speranza, ma io consiglio se possibile un cambio di router, è più sicuro e più semplice.
LE PORTE
In particolare le porte usate da Falcon BMS e da RAKNET sono solo la 2934 (usata dall'host per inviare dati ai client in assenza di connessione "dubbia") e 2935 (usata dal client per inviare dati all'host in assenza di connessione "dubbia") unicamente tramite protocollo UDP e teoricamente sarebbe sufficente aprire solo quelle se il router funziona correttamente.
In realtà per evitare problemi è meglio aprire anche il protocollo TCP perchè alcuni router aprendo solo l'UDP filtrano il pacchetto (per "errori" o alcune "features" nella gestione nel firewall, tipo alcuni Thompson) quindi è una buona idea aprire sia TCP che UDP per evitare problemi.
Le famose 2936-2937 che sembrano non utilizzate sono, di fatto, non utilizzate.
Venivano usate dalla versione di IVC, quella basata su directplay, ora obsoleta.
Infine le porte 9987 and 9988 (sempre UDP) vengono utilizzate solo dal server IVC, non è invece necessario aprire porte per il client IVC.
Quindi riepilogando un client deve aprire:
2935-2935 UDP (anche TCP se il router e "scarso")
LA GESTIONE DEL SERVER VIAF
Questa faccenda della "connessioni dubbie" come dicevo mi ha portato a avere un dialogo diretto con alcune delle "teste d'uovo" di BMS.
Parlando con loro ho scoperto che la nostra attuale gestione del server è gravemente errata, e causa di probabili desincronizzazioni, i cui sintomi sono:
- i classici carrelli che sono giù ma si vedono su o viceversa
- appena si entra in cockpit di un aereo in volo questo si trova in stallo profondo e/o precipita
- datalink parzialmente o non funzionante (causato anche da connessioni "dubbie")
- aerei che esplodono appena entrati in cockpit (causato anche da connessioni "dubbie")
- aerei che partono nei "campi" (causato anche da connessioni "dubbie")
Il punto è che il server DEVE ESSERE SEMPRE NEL MONDO 3D, NON DEVE MAI RIMANERE IN MAPPA!!!
Quando me l'hanno spiegato mi hanno preso solo parzialmente di sorpresa, avevo già sentito questa notizia prima, ma non ero sicuro fosse effettivamente necessario e neppure come effettivamente compiere correttamente l'operazione di entrata in volo.
Quello che è CERTO è che il server dedicato 2D è bacato, e non supportato in BMS dagli sviluppatori, e crea innumerevoli problemi.
In sostanza il server deve entrare nel mondo 3D come tutti, e deve farlo per primo.
Il problema che si viene a creare è che ovviamente se il server entra nel mondo 3D avrà ovviamente un calo di prestazioni in termini di FPS e il server deve avere almeno 60 FPS per essere affidabile, pertanto è consigliabile farlo entrare in cockpit in una zona molto distante da dove si svolgerà l'azione, entrare in ramp start e lasciare il cockpit "freddo", senza attivare alcun sistema.
Inoltre vi sono alcune modifiche da mettere in pratica a livello di configurazione, che svolgerò e spiegherò nel dettaglio agli interessati, in particolare è necessario fra le altre cose aumentare il timeout dei velivoli non IA per evitare che il server venga ricacciato sulla mappa 2D a causa del fatto che rimane immobile e inattivo.
CONCLUSIONE (finalmente)
Ora si tratta di fare prove e esperimenti per arrivare a 60fps con il server, speriamo sia possibile!
Adesso però avendo tutte queste nuove informazioni abbiamo la possibilità di offrire un server serio e affidabile se come abbiamo previsto apriremo la red-flag o altre iniziative a altri gruppi, offrendo un server al pari di quello di Archer & Co. per Battle For Sinai.
Complimenti a chi ha letto tutto!
). Tuttavia, riuscendo ad accedere senza problemi a Battle For Sinai, non dovrei avere problemi con il "disallow dubious connection" su VIAF.![[i-razz]](./images/smilies/icon-razz.gif "meglio che non dico nulla!"){kind=icon}
.... ![[kaboom.gif]](./images/smilies/kaboom.gif "[kaboom.gif]")