Réflexion sur le code réseau
-
Topic author
#1
Quelle solution pourrait arranger le code réseau?
Le principe du code réseau et de rafraichir chez chaque joueur les comportements et la position de chaque objet. Chez chaque joueur, une interpolation est faite en attendant les infos suivantes.
2 architectures posible : la chaîne de connexion rebouclée (ancien code de F4) et le modèle Client Serveur.
La chaîne de connexion a un avantage : tout le monde se partage le boulot de serveur/client. mais si un élément foire, la chaîne est rompue c'est tout le monde qui en pati (smith).
D'autre part, le temps que le premier joueur voit ses données atteindre le dernier joueur, il paut se passer du temps. Plus que dans un modèle Client/Serveur.
Avantage : adapté aux BP rachitiques. Inconvénients : sécurité et lag.
Le modèle Client/Serveur part du principe qu'un joueur hoste la partie : c'est lui qui recevra de chaque client les infos et les redispatchera à chaque autre client.
Avantages : fiabilité : si un client foire, les autres peuvent continuer à jouer. Possibilité d'utiliser un serveur dédié.
Inconvénient : grosse bande passante qui doit augmenter en upload en fonction du nombre de clients.
En fait, F4 actuellement fait un mix un peu particulier : pour toutes les phase sauf les le ravito, le serveur rafraichit l'environnement 3D. Pour le ravito, c'est le client qui ravitaille qui rafraichit les infos concernant le ravitailleur, pour éviter tout problème. Le Serveur les récupère et dispatche aux autres clients. peut-être existe-t-il d'autres phases où c'est le cas (attaque de blindés mobiles, pourquoi pas).
Comment gagner de la bande passante? En ne diffusant sur le réseau que le strict minimum. Sachant que les paramètres de chaque objet sont définis dans le code sous la forme de variables constituées de plus ou moins de bits. Au vu de ce qui a été dit, je ne pense pas qu'il ya ait grand chose de faisable à ce niveau. C'est la phase d'optimisation. Par exemple, inutile d'utiliser 2565478 bits de données pour savoir si untel est radar off ou on. Un seul suffit.
On peut penser aussi à ne rafraichir que les objets situés à moins de 30 miles par exemple. La bulle s'en occupe.
Pourquoi tout rafraîchir en même temps? Certaines données ont une priorité plus importante que d'autres. L'une sera rafraichie à chaque paquet, l'autre ne le sera que tous les 30 paquets. Mais ça je crois que c'est déjà optimisé.
Alors, quand vous voulez que le ravito soit suer en réseau, que vous voulez moins de lag, plus de ramp start à 54, etc... Ets-ce que finalement, la réponse n'est pas "achète toi une grosse bande passante et c'est tout"?
A moins qu'il y ait la possibilité de tweaker des options, permettant par exemple de choisir le taux de rafraîchissement de chaque donnée, via un utilitaire ou mieux l'UI.
D'autres idées?
Le principe du code réseau et de rafraichir chez chaque joueur les comportements et la position de chaque objet. Chez chaque joueur, une interpolation est faite en attendant les infos suivantes.
2 architectures posible : la chaîne de connexion rebouclée (ancien code de F4) et le modèle Client Serveur.
La chaîne de connexion a un avantage : tout le monde se partage le boulot de serveur/client. mais si un élément foire, la chaîne est rompue c'est tout le monde qui en pati (smith).
D'autre part, le temps que le premier joueur voit ses données atteindre le dernier joueur, il paut se passer du temps. Plus que dans un modèle Client/Serveur.
Avantage : adapté aux BP rachitiques. Inconvénients : sécurité et lag.
Le modèle Client/Serveur part du principe qu'un joueur hoste la partie : c'est lui qui recevra de chaque client les infos et les redispatchera à chaque autre client.
Avantages : fiabilité : si un client foire, les autres peuvent continuer à jouer. Possibilité d'utiliser un serveur dédié.
Inconvénient : grosse bande passante qui doit augmenter en upload en fonction du nombre de clients.
En fait, F4 actuellement fait un mix un peu particulier : pour toutes les phase sauf les le ravito, le serveur rafraichit l'environnement 3D. Pour le ravito, c'est le client qui ravitaille qui rafraichit les infos concernant le ravitailleur, pour éviter tout problème. Le Serveur les récupère et dispatche aux autres clients. peut-être existe-t-il d'autres phases où c'est le cas (attaque de blindés mobiles, pourquoi pas).
Comment gagner de la bande passante? En ne diffusant sur le réseau que le strict minimum. Sachant que les paramètres de chaque objet sont définis dans le code sous la forme de variables constituées de plus ou moins de bits. Au vu de ce qui a été dit, je ne pense pas qu'il ya ait grand chose de faisable à ce niveau. C'est la phase d'optimisation. Par exemple, inutile d'utiliser 2565478 bits de données pour savoir si untel est radar off ou on. Un seul suffit.
On peut penser aussi à ne rafraichir que les objets situés à moins de 30 miles par exemple. La bulle s'en occupe.
Pourquoi tout rafraîchir en même temps? Certaines données ont une priorité plus importante que d'autres. L'une sera rafraichie à chaque paquet, l'autre ne le sera que tous les 30 paquets. Mais ça je crois que c'est déjà optimisé.
Alors, quand vous voulez que le ravito soit suer en réseau, que vous voulez moins de lag, plus de ramp start à 54, etc... Ets-ce que finalement, la réponse n'est pas "achète toi une grosse bande passante et c'est tout"?
A moins qu'il y ait la possibilité de tweaker des options, permettant par exemple de choisir le taux de rafraîchissement de chaque donnée, via un utilitaire ou mieux l'UI.
D'autres idées?
-
Topic author
#2
Au moins, je suis pas embistrouillé par la contradiction
Moralité, le premier qui gueule à propos du code réseau se verra arracher un poil du luc toute les demi-heure, avec interdiction de remonter son falzard! :modor:
![Rolleyes :rolleyes:](./images/smilies/rolleyes.gif)
Moralité, le premier qui gueule à propos du code réseau se verra arracher un poil du luc toute les demi-heure, avec interdiction de remonter son falzard! :modor:
-
- Pilote Confirmé
- Messages : 2811
- Inscription : 06 mars 2003
#3
bah ... non :(
![Rolleyes :rolleyes:](./images/smilies/rolleyes.gif)
Là je deviends curieux : comment le sais-tu ?Originally posted by Nanard
... Mais ça je crois que c'est déjà optimisé ...
![Rolleyes :rolleyes:](./images/smilies/rolleyes.gif)
-
- Chef de patrouille
- Messages : 5737
- Inscription : 20 janvier 2002
#5
C'était trop beau ...5mn de reflexion, et le canard se lache;
fait gache , si on te chope , ce sont tes plumes du c.. qui vont y passer !!!
et tu vois comment ça peu être laid, un canard sans plumes au fion !!!
fait gache , si on te chope , ce sont tes plumes du c.. qui vont y passer !!!
et tu vois comment ça peu être laid, un canard sans plumes au fion !!!
VR et PIMAX Crystal
#6
Mouais, dans ce cas c'est pas gagné si on regarde la qualité globale du réseau qui nous est offert en france.
A moins que l'on trouve de squatter les installations de grandes entreprises ou d'université le temps de nos parties.
Perso, j'ai appris que grâce à "l'exceptionnelle" qualité de mon installation je suis bridé à 512. :(( (quoique certains diront que c toujours mieux que 56k
)
Mais dis-moi Nanard, qu'en est-il dans le cadre d'un LAN ??![Music Whistling :hum:](./images/smilies/music_whistling.gif)
![Huh :huh:](./images/smilies/huh.gif)
![Beta :beta:](./images/smilies/beta.gif)
Perso, j'ai appris que grâce à "l'exceptionnelle" qualité de mon installation je suis bridé à 512. :(( (quoique certains diront que c toujours mieux que 56k
![Rolleyes :rolleyes:](./images/smilies/rolleyes.gif)
Mais dis-moi Nanard, qu'en est-il dans le cadre d'un LAN ??
![Music Whistling :hum:](./images/smilies/music_whistling.gif)
-
Topic author
#7
Seul le Lan peut vraiment nous renseigner sur la qualité intrinsèque du code.
Donc il faut un beta test poussé et écrit d'avance pour vérifier chaque étape.
Des volontaires?
Ca permettrait de faire des propositions plus concrètes à ceux sui ont pris les rennes de F4...
Donc il faut un beta test poussé et écrit d'avance pour vérifier chaque étape.
Des volontaires?
Ca permettrait de faire des propositions plus concrètes à ceux sui ont pris les rennes de F4...
#8
bonne idée ...euh je retire ce que j'ai écris sur tes plumes du f...
si tu nous fais cela !!! LoL
non sérieux , le code MP, avec un ramp posible à plus que 4, j'en rève !
en plus maintenant avec les verrières et les train-light fonctionnels en réseau ... , j'en rève deux fois plus de faire des vrais ramp-départs mission en wing ...
si tu nous fais cela !!! LoL
non sérieux , le code MP, avec un ramp posible à plus que 4, j'en rève !
en plus maintenant avec les verrières et les train-light fonctionnels en réseau ... , j'en rève deux fois plus de faire des vrais ramp-départs mission en wing ...
VR et PIMAX Crystal
#9
A l'époque où on nous avait demandé nos désidératas pour Falcon 5 j'avais émis quelques idées dont certaines pour le réseau.
L'idée pour le réseau c'était d'avoir une architecture "réseau serveur"/clients.
Je ne vais pas rentrer dans le détail sur l'idée. Pour le réseau serveur celui-ci pouvait être aussi bien localisé, que réalisé à partir de diverses machines du net.
En fait le but et intérêt c'était de lancer l'idée d'un service continue de serveur de partie, pris en charge par l'éditeur du jeu.
Cela reviens en fait à ce que l'on a aujourd'hui avec les MMORPG.
On paye au mois, mais on bénéficie d'un service top qualité pour des parties exceptionnelles, et surtout la possibilités de voler dans un environnement où il est possible d'avoir un maximum d'appareils pilotés par des humains.
Il ne faut pas se leurrer, la simu en réseau est devenu exceptionnelement saisissante parce qu'on a pu multiplier la quantité des données transmises. Et plus ca va plus il y en a des données à transmettre, en dépit de toutes les optimisations que l'on peut faire.
Donc il faut absolument, d'une manière ou d'une autre, avoir des serveurs à très forte bande passante.
Espérer cela du quidam moyen me semble de plus en plus difficile.
C'est pour cela que je crois dans l'avenir de ce genre de service, de qualité mais payant.
A quand le MMORPG où l'on peut prendre la place d'un pilote de chasse?
L'idée pour le réseau c'était d'avoir une architecture "réseau serveur"/clients.
Je ne vais pas rentrer dans le détail sur l'idée. Pour le réseau serveur celui-ci pouvait être aussi bien localisé, que réalisé à partir de diverses machines du net.
En fait le but et intérêt c'était de lancer l'idée d'un service continue de serveur de partie, pris en charge par l'éditeur du jeu.
Cela reviens en fait à ce que l'on a aujourd'hui avec les MMORPG.
On paye au mois, mais on bénéficie d'un service top qualité pour des parties exceptionnelles, et surtout la possibilités de voler dans un environnement où il est possible d'avoir un maximum d'appareils pilotés par des humains.
Il ne faut pas se leurrer, la simu en réseau est devenu exceptionnelement saisissante parce qu'on a pu multiplier la quantité des données transmises. Et plus ca va plus il y en a des données à transmettre, en dépit de toutes les optimisations que l'on peut faire.
Donc il faut absolument, d'une manière ou d'une autre, avoir des serveurs à très forte bande passante.
Espérer cela du quidam moyen me semble de plus en plus difficile.
C'est pour cela que je crois dans l'avenir de ce genre de service, de qualité mais payant.
A quand le MMORPG où l'on peut prendre la place d'un pilote de chasse?
-
- Nouvelle Recrue
- Messages : 114
- Inscription : 07 septembre 2002