Discussion :

[Aspic]

Bonjour,

j'ai un gros soucis : je tente de transferer un fichier par les sockets en asynchrome mais alors il envoi tellement vite les données dans la boucle que l'autre partie n'a meme pas le temps de recevoir !!! Et apres 10s ca fait une erreur disant que la file d'attente est saturée !

Pourtant le asynchrome devrait gerer ca, je comprends pas car des qu'il envois des données, la socket devrait attendre que l'autre partie recoivent bien ces données avant de continuer... non ?

Pourquoi ca fait ca ?

Merci

[cinemania]

et non justement, c'est ca la caractèristique d'une ligne asynchrone. Comme son nom l'indique elle est asynchrone, SOUS TOUS LES SENS du terme. Ca signifie qu'elle est asynchrone au sens du temps, elle intervient n'importe quand, mais elle est également asynchrone au niveau du réseau. En dehors des spécificités de TCP/IP, lorsque tu envoie en asynchrone des données, rien ne garantie qu'elles sont bien recue avant d'en envoyer d'autres, car tu n'attend plus les acknoledges et tot ou tard, si tu fait pas attention, tu sature les buffers.
Le seul moyen, intégrer dans ton protocole personnel un mécanisme d'acquiessement pour compenser. Ainsi tu n'envoie que N paquet sachant que tu n'explosera pas le buffer cible, et tu attend gentillement que l'autre renvoie un acquiessement, et zou tu recommence en masse. Certes tu perd un peu la notion d'asynchrone, mais ca dépend quelle notion te plait, asynchrone au niveau du temps ou au niveau du transfert !

il ya un moyen de contrer ce probleme, mais là la solution ne conviendra pas dans tous les cas. Il suffit d'associer la socket a un thread propre qui synchronise et centralise les accès à la socket des autres threads, en gros, tu émule toi meme l'asynchrone sur du synchrone ! L'avantage tu garde tous les avantage du mode synchrone, et cela permet de programmer assez facilement des modeles handshake (poignées de main) et du coté de ton appli, tu a une impression d'asynchrone ...
J'avais un probleme similaire, je l'ai réglé de cette facon, encore une fois, cette solution convenait à mon probleme, mais ne conviendra probablement pas à d'autres problemes. C'est à toi de voir

[Feanorin]

Bonjour,

Je suis en train de programmer un serveur en asynchrone et justement je me posais cette question.
Donc si je résume pour éviter que le buffer du poste réceptionneur il faut alors découper l'envoie par pacquet de la taille de buffer soit si je me rappelle 7ko.Et tu proposes de le découper par un thread propre a la socket d'envoie qui effectue la temporisation nécessaire pour que le poste réceptionneur est le temps de lire.
Soit calculer le nombre de trame envoyée et de le stopper en faisant un sleep ou attente d'une réponse client si elle arrive a saturation du buffer client.

Est ce que j'ai bien compris ?

Merci