Discussion :

[damien99]

Salut,

J'essaye de mettre au point un transfert de fichier via des sockets, pour le moment la taille maximum pouvant �tre transmise est de 250octets. Bien sur �a na pas beaucoup d'interet, c'est pour cela que je souhaite l'am�liorer.

Pour de plus gros fichiers, je pensais les couper en plusieurs petits morceaux pour les envoyer et je me demandait comme faire pour enoyer les paquets.

Si on envoye tout en un seul coup, les messages risquent de s'entasser chez le destinataire surtout si sa connexion est moins rapide, et la je voudrait bien savoir ce qu'il se passe...
Faut t'il attendre une r�ponse du destinataire apr�s chaque paquet envoy�s et envoyer les paquets 1 � 1 (dans ce cas �a risue de ne pas �tre trop rapide surtout si le ping est important)

En fait je voudrait savoir quelle est la m�tode � adopter pour envoyer une grande quantit� de donn�es.

Merci de me conseiller

[OjBarbare]

si tu dispose d'une memoire tr� grande (un buffer devra contenir le fichier), tu peux tout envoyer d'un coup, TCP.IP se chargera de la segmentation.
La bonne technique est biensur de faire toi meme une segmentation pour ne pas saturer la memoire de ton pc. Tu peux par exemple utiliser un buffer de 1ko ou 10ko. TCP/IP se chargera du reste, tu n'as qu'a envoyer les donn�es (avec un marqueur de d�but et de fin)

jespere avoir �t� clair

[damien99]

Merci de ta r�ponse OjBarbare ,mais je voudrait savoir si dans un cas extr�me cette solution marche toujours.

Par exemple on envoi des donn�es avec une connexion tr�s rapide (100Ko/sec.) et du cot� du client (celui qui re�oit le fichier) on a une connexion tr�s lente (4Ko/sec. : vitesse d'un 56K).
Si avec cette configuration on envoi un tr�s gros fichier (de 200Mo par exemple), au bout d'une qurantaine de minute l'�m�tteur aura fini l'envoi et le client aura re�u seulement quelques M�gaOctets (eh oui c'est pas rapide un 56K ) on va se retrouver avec 190Mo dans le r�seau TCP/IP.

Les derniers paquets arriverons t'il � destination : Les FAI ne feraient t'ils pas une limitation dans ce cas pour emp�cher la surcharge du r�seaux :

[OjBarbare]

absolument pas, TCP/IP gere les envois de tel sorte que l'emetteur soit syncroniser avec le recepteur : il n'y aura jamais 190Mo qui se promenent sur le reso, �a voudrait dire qu'ils sont stock� sur un routeur....
quoi qu'il en soit, tu n'as pas � t'occuper de ce genre de probleme. Du point de vue du developpeur, l'emetteur envoi, le recepteur re�oi, c'est tout.

[damien99]

ok mais alors �a s'entasse dans la RAM ? A partir du moment ou �a a �t� envoy� c'est bien stock� quelque part non?
Peut connaitre la taille des donn�es qui se trouve dans le tampon d'�mission (�a pourrait �tre bien pour optimiser le programme)

PS: je suis en mode conn�ct� je sais pas si �a se passe de la m�me fa�on
EDIT: je voulait dire non-bloquant (�videmant que je suis en mode connect� )

[OjBarbare]

en effet c'est le petit d�tail qui a son importance
l� jme souviens plus comment c'est gerer dans ce cas l�... je pense que c'est empil� dans la ram

[damien99]

Quelqu'un connaitrai t'il un cours sur les TCP/IP : parce des qu'on recherche des truc qui sortent un peu de l'ordinaire c'est pas tr�s facile � trouver de la doc sur le net.

[damien99]

J'ai trouv� �a comme info :

"L'�criture sur la socket est bloquante uniquement si le tampon �mission
est plein (si la socket a �t� d�clar�e non bloquante, l'�criture retourne
une erreur)."

"Un m�canisme de rangement dans des m�moires tampons est mis en oeuvre par les sockets TCP. Pour chaque connexion, il existe un tampon d��mission (de 4 Ko � 16 Ko environ) et un tampon de r�ception. "

Source : http://www-gtr.iutv.univ-paris13.fr/...teme/TPudp.rtf

Donc apparement le truc d'envoyer tout le fichier d'un coup serait impossible compte tenu de la capacit� du tampon.

: Quelqu'un ne connaitrait pas une fonction qui indique la taille qu'il reste de libre dans le tampon de reception

[damien99]

Je voudrai savoir si j'envoi un paquet de 65535 octets, et que j'envoi juste apr�s* un autre de 512 octects,
le paquet de 65535 octets va t'il �tre envoy� dans sa totalit� avant celui de 512 octets.

*:avant que le paquet de 65535 octets soit fini d'envoyer

Ca m'arrangerai que le paquet de 512 octets soit prioritaire, comment faire ?