Discussion :

[hnouna2007]

Je veux implémenter une application qui fait communiquer plusieurs PCs sur le réseaux.

Ce que je veux savoir c'est:

Quelles sont les différentes solutions sur lesquelles je peux me baser?

Est il preferable d'envoyer trops de messages de petites taille, ou un petit nombre avec une taille importante?

Que-est ce qu'il limite la taille des messages?

Merci à toute personne essayant de me répondre

[nouknouk]

Quelles sont les différentes solutions sur lesquelles je peux me baser?

si tu travailles sur un réseau 'classique' au dessus d'IP, tu as typiquement le choix entre TCP et UDP. TCP est utilisé dans 90% des cas car il offre de fonctionnalités plus avancés pour garantir l'ordre de réception des paquets, la garantie de réception (si un paquet est perdu, il est réémis), l'ajustement de la bande passante utilisée, etc...

UDP est plus approprié dans des cas spécifiques ou les contraintes en "temps réel" sont les plus fortes et où la perte d'une partie des paquets n'est pas un gros souci (typiquement de l'audio.vidéoconférence, un FPS en multijoueur sur le réseau, etc...)

Est il preferable d'envoyer trops de messages de petites taille, ou un petit nombre avec une taille importante?

A priori, à taille de données utiles équivalente, il vaut mieux envoyer peu de messages plutôt que beaucoup de petits messages. En effet, pour chaque message envoyé il faut compter sur un surcroit d'octets transférés correspondant aux en-têtes des couches réseaux successives.

Par exemple, l'en-tête d'un paquet TCP fait 20 octets. Donc, pour les deux cas extrêmes pour 1000 octets de données à anvoyer:
- tu envoies un paquet => 1 * (1000 + 20 ) = 1020 octets.
- tu envoies milles paquets d'un octet chacun = 1000 * (1 + 20) = 21 000 octets.

Evidemment, l'exemple se focalise ici uniquement sur le protocole TCP ; pour avoir la taille totale d'un paquet de données, il faudra ajouter la taille des en-têtes de toutes les couches réseau inférieures.

A noter que pour le TCP, un algorithme est justement utilisé par défaut pour regrouper plusieurs petits paquets envoyés peu de temps les uns après les autres: l'algorithme de Nagle.
Cet algorithme est pratique dans la plupart des cas, mais peut tout de même poser problème lorsque l'application a des contraintes fortes en matière de "temps-réel". On désactive alors cet algorithme (cf. option TCP_NODELAY).

Que-est ce qu'il limite la taille des messages?

Toutes les infrastructures réseaux entre la source et la destination, et notamment les successions de protocoles différents (. Le chemin pris par un paquet pouvant être différent du paquet précédent, il est par conséquent impossible de déterminer la longueur maximale d'un paquet avant qu'il ne soit découpé automatiquement par le réseau : même si on peut l'estimer à un instant t, rien ne garanti que la valeur trouvée ne variera pas au cours du temps.

Il existe des façons de l'estimer, genre ça.

Certains protocoles (comme TCP) s'occupent tout seuls de reconstruire à la destination un message qui a été découpé par le réseau. D'autres non.

Typiquement, sur internet, tu peux compter sur une taille de paquet un peu au delà du kilo-octet sans trop de soucis.