En fait ce qui me pose un probleme c'est que data et sent sont de types differents et que tu les additionne ...
Sinon pour la question sur les string , laisse tomber, encore une inpeptie sortie
de mon petit cerveau fatigué ...
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
En fait ce qui me pose un probleme c'est que data et sent sont de types differents et que tu les additionne ...
Sinon pour la question sur les string , laisse tomber, encore une inpeptie sortie
de mon petit cerveau fatigué ...
Data est un pointeur sur char : lui additionner un entier fera se déplacer le pointeur d'autant d'octets (c'est l'arithmétique des pointeurs).En fait ce qui me pose un probleme c'est que data et sent sont de types differents et que tu les additionne ...
Ah mes non d'accord en fait je suis c** aujourd'hui !!
Data c'est un pointeur qui pointe vers le premier element du tableau
char data[] non ??
A ce moment la on peut alors lui ajouter sent pour que sa pointe vers le debut
données pas encore envoyées ...
Enfin je suis peut etre entrin de m'enfoncer encore plus la ..... Sacré sockets ...
Ok ok bon ba j'ai enfin compris , un grand merci pour ton aide et surtout pour ta patiente, pasqu'avec moi il en vaut une bonne dose ...
des tubes avec des sockets... quel cauchemard!
send prend en paramètre un descripteur, donc la socket correspondante. c'est quoi ce data+sent?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
ps: quelle différence pour un réseau tcp mode connecté entre [read & write] et [recv & send]?
j'ai toujours utilisé pour du tcp write et read. et pour l'udp recvfrom et sendto.
et au fait qu'est ce que fait une discussion sur des sockets dans la partie c++ (meme si c'est codé en c++/c)? ya une partie developpement réseau!
Peu importe l'ordre ou la place des paramètres (je n'en suis pas encore à les connaître par coeur), ici on parle juste du pointeur vers les données et leur taille. J'aurais dû placer des "..." de chaque côté pour éviter que les pinailleurs ne me tombent dessus...send prend en paramètre un descripteur, donc la socket correspondante. c'est quoi ce data+sent?
S'assurer qu'on ne sera jamais tenté de porter le code vers les sockets Windows, peut-être ?ps: quelle différence pour un réseau tcp mode connecté entre [read & write] et [recv & send]?
A part ça il n'y a sans doute aucune différence, tout étant géré sous forme de descripteur de fichier sous Unix.
C'est vrai que c'est limite, mais bon comme on intercale quelques questions de C++, et que ça ne gêne pas de laisser quelques questions de réseau ici, il est préférable de laisser le sujet ici.et au fait qu'est ce que fait une discussion sur des sockets dans la partie c++ (meme si c'est codé en c++/c)? ya une partie developpement réseau!
et c'est laquelle qui permet la portabilité vers les sockets windows?
et désolé de pinailler mais j'ai pas compris, donc j'ai demandé précision ^^
merci de ta rép, mais faut penser que des gens postent dans la partie développement réseau qui est bien moins visitée que celle de c++. (j'en suis la preuve)
votre pinailleur en chef :p
C'est send()+recv() qui marche sur tous les sockets, quelle que soit leur nature sous-jacente.
read()/write() ne marche que sur des descripteurs, donc ne marche avec les sockets que là où les sockets sont des descripteurs (à savoir: Tout système unixoïde/POSIX, mais sûrement pas Win32).
N'y a t-til pas un avantage de read/write par rapport a send/recv?
a part le nombre d'arguments qui sont moins nombreux dasn read/write!
j'utilise read write en principe mais bon...
Le résultat sera le même, quel genre d'avantage voudrais-tu avoir ?N'y a t-til pas un avantage de read/write par rapport a send/recv?
Bah... Il faut juste rajouter un flag (qu'on met toujours à 0)a part le nombre d'arguments qui sont moins nombreux dasn read/write!
Non, en fait je fais des projets sur des sockets en tcp, et j'utilise read/write.
et je me demandais comment je pourrais justifier l'utilisation de read/write par rapport a rcv/send.
c'est tout!
read et rcv sont tous deux bloquantes?
Oui, il me semble que c'est sur le socket (ou plus généralement sur le descripteur de fichier) qu'il faut paramétrer la notion de blocage / non-blocage. Comme ça peut se faire pour l'entrée standard par exemple, puisque c'est aussi un fichier (toujours sous Unix évidemment).read et rcv sont tous deux bloquantes?
lun4t1k :
- Inutile de chercher, tu ne peux.
- Oui. Comme dit par Laurent, ça se paramètre sur le socket (ou le descripteur de fichier sous nux).
La fonction doit être ioctl() sous nux, ioctlsocket() sous Windows.
merci a vous!
autre question: un client envoie 5000 caracteres (ou octets).
le buffer coté server est suffisament grand pour tout accueillir.
cependant je ne recois pas tout d'un coup.
apres chaque read j'affiche le nb d'octets recus, et de tps en tps l'envoi ne se fait pas qu'en une fois. (en tcp mode connecté toujours)
le nb de carctères envoyés par le client est aléatoire et s'échelonne de 1000 a 10000. (souvent aux alentours des 3000)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
d'ou ca pourrait venir? sachant que le client n'envoi qu'une fois et que le serveur ne recoit qu'une fois!
pourquoi read se bloque?
ps: c'est la derneire question! ^^
Les sockets en mode connecté on toute lattitude pour découper leurs packets quand bon leur semble, cela fait partie du standard.
La seule chose dont tu peux être sur, c'est l'absence de perte de packets, ainsi que l'ordre d'arrivé qui est toujours respecté.
D'ou cela vient ? Surement des différents buffeurs dans la chaîne réseau (os, cartes, routeurs, ...) qui choisisent la meilleure taille de packet pour être le plus rapide possible.
D'ailleurs la taille des frames est paramétrable sur les cartes réseau, cependant il n'existe pas à ma connaissance de formule exacte pour connaître la taille de "3000" que tu indiques.
Pourquoi read se bloque ? Laurent t'as donné la réponse => fonction ioctlsocket ...
Par contre je suis désolé je vais en contredire certains, mais j'ai bien peur que ce soit faux que d'affirmer que recv est portable sur windows.
Source: Prof de réseau!
recv n'est pas plus portable que les autres fonctions ; simplement dans 90% des cas ce sont juste des différences de types (int / unsigned int, SOCKET / int, ...) et qui compilent tout de même sur les deux OS sans modification.
Je confirme que la fonction recv existe bel et bien sur Win32.
En fait ce n'est autre qu'un alias d'une des fonctions "natives" de Windows sur les sockets. Mais les 2 fonctionnent bien.
En règle générale Windows fournit toujours de quoi être compatible avec les sockets Berkeley, il reste juste quelques lourdeurs dûes à certaines différences entre Windows et les Unix. Quoiqu'il en soit faire une interface portable par dessus tout ça n'a rien de bien compliqué.
En gros il n'y a pas lieu de dire que rcv & send sont portables vers win! (vocabulairement)
La seule différence que je vois entre read et rcv c'est l'absence du flag sur read.
(flag que je laisse souvent à 0 pour mes utilisations...)
Ok merci à vous.
Bonne soirée à tous!
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager