PVP de masse (nvidia)

Répondre
Partager Rechercher
Citation :
Publié par Niea
C'est pas plus dangereux que de ce fier aux avis de la majorité ( surtout 3 personnes sur JOL )

Vous avait des exemple de gens avec de bonne config ( I7 / GTX 295 ) qui arrive à jouer un peu prêt bien. ( Et soit dit au passage jouer a 20-30 FPS avec une config de taré ya quand même un problème O.o ) --> Peut être qu'avec un meilleur serveur, ils pourraient jouer en full AA 9600x7200 en tournant à plus 80 image/sec ... qui sait. Le moteur du jeu doit jouer pas mal mais bon ....

Moi j'ai des exemple de gens qui on des très bonne config et qui dépasse pas les 10-15 fps en Shift/F12 ....
Je ne comprends pas comment tu peux persister dans ton raisonnement illogique avec toutes les explications sur le rôle d'un serveur données ici par plusieurs personnes et même si pour divers raisons tu n'avais pas confiance,tu as internet/wikpedia pour vérifier que ces explications sont correctes.

C'est pas comme si nos écrans étaient directement branchés au serveur si ?
Personne n'a dit qu'il n'y avait pas de problème mais que ce probleme de chute/bas fps ne peut venir du serveur car ce n'est pas son rôle.
Le problème vient du jeu en lui même qui est tres gourmand en cpu/ram quand il y'a masse.
Je t'invite aussi à aller consulter les sujets à propos de ça sur aionsource si il te reste quelques doutes.
Citation :
Allez va, regarde cette vidéo plein écran en HD, et tu verra que si ce joueur est capable de jouer a 100ips + les graphismes aux max sans aucune saccade pendant un RvR , il le doit bel et bien a son monstre de PC et non a un serveur en pleine forme...
- Ce que je vois c'est qu'il y a tout casser 50-70 personnes sans asmo.

- Ce que je vois c'est ce commentaire : "" mate what is ur machine and ur windows ? please i have relaly good machine and cant get more then 8fps at max details on siege ;( my pc spec : I7 860 / 8GB Corsair 1333 / GTX 275 / 650W PS - 37" 1080p Display - on win 7 Ultimate 64Bit ""

Commentaire qui prouve assez bien que la puissance de nos machine ne servent pas des masse. Et si ça viens pas de nos machine ..... je vais pas vous faire un dessin ....

--------------------------

Que mon explication soit mauvaise ou non ça change pas le fait que le soucis viens principalement des serveurs. Puisque vous n'arrêter pas de répéter que ça lag ....

Dans tous les cas avoir un super PC ça vous empêchera pas d'avoir 10 FPS en siège ( un siège C'est plus de 200 personnes hein .... pas 50 )
Visiblement tu n'as toujours pas fais de recherches sur quel est le rôle/fonction d'un serveur sinon tu arrêterais de t'obstiner sur cette voie là.

en ce qui concerne le commentaire,le gars ne précise pas si son i860 est overlocké ou non,le posteur de cette video est à 3.75 ghz donc 1.1 ghz en plus c'est pas négligeable.

je t'invite à regarder la video en page 4 de ce topic et si tu me dis qu'il n'y a que 50 personnes ce sera manifestement de la mauvaise fois.
à noter que avec fraps c'est au moins 10 fps en moins.

Le problème a été plus ou moins expliqué en bref jeux anormalement gourmand en cpu quand il y a masse mais je me répète là.
Citation :
Publié par Niea

Commentaire qui prouve assez bien que la puissance de nos machine ne servent pas des masse. Et si ça viens pas de nos machine ..... je vais pas vous faire un dessin ....
... c'est que ça peut venir du client (le jeu quoi si tu préfères).

Citation :
Publié par Niea
Que mon explication soit mauvaise ou non ça change pas le fait que le soucis viens principalement des serveurs. Puisque vous n'arrêter pas de répéter que ça lag ....
Non, on te dit justement que ce n'est PAS du lag.

LAG =/= chute de FPS
Lag = problème lié à la connexion (donc FAI ou latence serveur)
chute de FPS = problème PC (que ce soit la config ou du matos mal exploité à cause de drivers ou version directX ou client pas copain avec ton matos, etc.)

J'peux pas être plus claire je crois

Bref comme dit plus haut, ça tourne en rond.
*overdose de boucles après une soirée php, pas envie de se torturer davantage*
Citation :
Publié par Niea
- Ce que je vois c'est qu'il y a tout casser 50-70 personnes sans asmo.

- Ce que je vois c'est ce commentaire : "" mate what is ur machine and ur windows ? please i have relaly good machine and cant get more then 8fps at max details on siege ;( my pc spec : I7 860 / 8GB Corsair 1333 / GTX 275 / 650W PS - 37" 1080p Display - on win 7 Ultimate 64Bit ""

Commentaire qui prouve assez bien que la puissance de nos machine ne servent pas des masse. Et si ça viens pas de nos machine ..... je vais pas vous faire un dessin ....

--------------------------

Que mon explication soit mauvaise ou non ça change pas le fait que le soucis viens principalement des serveurs. Puisque vous n'arrêter pas de répéter que ça lag ....

Dans tous les cas avoir un super PC ça vous empêchera pas d'avoir 10 FPS en siège ( un siège C'est plus de 200 personnes hein .... pas 50 )
Pour le lag serveur la question posée été plutôt problème FAI ou NCsoft.

Faut bien lire!(texte en rouge) Si le mec coche l'option fixed FPS bizarrement y vas beaucoup moins ramer et passera très très facile a 30+ fps. C'est qu'un mmo mais faut pas non plus croire au miracles.
certain possesseur d'i7 ne tourne pas correctement en prise de fort donc try again la théorie du cpu limited .

ca pourrait etre du lag car même si la puissance est présente une arriver trop lente d'info , la puissance sert a rien si elle traite rien...

apres c'est peu être un phénomène "lag asmo" qui se répète en boucle ( quand un asmo entre il y a un minilag pour certain joueur, donc 300 asmo ... )
Citation :
Publié par Atsura
apres c'est peu être un phénomène "lag asmo" qui se répète en boucle ( quand un asmo entre il y a un minilag pour certain joueur, donc 300 asmo ... )
C'est mon cas, par contre j'appellerais pas ça un minilag (souvent 0,5sec, presque 1 sec), parfois ça serait plutôt un gros freeze (2 secondes), et ça arrive avant même qu'il soit visible sur la minimap en général, donc pas d'affichage graphique du personnage en question. Mais tu dis : certain joueur, ce qui veut dire pas tous, je pensais que ça venait de mon PC est ce le cas ?
Citation :
apres c'est peu être un phénomène "lag asmo" qui se répète en boucle ( quand un asmo entre il y a un minilag pour certain joueur, donc 300 asmo ... )
C'est justement pas un lag... L'écran se fige, c'est côté client que ca se passe.
C'est dingue la désinformation à propos de la nuance rame/lag.

J'ajouterai que dans une partie technique de forum, il vaudrait mieux s'abstenir quand on ne connait pas le fonctionnement d'un serveur plutôt que d'émettre des théories absolument fausses et fondées sur un abus de langage. ("Ho micro-lag ! asmo !")
Citation :
apres c'est peu être un phénomène "lag asmo" qui se répète en boucle ( quand un asmo entre il y a un minilag pour certain joueur, donc 300 asmo ... )
J'aime bien ça en rift, comme ça je sais quand un Asmo est dans le coin sans même avoir à regarder le radar.
Citation :
Publié par Atsura
certain possesseur d'i7 ne tourne pas correctement en prise de fort donc try again la théorie du cpu limited .
C'était mon cas il y a 2 semaines, après l'obtention de mon i7 920@2.67GHz. Je tournais entre 20 et 25fps.

Et puis j'ai démonté une ancienne machine pour récupérer mon DOD, histoire de faire un peu d'overclocking... i7 920@4GHz, je tourne à 65fps constant, dans une forteresse avec 500 bourrins se tapants dessus, et tout ça avec une 4870X2.

La config :
-i7 920@4GHz
-CM x58-Pro
-6Go DDR3 PC12800
-SSD 64Go
-ATI 4870X2

Tout ça simplement pour dire que le problème ne vient pas du serveur mais bien du client. Les possesseurs d'i7 ayant ces problèmes devraient essayer d'OC ce dernier, au moins jusqu'à 3.4GHz, c'est sans risque a ce niveau et le gain est significatif. Le fait est que le GPU se décharge d'une partie des calculs quand il est débordé, passant la main a la puissance de calcul du processeur. Évidement, la fréquence RAM doit également suivre.

Citation :
Publié par Niea
OK alors expliquez moi pourquoi le simple fait d 'être dans une forteresse vide ( avec la masse de joueurs à 300m en train de taper des tours dehors ) lors d'un siège fasse chuter les FPS. Ça ne peut pas venir de chez moi vu que je n'ai aucun élément supplémentaire à l'écran qui pourrait faire ramer mon PC. Et je suis pas le seul à qui ça arrive.
Justement si, ça vient de chez toi, le calcul des textures, animations, mouvements, etc, se fait a une distance donnée, pour reprendre ton exemple disons à 300m. Sinon, tu ne chargerais les skins qu'une fois que tu les auraient en vis a vis, ce qui n'est pas le cas quand tu croise un pelos en 1v1. ^^

La seule chose que peut provoquer une insuffisance serveur, c'est un retard au niveau des calculs d'événement, donc un lag "serveur", insondable grâce au ping puisque l'envoi du paquet se fait bien via ton FAI. Si le lag serveur était tel que ce que tu dis, tu verrais des persos se déplacer par saccade. De plus, si tu observais la scène, tu pourrais te déplacer de manière fluide, avec des pushback dues a l'incohérence de ta position (client) par rapport aux coordonnées que t'alloue serveur.
Vous avez tous faux.

Avant, j'étais partisan du : si ca rame c'est que le PC est pas suffisamment puissant, si ca lag, c'est la connexion.
Ok, c'est bien, sauf qu'on parle d'un MMORPG. La ou il y a des synchros partout dans le code, avec un netcode bourrin, un clustering coté serveur, des routines censés améliorer l'affichage de masse etc ...

Donc pour commencer : oui le netcode a à voir avec l'affichage. Juste a cause du pré-caching des textures et des modèles. (se qui bouffe le plus de ressources) -> Ca cause des "mini/micro" freeze quand un ennemis de la faction adverse se trouve dans la zone -> Votre connexion reseau est bonne mais un goulet d'étranglement dans la chaine DD/ram/cpu existe quelque pas. Optimisez vos timings mémoire, passez sur un raid 0, clockez un peu votre FSB ?

Ensuite, l'affichage des textures et d'un trop grand nombre de personnes peu causer des fractionnement de paquets. Un datagramme trop gros, trop de données et bam, fractionnement : un temps de calcul est necessaire au jeux pour soit redemander les infos, soit recoller les informations -> Ca provoque des rollback du personnage.

Packet loss : dans la chaine de transmission réseau, parfois, ben y'a des paquets qui se perdent. Le serveur gère mal et votre client sais pas quoi faire, alors il se met a idle. -> Ca rame.

Packet loss + fractionnement (typique en forto) ben la, vous avez droit a un peu tout. Non seulement le precaching se fait mal, mais en plus vous avez des rollback et votre client slack.


Précision : si vous croyez que c'est du TCP/IP le réseau, vous me faite rire. Ok, l'ecapsulasion se fait en TCP, mais c'est tout. A l'interieur, les packets c'est pas du TCP, ca resiste un minimum a tout se que j'ai mis au dessus, mais y'a une limite.
Le ping, c'est des requetes ICMP qui envoient la commande sur les serveur frontend, et sur aion c'est le backoffice qui est laborieux.

Si vous ne voyez pas de liens dans se que j'ai dit : retournez en cours de sys/reseau.
Citation :
Publié par norelenilia
raid 1 plutot non ? parce que raid 0 apporte rien en perf
Il apporte en bande passante mais pas en réactivité, vue que le temps de positionnement des têtes est multiplié par deux, mais le débit est censé être multiplié par deux aussi. Ca, c'est la théorie.
En pratique :
-La majorité des contrôleurs raids grand publique sont se qu'on appelle des "PHY", en gros, se sont des interface rendant electriquement compatible le raid, le reste étant géré logiciellement (et donc par le processeur centrale) le gain apporté est donc faible (de l'ordre de 10 a 20%) puisqu'utilisant le bus de donnée principal (série) du southbridge (ou du moins la partie adaptateur) donc le flux de donnée fait DD > PHY > southbridge (full duplex/fullspeed) > northbridge (souvent c'est un lien partagé pci-express 1x pour tout les composants reliés au SB, en semi duplex) > FSB.
-Seul un contrôleur spécifique approche le doublement des performances.

Dans les faits, le stripping est plus interessant que le mirroring (raid1) dans la majorité des cas usuels sur un PC grand publique. Puisque dans un PC grand publique, le débit est a privilégié face a la latence.
Citation :
Publié par Brume-KiSS FC
Vous avez tous faux.

Avant, j'étais partisan du : si ca rame c'est que le PC est pas suffisamment puissant, si ca lag, c'est la connexion.
Ok, c'est bien, sauf qu'on parle d'un MMORPG. La ou il y a des synchros partout dans le code, avec un netcode bourrin, un clustering coté serveur, des routines censés améliorer l'affichage de masse etc ...
Il y a des syncros partout oui (normal même), mais aucun lock sur le rafraichissement de l'image en attente d'un paquet par exemple (à part les jeux codés n'importe comment comme je le disais plus haut, mais ils sont assez rare dans le milieu pro).
Le clustering côté serveur... bah on s'en fout un peu côté client.

Citation :
Donc pour commencer : oui le netcode a à voir avec l'affichage. Juste a cause du pré-caching des textures et des modèles. (se qui bouffe le plus de ressources) -> Ca cause des "mini/micro" freeze quand un ennemis de la faction adverse se trouve dans la zone -> Votre connexion reseau est bonne mais un goulet d'étranglement dans la chaine DD/ram/cpu existe quelque pas. Optimisez vos timings mémoire, passez sur un raid 0, clockez un peu votre FSB ?
Attention, tu détournes la problématique là. On a jamais dit que le netcode avait aucun rapport avec l'affichage, ça serait équivalent à dire que jouer à un MMO avec internet ou sans internet ne changerai rien.
Le problème était : Est-ce qu'un problème de serveur/connexion provoque directement une chute de fps chez le client ?
Le fait que tu dises que le pré-caching "bouffe plus de ressources" montre justement qu'il s'agit bien d'un problème de performance et non de lag.
Et le fait que tu parles d'optimiser le matériel, confirme d'avantage tout ça.
Au passage, c'est bien le raid0 qui améliore la vitesse alors que le raid1 (mirroring) permet une protection supplémentaire des données.
Citation :
Ensuite, l'affichage des textures et d'un trop grand nombre de personnes peu causer des fractionnement de paquets. Un datagramme trop gros, trop de données et bam, fractionnement : un temps de calcul est necessaire au jeux pour soit redemander les infos, soit recoller les informations -> Ca provoque des rollback du personnage.
Aïe, aïe, aïe, tu te mélanges les pinceaux là. Les textures ne sont PAS envoyé sur le réseau, ça reviendrait à dire que tu retélécharges les textures qui sont déjà disponible dans ton disque dur à chaque fois que tu rencontres quelqu'un.
Tu te rends compte de ce que tu dis là ?

Citation :
Packet loss : dans la chaine de transmission réseau, parfois, ben y'a des paquets qui se perdent. Le serveur gère mal et votre client sais pas quoi faire, alors il se met a idle. -> Ca rame.
Faux, un packet loss sera suivi soit par une nouvelle requête soit par une déconnexion du jeu mais en aucun cas le PC souffrira d'une perte de performance à cause de ça !
"Le client ne sait pas quoi faire" => Il sait toujours quoi faire s'il est codé proprement, s'il ne sait pas quoi faire ça veut dire que t'as planté et ça ne va pas plus loin.

Citation :
Packet loss + fractionnement (typique en forto) ben la, vous avez droit a un peu tout. Non seulement le precaching se fait mal, mais en plus vous avez des rollback et votre client slack.
Bon reprenons : Le packet loss arrive assez rarement, ça ne touche surtout que les mauvaises lignes. Forto ou pas forto, ça ne changera pas le taux de paquets perdus. Au pire il y aurait une augmentation du délai (ping), voir une coupure de connexion à cause du délai trop important mais rien de plus.
Le fractionnement aussi, tu ne peux pas savoir s'il a lieu (et honnêtement j'en doute fort) si tu ne connais pas le protocole de communication du client/serveur.
Exemple : Qui te dis qu'il rempli un paquet avec toutes les infos d'un coup et non pas un nouveau paquet à chaque nouvelle requête (donc pas de fractionnement) ? Sans réelle connaissance des clients MMOs, je pense pas que le fractionnement de paquet ait souvent lieu.

Citation :
Précision : si vous croyez que c'est du TCP/IP le réseau, vous me faite rire. Ok, l'ecapsulasion se fait en TCP, mais c'est tout. A l'interieur, les packets c'est pas du TCP, ca resiste un minimum a tout se que j'ai mis au dessus, mais y'a une limite.
Le ping, c'est des requetes ICMP qui envoient la commande sur les serveur frontend, et sur aion c'est le backoffice qui est laborieux.
Oulalalalala ! Alors là tu nages dans l'incompréhension totale !
Tu te contredit toi même dans ta phrase : "C'est du TCP mais pas du TCP/IP"
Tu te rends compte de ce que ça veut dire ? Le TCP EST encapsulé dans du IP.
Les paquets tu crois qu'ils voyagent comment sur le réseau ? Si IP n'est pas utilisé je veux bien que tu supprimes tous mes persos à Aion
Tu dis que c'est encapsulé en TCP mais qu'à l'intérieur c'est pas du TCP... Là encore c'est un non sens total ! Le TCP n'est là que pour encapsuler les informations justement, tu voulais quoi de plus ?
D'ailleurs il me semble que Aion utilise également une connexion UDP pour les canaux en jeu donc y a du TCP et du UDP.
Quant au ping on sait que c'est du ICMP mais il est où le rapport avec Aion là ? De quel backoffice tu parles ?

Citation :
Si vous ne voyez pas de liens dans se que j'ai dit : retournez en cours de sys/reseau.
Franchement, celui qui a besoin de cours de sys/réseau c'est bien toi. Tes bases sont mal acquises et tu mélanges tout. Bref une bonne révision te ferait pas de mal coco
Citation :
Publié par Jinou
Au passage, c'est bien le raid0 qui améliore la vitesse alors que le raid1 (mirroring) permet une protection supplémentaire des données.
Le raid 1 ameliore la vitesse de 30% a peu pres puisque les 2 disques peuvent etre lus simultanement
Citation :
Publié par norelenilia
Le raid 1 ameliore la vitesse de 30% a peu pres puisque les 2 disques peuvent etre lus simultanement
Oui pour la lecture uniquement
Punaise, quote-wars est la. Et pour couronné le tout, il détourne se que je dit xD.
Déjà je vais répondre aux deux posts d'avant.

Le mirroring améliore la latence en la divisant par deux (si il y a deux disques de spanning, plus si il y a plus de disques dans la grappe donc), un peu comme du NCQ (sauf que c'est pas du NCQ). Mais vue qu'on a qu'un PHY, ben le processeur a pas forcement le temps de faire les calculs de prédisposition des têtes de lectures sur les X disques de spanning et donc le gain est misérable avec du matériel grand publique. Le débit reste inchangé. le seul inconvénient c'est qu'on perd en taille.
Le stripping améliore le débit au détriment de la latence. La latence et le temps de positionnement des têtes est multiplié par le nombre de disques, mais le débit également.
Le raid 5 améliore le débit et la latence au détriment du temps de calcul.

Pour monsieur quote.

Citation :
Aïe, aïe, aïe, tu te mélanges les pinceaux là. Les textures ne sont PAS envoyé sur le réseau, ça reviendrait à dire que tu retélécharges les textures qui sont déjà disponible dans ton disque dur à chaque fois que tu rencontres quelqu'un.
Tu te rends compte de ce que tu dis là ?
J'ai dit que les textures étaient envoyées sur le réseaux ? xD
Je te fait la chaine :
Elyo arrive sur spot > envoie youhou je suis la au serveur > serveur reçoit l'information > envoie l'information aux clients de touts poils > client dit je le vois pas mais je pre-cache les données de Elyo, on sais jamais. (soit textures, squelette, formes, mods, couleurs et même position !)

Multiplie ca par le nombre de personnes dans une zone, avec des chargements/déchargements pas toujours fait de manières propre ... Tu comprendra que le netcode est DANS le moteur d'affichage du jeux.

Citation :
Faux, un packet loss sera suivi soit par une nouvelle requête soit par une déconnexion du jeu mais en aucun cas le PC souffrira d'une perte de performance à cause de ça !
"Le client ne sait pas quoi faire" => Il sait toujours quoi faire s'il est codé proprement, s'il ne sait pas quoi faire ça veut dire que t'as planté et ça ne va pas plus loin.
Etttttt pas de bol. Je vais pas parler de choses illégales ici, mais certaines personnes s'amusant a casser du netcode trouvent le fonctionnement et l'interaction client/serveur d'Aion franchement crade. Et de toute façon, je te rassure pas, tout est crade dans le monde du jeux vidéo parce que le but entre un client et un serveur de mmorpg, c'est pas la sécurisation des données mais la latence pour limiter justement le lag. Donc un client qui idle quand y'a un paquet loss ... Osef, c'est pas critique
Citation :
Oulalalalala ! Alors là tu nages dans l'incompréhension totale !
Tu te contredit toi même dans ta phrase : "C'est du TCP mais pas du TCP/IP"
Tu te rends compte de ce que ça veut dire ? Le TCP EST encapsulé dans du IP.
Les paquets tu crois qu'ils voyagent comment sur le réseau ? Si IP n'est pas utilisé je veux bien que tu supprimes tous mes persos à Aion
Tu dis que c'est encapsulé en TCP mais qu'à l'intérieur c'est pas du TCP... Là encore c'est un non sens total ! Le TCP n'est là que pour encapsuler les informations justement, tu voulais quoi de plus ?
D'ailleurs il me semble que Aion utilise également une connexion UDP pour les canaux en jeu donc y a du TCP et du UDP.
Quant au ping on sait que c'est du ICMP mais il est où le rapport avec Aion là ? De quel backoffice tu parles ?
biduletruc/TCP/IP pendant la phase de login, qui devient "biduletruc a en-tête TCP mais qu'est pas du TCP"/IP.
En gros, c'est ni de l'UDP, ni du TCP, ni du n'importe quoi, c'est un protocole qui a les en-têtes TCP pour être routé sur le réseau mais c'est du maison qui répond a aucunes RFC, encore plus gros donc : t'as une forme d'encapsulation qui ressemble a du TCP, ca se sniffe comme du TCP, ca a le gout du TCP mais c'est pas du TCP. Tu veux un dessin, le protocole réseau, la clef de cryptage des paquets et tout le bordel ? Je te laisse t'amuser a coller un proxy avec wireshark recuperer et faire l'analyse des paquets. Perso, je l'ai fait c'était bien trippant mais je le referais plus.

la commande /ping du jeux fait envoyé un ping icmp en mode console a windows vers le frontend (et donc les serveurs front office) de ncsoft/aion, le backend (backoffice) n'est pas du tout testé. Si le problème (paquet loss/fragmentation/tout se que tu veux) viens du backoffice, tu l'as dans l'os, t'as aucuns moyens de savoir si le clustering va bien ou pas toi en temps que client final.
Monsieur quote, quote (cot cot ?) pour pas répondre un bloc illisible et incohérent, mais si tu préfères je ne quoterais (du verbe quoter, casser des côtes) pas dans ce post :

Alors soit pour la texture, si tu ne pensais pas ça tant mieux mais tu admettras que ça n'avait pas de sens : "l'affichage de beaucoup de texture peut provoquer une fragmentation des paquets".

Si tu parlais du nombre conséquent d'information, je répète ce que j'avais dit : Il y a de forte chance qu'un paquet soit émis à chaque requête sinon on perdrais en réactivité s'il fallait attendre d'en "bourrer" un avant de l'envoyer.
Donc je ne pense pas qu'il y ai de fragmentation.

Ensuite pour le code qui est crade je veux bien te croire mais ça ne change pas le fait qu'un paquet perdu, qu'une connexion soit en idle ou autre problème réseau fasse chuter le FPS du client.

Quant au protocole utilisé, tu continues de confondres, voilà comment ça fonctionne :
Ethernet <= IP <= TCP <= Protocole AION

L'un encapsulé dans l'autre. Donc si TCP/IP est bien utilisé, et par dessus la communication client/serveur ont leurs protocole propre qu'on ne connait pas (enfin les développeur de serveur privé si).
Je n'ai pas besoin de dessin, je connais très bien les sujets dont je parle et la clé de cryptage (chiffrement si on veut être correct) est tout un autre sujet.

Wireshark n'est qu'un outil qui permet d'intercepter les paquets, tu n'avais pas besoin de passer par un quelconque proxy, ton PC aurait fait très bien l'affaire.
Et tant qu'on parle de ça, prends un screen des paquets sniffé et post là que tu voies qu'il s'agit bien de TCP/UDP, de toute manière un netstat aurait suffit à te le montrer.
Au passage, ça m'étonnerais que tu ais utilisé un proxy, mais plutôt un routeur en mirroring.

Quant au cluster de serveurs, une fois encore on en a rien à faire en tant que client.
Nous on voit le serveur en tant qu'entité qui répond à nos requête, ce qui s'y passe en interne on s'en tape le coquillage, s'il va mal ou super bien ça se verra au niveau du temps de réponse mais encore une fois ça ne jouera pas sur la fluidité (FPS) de ton client.

Bref, j'ai l'impression que tu cherches surtout à étaler ta "connaissance" sans connaître le fonctionnement.

C'est pas méchant, mais je ne supporte pas la désinformation sur les forums.
Non non, je sais se que j'ai dit, les paquets ressemblent a du TCP, on les entête TCP mais pas du tout la compression ni les routines ni même le format du TCP.

Le simple netstat comme tu dit retourne bien que c'est du TCP, mais une analyse des paquets te dira que s'en est pas (hormis pendant la phase de login).
Une fois passer le login c'est bien protocole ncsoft/ip.

Et j'ai bien du proxyfier pour sniffer les paquets, puisque lancer le moindre programme de sniffage bloque le jeu et est contraire a l'eula en plus. (tout comme lancer le moindre programme de la suite sysinternal d'ailleurs, j'ai déjà signalé ça dans un post qui date des openbeta). Un bon gros "proxy" (je te le met entre guillemets parce que router tout le trafique d'un pc vers une passerelle ça s'apparente plus a du firewalling/filtrage ou autre, enfin c'est pas vraiment du proxy même si le programme utilisé est a la base un proxy enfin ... On détourne les outils quoi) transparent sur lequel est routé tout le trafique de la machine, se qui permet, en toute transparence et sans altérer ni modifier les routes de sniffer les paquets.

Donc, je te l'affirmer : le paquet loss (qui arrive fréquement) et la fragmentation des paquets font que ton client rame. (et pas lag)
Citation :
Publié par Brume-KiSS FC
puisque lancer le moindre programme de sniffage bloque le jeu et est contraire a l'eula en plus. (tout comme lancer le moindre programme de la suite sysinternal d'ailleurs, j'ai déjà signalé ça dans un post qui date des openbeta).
Sérieusement ? O_O O_O
car j'utilise process explorer continuellement , et de manière tellement naturelle maintenant que je le lance sans me préoccupé des programmes exécutés sur mon PC, aion ou non

on risque le ban pour logiciel tiers ou un truc du genre pour ça ?
Car à ma connaissance, ce logiciel ne fournit aucune information que l'on ne puisse trouver autrement, c'est juste beaucoup plus pratique et rassemblé ....

j'avais entendu dire que certains éditeurs n'aime pas les soft du vieux Mark mais je n'avais jamais constaté ça. ils ont peur de quoi ? d'un pseudo reverse engineering ?
Citation :
Publié par Mr Duke
Sérieusement ? O_O O_O
car j'utilise process explorer continuellement , et de manière tellement naturelle maintenant que je le lance sans me préoccupé des programmes exécutés sur mon PC, aion ou non

on risque le ban pour logiciel tiers ou un truc du genre pour ça ?
Car à ma connaissance, ce logiciel ne fournit aucune information que l'on ne puisse trouver autrement, c'est juste beaucoup plus pratique et rassemblé ....

j'avais entendu dire que certains éditeurs n'aime pas les soft du vieux Mark mais je n'avais jamais constaté ça. ils ont peur de quoi ? d'un pseudo reverse engineering ?
Oui process explorer lancé avant aion empêche le lancement du jeu. Le soucis de ces logiciels, c'est que oui, ils permettent dans une certaine mesure de faire du reverse. Et hm, si process explorer permet quand même de récupérer des informations que tu n'aurais pas autrement (et surtout un historique chronologique des actions d'un process, le nombre de threads et autre :/)
Process explorer est aussi a la base de nombreux logiciels de botting (ca permet de savoir par exemple, quel DLL/thread gère le clavier ? )

Et oui tu risque le ban sur le papier.
Citation :
Publié par Brume-KiSS FC
Oui process explorer lancé avant aion empêche le lancement du jeu. Le soucis de ces logiciels, c'est que oui, ils permettent dans une certaine mesure de faire du reverse. Et hm, si process explorer permet quand même de récupérer des informations que tu n'aurais pas autrement (et surtout un historique chronologique des actions d'un process, le nombre de threads et autre :/)
Process explorer est aussi a la base de nombreux logiciels de botting (ca permet de savoir par exemple, quel DLL/thread gère le clavier ? )

Et oui tu risque le ban sur le papier.
Merci, je ferais attention. Oui effectivement il permet beaucoup de chose mais il me semble qu'avec des requêtes sur le wmi et/ou à l'aide de powershell on peut obtenir la même chose.

Bon , quoi qu'il en soit je ferais attention, heureusement que j'ai lu ça, car un jour ou l'autre je serais aller voir dedans, juste pour voir comme d'hab
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés