Publié : mer. févr. 07, 2007 3:59 pm
[quote="Ghostrider"]De l avis meme de membres du beta le flux MP du 4.3 est telement lourd (car riche) que pour voler des missions chargé]
Salut ghost, c'est exactement ca mais voici de petites precisions concernant le code MP de OF :
il a donc ete optimisé pour des transfert "server => clients" (environnement global, position des objects et unités, reception des data lors de la rentrée dans la TE ou la campagne, management des AGG et DEAGG d'objects etc) et "clients => clients" (echange des dirty data, info de position)
Il est donc tout à fait vrai que ce code est gourmant, surtout en terme de transfert "clients => clients" avec 90% de priorité pour les info de position, cela reviens à dire que plus le client aura parametrer un -bw grand, plus le vol en formation sera non seulement fluide, mais il n'y aura pas de perte au niveau des dirty data (car la priorité est donné aux info de position)
Personnelement je vous recommande un minimum de -bw 256 (en kb/s bien sur) pour les clients, bien sur, le host doit etre celui qui a la plus grosse
Nous avons aussi remarqué que si les host a un -bw inferieur a 600-900 kb/s, nous deconseillons que les clients aient de -bw differents entre eux, par contre avec nos server 100/100 Mb/s, nous mettons chacuns notre upload max - 10% (en respectant ce minimum de -bw 256 bien sur, mais l'ideal est d'avoir -bw 512). Les clients n'ayant pas une tel capacité d'upload seront pénalisés, se traduisant d'abord par la perte des coms integrées, ensuite par la perte de certains dirty data et eventuelllement de mauvais rafraichissement de position si sa connexion en upload est faible (inferieur a 128 kb/s)
Concernant les transferts "server => clients", une grosse bande passante va permetre deux choses :
-pouvoir avoir un environnement tres chargé TE ou campagne
-pouvoir ne respecter auncune regle lors de la rentrée dans la mission
je m'explique : si le host a un -bw inferieur a 1 Mb/s, nous recommandons de rentré un par un dans la partie en ligne (TE et a fortiori pour la campagne), pour laisser toutes la bande passante du host au client en cour de connexion. Avec nos server 100/100 Mb/s, nous pouvons eviter cette regle, tout le monde peut rentrer en meme temps
Il y a encore enormement à dire sur ce code, ce que je ne veus pas faire et encore moins rentrer dans des explications vraiment "techniques", mais le debuggage du coeur meme de OF (surtout au niveau de la gestion de l'environnement "bulle" host-client et client-client) entraine notament cette fameuse "gourmandise" en bande passante au niveau des clients, mais quel bonheur de pouvoir avoir un environnement (notament electronique) coherent en MP, chose absolument indispensable pour un tel simulateur
Cheers,
BB
Salut ghost, c'est exactement ca mais voici de petites precisions concernant le code MP de OF :
il a donc ete optimisé pour des transfert "server => clients" (environnement global, position des objects et unités, reception des data lors de la rentrée dans la TE ou la campagne, management des AGG et DEAGG d'objects etc) et "clients => clients" (echange des dirty data, info de position)
Il est donc tout à fait vrai que ce code est gourmant, surtout en terme de transfert "clients => clients" avec 90% de priorité pour les info de position, cela reviens à dire que plus le client aura parametrer un -bw grand, plus le vol en formation sera non seulement fluide, mais il n'y aura pas de perte au niveau des dirty data (car la priorité est donné aux info de position)
Personnelement je vous recommande un minimum de -bw 256 (en kb/s bien sur) pour les clients, bien sur, le host doit etre celui qui a la plus grosse
Nous avons aussi remarqué que si les host a un -bw inferieur a 600-900 kb/s, nous deconseillons que les clients aient de -bw differents entre eux, par contre avec nos server 100/100 Mb/s, nous mettons chacuns notre upload max - 10% (en respectant ce minimum de -bw 256 bien sur, mais l'ideal est d'avoir -bw 512). Les clients n'ayant pas une tel capacité d'upload seront pénalisés, se traduisant d'abord par la perte des coms integrées, ensuite par la perte de certains dirty data et eventuelllement de mauvais rafraichissement de position si sa connexion en upload est faible (inferieur a 128 kb/s)
Concernant les transferts "server => clients", une grosse bande passante va permetre deux choses :
-pouvoir avoir un environnement tres chargé TE ou campagne
-pouvoir ne respecter auncune regle lors de la rentrée dans la mission
je m'explique : si le host a un -bw inferieur a 1 Mb/s, nous recommandons de rentré un par un dans la partie en ligne (TE et a fortiori pour la campagne), pour laisser toutes la bande passante du host au client en cour de connexion. Avec nos server 100/100 Mb/s, nous pouvons eviter cette regle, tout le monde peut rentrer en meme temps
Il y a encore enormement à dire sur ce code, ce que je ne veus pas faire et encore moins rentrer dans des explications vraiment "techniques", mais le debuggage du coeur meme de OF (surtout au niveau de la gestion de l'environnement "bulle" host-client et client-client) entraine notament cette fameuse "gourmandise" en bande passante au niveau des clients, mais quel bonheur de pouvoir avoir un environnement (notament electronique) coherent en MP, chose absolument indispensable pour un tel simulateur
Cheers,
BB
et bravo pour ton boulot sur le MP