quelqu'un serait -il  comment on fait pour programmer les sockets de façon simple c'est pour faire un petit logiciel de chat pour débuter.
merci

 
ça veux dire quoi?
 
 
sinon sans blaguer il n'y a pas de lib de socket dans le standard c++, va falloir chercher dans des libs externes.

Que t'as intéret à mapper sur les streams de C++ ou de faire en sorte que Taz ne soit jamais au courant.

quel environnement ?
 
sis Linux, GNUCommonC++, Socket++, etc

franchement vous etes gerbant, les répondeurs plus que les posteurs.
 
le gars demande a faire de la socket pour apprendre, répondez lui ce qu'il veut entendre : comment faire des socket, qu'il soit sur nux ou win, c'est 100% pareil, en C ou C++.

Si t'es pas jouasse tu peux te casser.
 
On n'a été gentil je trouve car l'unique réelle réponse est : "google est ton ami, comme pour 60% des questions de ce forum".
http://www.google.fr/search?q=C%2B [...] 8&oe=utf-8

et en ce qui concerne les transferts de grande taille en tcp ???

non justement ça l'est pas du tout, qu'il soit sous win ou sous un unix, y a des différences, s'il fait du C, qu'il fasse en C, s'il fait du C++ qu'il fasse en C++ .|

tu balances dans la socket sans t'occuper de la taille.
J'ai lu vite fait hier qu'on pouvait régler certains paramètres car TCP n'est pas très bien réglé par défaut pour les gros transfert, mais j'ai la flemme de rechercher le post (il était sur comp.lang.ada).

oui, on peut, moi non plus je retrouve plus, en fait ça consiste à n'émettre le paquet que quand il est plein (ou un flush)

Mais à quoi peut bien servir ce forum si toutes les réponses aux questions sont sur googles ?
 
L'avantage d'un forum c'est de pouvoir poser ses questions aussi bêtes qu'elles soient et d'en débatre pour rentrer dans le sujet en profondeur.
 
Et puis niveau topics de la section C++ c'est plutôt mord, donc ca gène pas outre mesure je trouve.
 
Maintenant, le truc chiant c'est les topics doubles.

Elles n'y sont pas toutes. Mais en général, quand elles n'y sont pas, personne ne sait sur ce forum et il faut aller sur des ml ou des newsgroups spécialisés.
 
Ce forum il sert à :  
1) apprendre à se servir de google
2) déconner sur blabla

 
les fonctions socket de berkeley sont standard, et si le prog est fait correctement il compilera sous linux, win, bsd, etc.
 
et c'est une lib plutot en C, avec des char* et plein de trucs dans ce genre. si je fais du c++ j'ai pas le droit de l'utiliser ? je fais comment, je m'abrutise a faire une classe spéciale socket ? (d'ailleurs aucune trouvée sur le net ne marche correctement)
 

 
c'est quoi un paquet "plein" ? "vide" je vois, mais plein la je saisis mal.
sinon pour envoyer des trucs de grosse taille (> 100 Ko par ex), je conseillerais quand meme de fragmenter les paquets (1, 2, 4 ou 8 Ko), ne serait ce que pour avoir un léger controle sur le transfert.

1) je pense pas qu'une classe compatible stream soit abrutissante, du moins bien moins que les char*
2) c'est un paquet dont la charge utile est maximale.
3) pour les trucs de grosse taille, remplis tes paquets .| la couche IP se charge de faire se qu'il faut pour l'acheminement, pas la peine de fragmenter à la main (l'effet serait d'ailleurs désastreux)

1) ca l'est du moment que les fonctions de base en C marchent suffisamment bien, en faire une belle classe (qui marcherait peut-etre moins bien) servirait juste a se dire "ouais, moi je fais du C++"
2) je vois toujours pas... si tu te referes aux 1400 octets (ou 1200, me souvien plus) qui sont en theorie la taille des paquets envoyés, la ok.
3) me vois tres mal envoyer 20 Mo d'un coup dans ma socket, elle risque de pas aimer. Fragmenter peut paraitre con vu que la couche ip fragmente deja, mais ce qui serait desastreux ca serait de penser que le transfert va marcher nickel. en coupant un fichier en petit paquets de 8 Ko, on a un controle total sur le transfert, d'ailleurs y a qu'a voir comment sont écrit les ftp...

pourtant elle va aimer

si on fragmente c'est poura voir un controle d'erreur sur l'ecriture pour pas avoir à reprendre depuis le debut, etc

gni ? c'est TCP qui est sensé ce démerder de ça au niveau réseau (retransmition comprise).

oui et alors ? tu fais ton write(socket en C, et comme sut veux gérer un peu les erreurs, tu regardes son code de retour qui t'indique combien on était écrit. si ça foire, tu réessaies. non ?

honnêtement (je trouve que la question méritait d'être posée)
Je ne vois que 3 cas où réessayer, le cas d'interruption par un signal, celui d'un bourrage du buffer de sortie et celui de EAGAIN.

Mais c'est un problème applicatif et n'a rien à voir avec la liaison TCP qui est en dessous tant qu'aucun flush n'est lancé.
 
En fait je viens de comprendre ta remarque initiale, tu parlais de l'écriture dans la socket et de la transaction associée à tout write, pas de la connection réseau (auquel cas "fragmenter" voudrait au pire dire "flush" au mieux dire "close" ).

voilà