Check-Six Forums

incroyable ..ce matin.

due à la tempête qui passe pas loins en ce moment, j'ai eu des coupures electrique en vol OnLine alors que je hostais...


la meilleure..c'est que les 3 ailiers ont continué à ce voir et à être On line ensemble.
Confirmation de connection, et d'évolution ensemble ! ! !

Le tout alors que j'avais coupé et fermé mon ordi Falcon depuis longtemps...
ils ont continué à faire de la formation et du smoke on ensemble .



le tout suivi sur l'autre ordi qui sert au TSC6 (et qui était sur onduleur....)

salut

Bah comme depuis tres tres tres longtemps sur Falcon !!

A+

ben qui...qui host dans ce cas alors....

et le hosteur..il peut essayer de re-entrer !!! mais avec quels paramêtres ???

AHAH qui devient hosteur ca ??? difficile a dire !! a mon avis impossible a savoir a l'avance !!

Et oui tu peut revenir en plus avec AF c'est devenu chose courante.

Quand tu as coupe il y a certainement du avoir un lag le temps que la partie soit redonne a un des joueurs (enfin comme cela avec les anciennes versions) et ensuite c'est reparti !!

A+

c'est dingue comme les contrainte techniques peuvent permettre aux developpeurs d'innover !

a l'epoque , aucun particulier n'avait l'adsl. sans doutes pour ca que le model reseau du jeu n'est pas conventionnel. et pourtant , c'est super fiable

Bah, rien à voir avec le non conventionel , c'est un mélange déchanges host/clients et per to per .

Si tu perds le host, il te reste le p2p , mais tu perds les infos gérés par le Host !c'est extrèmement conventionel au contraire

toopack66 a écrit :Bah, rien à voir avec le non conventionel , c'est un mélange déchanges host/clients et per to per .

Si tu perds le host, il te reste le p2p , mais tu perds les infos gérés par le Host !c'est extrèmement conventionel au contraire

Pas mieux.... .

@+Markus

toopack66 a écrit :Bah, rien à voir avec le non conventionel , c'est un mélange déchanges host/clients et per to per .

Si tu perds le host, il te reste le p2p , mais tu perds les infos gérés par le Host !c'est extrèmement conventionel au contraire

le model standard (pour le jeu reseau , on s'entends bien ... ), c est un host , qui joue le role du noeud reseau.
si tu perds le host , tu perds tout .

donc , le model reseau de falcon4 n'est pas "conventionnel"

pas conentionel !! ok...

mais rest-il fiable en perdant le hosteur de la partie ??

c'est là...la question...;car hier...le trainning s'est complètement continué !!! mais sans moi !!!
qui suis quand même resté avec eux en phonie grace à mon TS-C6 sur l'autre ordi

Bah si le training as continue c'est que c'est fiable non ?

Ou alors y a des grosses erreurs et les autres non rien vu ? ca c'est a vous de voir !!

A+

[quote="Jallie"]pas conentionel !! ok...

mais rest-il fiable en perdant le hosteur de la partie ??

c'est là...la question...]


Les ordis restant connecté se renvoyaient les position avions en p2p normal,
ensuite ce que le hoste envoye dans le tuyau est perdu pour tous ! il ne peu y avoir de host de cette façon ! Pour t'en convaicre, cré une TE avec troupes au sol ( en mouvement de préfèrence) , déconnecte le hoste une fois en 3D , et va survoler tes troupes au sol .....

ou affronte un ennemi IA '(air/air) après déconnection du host ,
ou demande l'awaks , enfin tout ce qui est géré par le host quoi !

Vu que les ports de F4 sont en UDP, ils n'y a pas de relation Serveur<->client puisque l'UDP n'etablis pas de connexion pure dans le sens propre du terme, seul le TCP le fait.

Donc je pense que Falcon utilise uniquement un systeme de P2P et que les communications se font entre chaque participants et non pas centralisé par l'hote (qui servirait juste a initier le systeme et gerer certaine chose de la partie)

Pour verifier cette theorie il faudrais essayer de se connecter sur quelqu'un qui n'hoste pas mais qui est connecté a un host.

(Je crois qu'on avait deja fait ce test sur F4 il y a fort fort longtemps mais impossible de me souvenir du resultat)

Bah, révise sur le protocol UDP et tu auras une autre vue....






En UDP , tu n'as pas de confirmation de bonne réception, ce qui allège le flux et ce qui permet à l'exe de continuer à envoyer des données au lieu d'attendre un accusé de reception

[quote="toopack66"]Bah, révise sur le protocol UDP et tu auras une autre vue....






En UDP , tu n'as pas de confirmation de bonne réception, ce qui allège le flux et ce qui permet à l'exe de continuer à envoyer des données au lieu d'attendre un accusé de reception ]


Il n'y a pas de confirmation c'est normal puisqu'il n'y a pas de relation client/server comme le fait le TCP, c'est ce que j'ai ecrit en vulgarisant pour ceusse qui ne sont pas admin reseau.

CAT the PSION a écrit :il n'y a pas de relation client/server comme le fait le TCP, c'est ce que j'ai ecrit en vulgarisant pour ceusse qui ne sont pas admin reseau.

le model reseau serveur/client n'a rien a voir avec le presence ou non d'un control de transport

hé bien puisque tu le dis The Cat......

drafak a écrit :le model reseau serveur/client n'a rien a voir avec le presence ou non d'un control de transport

toopack66 a écrit :hé bien puisque tu le dis The Cat......

Quand je dis "vulgariser" c'est quel mot qui n'a pas été compris ?


On est pas sur le forum technique j'allais quand meme pas sortir un descriptif complet quand meme ^^

Le TCP est une forme de flux (d'ou ma vulgarisation client/serveur mais ce n'est pas exactement ca mais ca pourrais y ressembler) l'udp c'est plutot paquet par paquet sans aucun controle ni assurance que le paquet soit arrivé a destination.

CAT the PSION a écrit :Vu que les ports de F4 sont en UDP, ils n'y a pas de relation Serveur<->client puisque l'UDP n'etablis pas de connexion pure dans le sens propre du terme, seul le TCP le fait.

C'est celle là

Apres avoir relu une dizaine de fois ma propre phrase, je la comprends tres bien mais comme c'est moi qui l'ai ecrite je suis pas objectif ^^

Je vais essayer de detailler ma pensée que j'ai pu avoir mais avec ma memoire de poisson rouge je vois deja plus a quoi je pouvais penser quand j'ai ecrit.

F4 utilise les ports 2934 & 2935 en UDP pas en TCP.

L'UDP a un datagramme beaucoup plus "light" (Hote Port Taille Checksum Donnée) que le TCP (euh non je vais pas detailler sont trop dedans :p) mais pour la meme taille l'UDP transmet plus d'info (en treeeeeeeeees gros), ce qui explique _peut etre_ le choix de ce mode de transmission a l'epoque ou l'ADSL n'existait pas encore.

L'UDP ne necessite pas d'accusé reception de la part de l'hote distant par rapport au TCP qui necessite un "vrai" dialogue (d'ou mon allegorie client/serveur).

Je venais de m'emm***der a chercher une allegorie a la comparaison UDP/TCP mais apres reflexion mon exemple est pourris (valable mais pourris :p)

Ok, je t'ais compris ,
Mais celà n'empêche aucunement d'avoir une machine qui centralise alors que d'autres actualisent, et c'est bien comme çà qu'un jeu fonctionne, qu'il y ai accusé de réception ou non . Un jeu comme Falcon ( toutes versions confondues ) est bouffeur de bande passante .... parceque le théatre est immense , les déplacement sont rapides ( avions ) , les changements d'états sont très nombreux ( armements, rwr, radar, ranges sams, IA avions, IA sol/air, ect .... ) donc il est facile de comprendre la necessité d'avoir une centralisation pour certaine catégorie de données, et du p2p pour entre autres le rafraichissement des données de positionnement propre à son avion, état armement, ect ..... qui sont envoyées à chaques connecté ( y compris au host )

Enfin , tout çà pour dire que si tu perds un client , tu te retrouves avec un IA de plus alors que si tu perds le host tu perds la partie bien que tu gardes le positionnement car p2p avec ceux connectés ect. et c'est ce que décrit Jallie.... Ensuite il y a les priorité mais çà chaque dèv fait comme il le sent et je ne peu te dire ce qui est codé dans AF

c'est ce que j'ai dit ^^

Tu perds le contenu (IA etc.) de la partie mais pas les joueurs en vol

On tourne en rond la et on fait pas avancer le sujet :p

l'UDP est un mode de transfert simple non securisé (si tu perds un paquet tant pis, l'expediteur ne sait pas que sont paquet a été perdu, et le receveur ne sait pas qu'un paquet lui etant destiné est perdu), utilisé par les jeux la plus part du temps (comme les quake like) car il est peu gourmand en ressource donc plus rapide.

le TCP est un mode de transfert sécurisé : en cas de perte de paquets détectée (car il y a une rupture de séquence) une retransmission est possible. Plus lourd au niveau ressource. en TCP les 2 machine sont obligé d'ouvrir un canal de communication entre eux.

CAT the PSION a écrit :c'est ce que j'ai dit ^^

Tu perds le contenu (IA etc.) de la partie mais pas les joueurs en vol

On tourne en rond la et on fait pas avancer le sujet :p

Parceque tu penses que tu peux aller au bout de ta mission si tu perds le host ?
J'entends par IA toute l'intelligence artificielle gestion des troupes/sams/tanker/awacs compris

Beh non c'est normal qu'il y ai pas moyen de finir la mission j'ai jamais dit le contraire ^^

Mais c'etait pas vraiment le sujet, le sujet c'etait que les autres puissent continuer de jouer meme sans Hote, IA ou pas ^^

C'est logique, chaque jouer édite sa map ( terrain) et refraichit les données de position du p2p restant et idem pour les autres ...... Avant (bms2) lorsque tu perdais le host c'était CTD assuré voir même quand perte d'un client tu avais CTD du host pas loin derrière .....mais bon, le code réseau n'avait jamais été réellement travaillé et qui plus il était complètement branlé.....
Enfin pour moi c'est très claire , j'ai peut-être du mal à exprimer çà ?