Transfert de fichier via sockets...

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.

:arrow: 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...
:arrow: 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 :)

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 :)

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 :?:

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.

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é :D )

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

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.

J'ai trouvé ça comme info :

:arrow: "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)."

:arrow: "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

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 ?