VIAF: Virtual Italian Air Force

Ho trovato un articolo, che riassumo brevemente, su questo argomento:

Sostanzialmente dice che per l'host va inserito il 75% dell'upload totale in Kbps (e questo è affermato anche nel manuale di bms).
Per esempio io ho 390Kbps (o 0,39 Mbps) di upload, quindi inserirò 292.
I client dice che sotto a 125 non possono inserire, e al massimo dovrebbero inserire 250, e qualunque valore maggiore è tendente allo spreco. I 300 che inseriamo adesso quindi dovrebbero (con un minimo di margine aggiuntivo) andare bene.
L'host può avere tanti client connessi quanto gli permette il valore che ha inserito, in pratica se io che ho inserito 292 posso avere 2 client a 125 (totale 250), con il terzo andrei gia a 375, superando il valore che ho impostato.

Tuttavia mi pare strano che con la mia connessione domestica non sia possibile ospitare più di 3 giocatori me compreso, ma probabilmente mi sbaglio!

Se qualcuno che ha più esperienza mi può dare ulteriori informazioni o correggermi se quelle che ho sono errate gli sarei grato.

Di seguito il testo originale, preso dal manuale di migrazione a Falcon BMS dei membri del 72nd VFW:
"Joining a multiplayer game as a guest – BMS’s optimal upload requirements for a
multiplayer guest is 250kbs. Setting a bandwidth higher than that is a waste of bandwidth
allocation. Overall multiplayer stability is better when all guests use the same bandwidth
setting. Note: guests can actually use a setting as low as 125, but their multiplayer experience
will be ‘laggy’ and possibly a little jerky.
Hosting a multiplayer game – if you wish to host a game, your bandwidth setting is
determined by entering (in kbs) 75% of your potential upload bandwidth. So, for instance, if
you have a 4Mbs (or 4000kbs) upload capability, you would enter ‘3000’ in the bandwidth
setting. If all of your guests join using the recommended setting of 250kbs, the number of
guests that you can handle would be
(your setting / nominal guest setting), which in this case would be (3000 / 250) = 12 guests
Further, as a host, your computer needs to be able to sustain a nominal frame rate of 30FPS
or better. Finally, for an optimal multiplayer experience, your computer should have a fairly
robust CPU.
So if you want to host a multiplayer game, you can quickly determine how many guests you
can handle by running a bandwidth speed test and dividing the result by 250.
If you want to host, but your upload bandwidth is limited, you can try to host guests at a lower
rate than 250 (but certainly no lower than 125)."

Mi viene da ridere perché è da quando sono in VIAF che si discute di tutto ciò ed è da quando sono in VIAF che abbiamo concluso che sti americani di reti informatiche non ci capiscono un cavolo.

Non so se sia cambiato qualcosa negli ultimi 18 mesi, ma
- 250 kbps sono tantissimi per quei pochi dati che fa transitare Falcon
- 4 Mbps in upload sono un sogno in Italia, ma abbiamo volato tranquillamente in 16 (a patto di avere host e client stabili ed una mix intelligente), alla faccia di tutti i discorsi di sti americani saccenti

In altre parole: ecco tornato il rompiballe MaxTow

Ehhh... magari fosse così semplice!

maxtow ha scritto:sti americani di reti informatiche non ci capiscono un cavolo.

Beh, gli americani di per sè non è che centrino molto, sono in minoranza sia fra gli sviluppatori di BMS che fra i beta-tester che hanno testato la parte MP, la maggioranza infatti è europea.

maxtow ha scritto:Non so se sia cambiato qualcosa negli ultimi 18 mesi, ma
- 250 kbps sono tantissimi per quei pochi dati che fa transitare Falcon
- 4 Mbps in upload sono un sogno in Italia, ma abbiamo volato tranquillamente in 16 (a patto di avere host e client stabili ed una mix intelligente)

Mi addentro nel problema e ti propongo alcune informazioni che possono chiarire meglio il concetto di connection bandwidth:
BMS implementa il più moderno motore MP open-source esistente, ovvero RakNet, ed esso non è assolutamente compatibile o paragonabile a AF, Openfalcon e tantomeno Falcon 4.0.
Il tutto viene da modifiche al codice che i dev hanno introdotto in BMS (per le migliorate capacità dei pc moderni, all'epoca di Falcon 4.0 erano impensabili), fra le tante l'essenziale ingrandimento della player-bubble (è possibile trovare maggiori informazioni sulla player-bubble nei manuali delle super-pak compresi in BMS).
Sostanzialmente la CB non è un'opzione vincolata unicamente alla mole di dati trasmessi di per sè (anche se senz'altro è un aspetto molto importante), ma da questo valore RakNet estrapola anche tutti quelli legati alle latenze e alla gestione degli intervalli di comunicazione fra host e client, e la metodologia di popolamento del mondo 3d nelle fasi iniziali (molto importante!) e durante la mix stessa.
Questo valore di CB è un numero che normalmente viene auto-calcolato dal software, e normalmente imposto e gestito nel lato server, in BMS ciò non è stato ancora possibile implementarlo per limiti di tempo e risorse, tuttavia è in programma e prima o poi verrà probabilmente eliminata l'opzione Connection Bandwidth (perlomeno a lato client), tuttavia al momento l'utente finale ne ha la responsabilità e fa un lavoro potenzialmente migliore del software di auto-configurazione al momento disponibile.

Concludendo: no, l'impostazione Connection Bandwidth non è unicamente legata alla larghezza di banda, e inoltre no, BMS non ha un uso della banda analogo o paragonabile a AF o al vecchio Falcon 4.0.

Come esperienza personale posso dire che con il mio upload di circa 40 KB/sec imposto secondo lo schema 300 in CB, e chiedo ai client di connettersi con 125.
Ebbene, già con 3 client dovrei aver saturato completamente la mia banda in upload e pertanto dovrei avere problemi, ma tutto ciò non succede, ho hostato per 4 client senza problemi (solo alcuni leggeri e saltuari lag che non davano particolare noia).
Il punto è che le missioni avevano un numero di entità irrisorio, non ho mai provato a hostare una campagna e volare sopra la flot con un bel po' di movimento e 4 client connessi, non credo andrebbe tutto liscio.

Pertanto si, i valori esposti dai membri del 72nd VFW (fra l'altro sono fra i beta-tester ufficiali della parte MP di BMS) sono in linea di massima corretti e frutto di moltissime prove e sperimentazioni, e non sono valori teorici, ma valori provati "sul campo" e garantiti.
Il punto che crea discordia è che sono stati redatti per permettere un MP fluido con OGNI tipo di situazione (comprese campagne con una moltitudine di unità attive contemporaneamente), e non sono invece da intendersi come valori MINIMI.

Le conclusioni che ho esposto non sono ovviamente tutta farina del mio sacco, ho letto molto nel forum BMS e ho avuto la fortuna di riuscire a contattare alcuni dei betatester, che mi hanno gentilmente chiarito le idee non poco.
Certamente non è certo sbagliato se anche noi facessimo delle prove e esperimenti all'interno di VIAF per scoprire eventualmente qualcosina in più e ottenere dei valori più "corretti" per il nostro particolare uso del sim, e sicuramente sarebbero dati utili e interessanti anche per i dev di BMS, oltre che per noi stessi.
Però tutto ciò richiede impegno e tempo, in sostanza i soliti

---

Sezione
Vorrei cogliere anche l'occasione per aggiungere qualcosa che proprio uno dei beta-tester (Scoob) mi ha spiegato riguardo all'accelerazione del tempo in MP, giacchè avevo (come tanti) dei dubbi, e in BMS la consideravo sicura, tuttavia mi è stato spiegato che:

1 - non è MAI una buona idea avere il tempo a x64 durante una sessione MP, e non andrebbe MAI fatto.

2 - è una buonissima idea entrare nella missione UNO ALLA VOLTA.

3 - se tutti premono fly (host compreso) e manca ancora del tempo all'orario di inizio della mix il tempo viene automaticamente portato a x64 da Falcon, e questo è PERICOLOSO e SBAGLIATO!

4 - la massima accelerazione temporale considerata "sicura" dai tester in MP è x16, ed è anche la massima accelerazione temporale certificata sicura dai dev di BMS.

Quindi anche il x32 che usiamo normalmente sul server probabilmente non è una buona idea, è più sicuro limitarlo perlomeno a x16 (principalmente per evitare quegli aerei che esplodono e quelli in mezzo ai campi all'inizio delle mix, eventi rari ma fastidiosi).

Interessante lettura molto ben esposta.