Discussion :

[rdr2510]

Salut,

J'essaie d'envoyé un stream avec TIdUDPClient vers TIdUDPServer.

Le TIdUDPClient me renvoie une erreur "Taille de package trop large", pourtant la taille de stream est de 500Ko.

Est ce que vous avez une solution pour ça?

[ShaiLeTroll]

Avec un TClientSocket (TCP IP), la méthode SendStream va émettre ton stream découpé en paquet de 4Ko, c'est le code de la RTL qui lit le Stream par bout et appel send avec ce petit paquet de 4ko

Comme l'émission des 4Ko est rapide et rapproché, le receveur ne reçoit pas forcément 4Ko aussi nettement découpé !

J'ai fait un programme en Delphi 5 où j'envoyais 40 chaines une par une d'une longueur de 40 caractères et cela dans une boucle (envoi TRES TRES rapproché)
En face un programme en VSC++, recevait presque 20 chaines d'un coup, leur programme n'avait pas été prévu pour découper un buffer et d'y retrouver plusieurs chaines dans le même buffer
J'ai du adapter mon programme pour ralentir l'émission de ces trames pour que le programme C++ les recoivent bien une par une !
J'ignore d'où venait ce regroupement :
est-ce à cause tu TServerSocket et son système de message ?
est-ce windows ?
est-ce la carte réseau ?
...

Même entre un TClientSocket qui envoie un Stream de 1Mo, le TServerSocket en face reçoit des paquets de 8Ko alors que le code Delphi lui emet 4ko par 4Ko, magie du TCP IP qui regroupe !!!

C'est comme cela qu'on se retrouve avec de buffer fragmenté en paquet de 8Ko qu'il faut concaténer, évidemment, si l'on envoie plusieurs Stream à la suite, il faut avoir un protocol applicatif qui émet ses propres STX\ETX permettant de savoir où commence et fini un stream


Peut-être que le TIdUDPClient ne fragmente pas automatiquement le Stream et qu'il faut toi même émettre au maximum 64Ko :

UDP datagram IPv4 : 65,507 bytes
UDP datagram IPv6 : 65,527 bytes

[rdr2510]

Donc d'aprés ce que je compris, il faut que je crée une protocole qui decoupe le 500ko en 64Ko.

[ShaiLeTroll]

Si le TIdUDPClient ne le fait pas (ce qui m'étonne), oui cela serait une solution !

Mais il me semble que le SendBuffer fait une fragmentation *, il y a peut-être une option a vérifier avant de te lancer dans une uzinagaz

* si l'on fouille le code bien tordu de Indy, on fini sur GStack.SendTo puis en cherchant l’implémentation selon OS, on trouve un GetProcAddress sur sendto des API Windows

The sendto function is used to write outgoing data on a socket. For message-oriented sockets, care must be taken not to exceed the maximum packet size of the underlying subnets, which can be obtained by using getsockopt to retrieve the value of socket option SO_MAX_MSG_SIZE. If the data is too long to pass atomically through the underlying protocol, the error WSAEMSGSIZE is returned and no data is transmitted.

[Paul TOTH]

moi je dirais plutôt 1472 octets

si votre infrastructure de couche 2 est de l'ethernet alors quoi qu'il arrive vos paquets de couche 4 seront forcément transmis en trames de 1500 octets maximum.
Afin d'éviter la segmentation dans ce cas il vaut mieux produire des paquets UDP ne dépassant pas 1472 octets de payload

http://forum.macbidouille.com/lofive...hp/t64304.html

[ram-0000]

moi je dirais plutôt 1472 octets

1472, c'est la taille max d'une trame ethernet "standard" sur ethernet. Et encore, cette taille max diminue si tu es dans un tunnel GRE.

Sur fibre, c'est 4096, sur loopback, c'est "implementation dependant".

La taille max d'une trame de niveau 2 n'est pas le problème de la couche 4. En effet, la couche 4 repose sur IP qui lui, sait fragmenter et défragmenter et connait la taille max des trames du protocole d'en dessous.

Par contre, la taille d'une trame UDP est donnée dans le header UDP sur 2 octets (16 bits), donc la taille max des données utilisateur en UDP est de 65535 octets