[Cours] La programmation réseau
-
Il y a t-il un moyen de réaliser un client-server en tcp ou UDP en quelques lignes? Ou faut-il obligatoirement réaliser toutes la gestion de sockets, les différentes options et tout ça, c'est vite le bordel ;).
Sinon sympa le tutoriel
-
Hey,
ça dépendra du langage, et si tu utilises ou non une librairie. Dans tous les cas, faire du network est un challenge, autant que la gestion mémoire, c'est donc souvent une prise de tête, sans parler du débugging en networking qui est... Difficile
-
Le réseau est pas aussi compliqué que ont le croix ! moi par exemple je joue un peux avec est j'ai appris tout seul avec du code open source
après sa peu devenir un casse tête ! -
Le 5/2/2016 à 14:57, aurelien974 a dit :
Le réseau est pas aussi compliqué que ont le croix ! moi par exemple je joue un peux avec est j'ai appris tout seul avec du code open source
après sa peu devenir un casse tête !En C# c'est vrai que c'est relativement simple, mais c'est parce-que le framework net facilite beaucoup. En réalité c'est très complexe.
-
il y à pas que C sharp
le java aussi c'est facile ^^ est en c aussi je trouve ! après c'est pas parce que j'utilise un langage tout le temps sur le forum (C#) que je connais pas d'autre langage ^^ après le Tcp ou l'udp c'est des normes pour que tout les ordinateur communique en semble. tu peux aussi créer ta normes à toi ^^Le Tcp c'est tout simplement comme une ligne téléphonique.
L'Udp c'est comme si tu envois une lettre que tes pas sûr que le destinataire va recevoir
( mais c'est parce-que le framework net facilite beaucoup. En réalité c'est très complexe. ) après je vois pas le problème d'utilisé des outils qui facilite la programmation ^^
-
Mon commentaire s'applique à la plupart des langages populaires car ils possèdent tous une ou plusieurs librairies qui facilite ça.
Et je n'ai jamais dit que c'était un problème, c'est même très bien et je dirais même indispensable.
-
En réalité, c'est encore plus complexe que vous ne le pensez ;). Par exemple, en TCP, la perte d'un packet peut engendrer plusieurs centaines (voir milliers) de MS en ping! Tout ça parce que la liste de packets à envoyer en TCP se rallonge ;). Pour résumer, un packet foireux peut engendrer des secondes de délais si il y en a beaucoup à la chaine.
l'UDP est plutôt facile à comprendre: on envoit une lettre sans être sur qu'elle soit reçue. Mais bon, très compliqué à gérer niveau code. Il faut vérifier que le packet est bien reçu, et qu'il n'est pas corrompu. Bref, un bordel! Souvent on utilise ce qu'on appelle du "Reliable" en UDP, c'est une implémentation qui permet de "tracker" les packets, tout en gardant la puissance de l'UDP.
Comprendre, en interne, le TCP et L'UDP est très important. Le TCP est pré-fait avec des systèmes reliables, mais qui ne sont pas forcémment optimisés. (ils le sont pour leur utilité, mais pour un jeu par exemple, le TCP n'est pas conseillé). L'UDP permet, du fait qu'il ne soit pas "connecté" de créer son propre système reliable, et donc d'implémenter sois même un système plus adapté (un des exemples étant l'UDT, qui allie la rapidité de l'UDP avec la force du TCP (je rappelle que l'UDT est encore en dev!)).
Bref, quand on a très peu d'experience dans le domaine, on se dit que c'est facile, mais ayant fait mes études très spécialisées là dedans (MSc Network & Network Security) je peux te confirmer que c'est trèèèès compliqué.
Question de passage: d'après vous, il vaut mieux envoyer plusieurs "petits" packets en TCP ou un gros packet TCP? (celui qui réponds correctement, je lui dis bravo!)
-
A mon avis, il vaut mieux envoyer un gros packet, ça évite d'avoir à envoyer l'header à chaque fois.
-
Question piège ofc. En faite, ça dépends! Si le packet est trop gros, il sera, dans tous les cas, découpés en "Frames" et envoyé en plusieurs fois ;). Le problème n'étant pas vraiment la taille du packet le problème, mais bien entendu la cadence d'envois ;). En TCP, il ne faut pas oublier qu'on est dans un contexte d'envoit->réception->avis de réception. Donc bon, d'une manière générale, il vaut mieux envoyer un packet "package" avec pas mal d'infos, en TCP, plut^ot que plein de petits :). Le mieux étant encore de respecter les framesizes internationales. Mais bon, là on va un peu trop loin :).
L'UDP, à contrario, est pensé pour l'envoit de plein de petits packets rapidement (en effet, + le packet est gros, + il a de chances d'^etre perdu).
Bref, comme je l'ai dis, le réseau est quelque chose de très complexe, et c'est quand on a des app avec des milliers de connexions qu'on commence à s'en rendre compte!
Si vous avez d'autres questions, n'hésitez pas!
-
C'est pour ça dans certain code qui utilise du Tcp on voie des sleep un peu partout x') pour pas spam, c'est mieux aussi de découper soie même se que ont veux envoyer ! Est par exemple pour le déplacement d'un personnage en ligne c'est mieux de utiliser du peer-to-peer.
-
Il y a 4 heures, aurelien974 a dit :
C'est pour ça dans certain code qui utilise du Tcp on voie des sleep un peu partout x') pour pas spam, c'est mieux aussi de découper soie même se que ont veux envoyer ! Est par exemple pour le déplacement d'un personnage en ligne c'est mieux de utiliser du peer-to-peer.
Je ne vois pas le rapport du peer to peer avec le découpage des packets. Et pas beaucoup de jeux utilisent le peer to peer.
-
Le découpage est le peet to peer ça pas rapport.
Je voulais juste dire que au lieu d'envoyer un String par exemple qui est très long est l'envoyer comme ça. c'est mieux le découper soie même avent l'envoyer !
Bonjour ! Vous semblez intéressé par cette conversation, mais vous n’avez pas encore de compte.
Marre de refaire défiler les mêmes messages ? Créez un compte pour retrouver votre position, recevoir des notifications des nouvelles réponses, sauvegarder vos favoris et voter pour les messages que vous appréciez.
Grâce à votre participation, ce message peut devenir encore meilleur 💗
S'inscrire Se connecter