Envoyé par ram-0000
Au fait, si tu veux être portable, utilise recv() et non read() pour tes sockets...
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
Sur un socket : send et recv ou read et write ?
Au fait, si tu veux être portable, utilise recv() et non read() pour tes sockets...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
La norme permet d'utiliser read() sur une socket, c'est donc tout à fait portable.
La norme POSIX permet d'utiliser read() sur une socket. Les sockets Berkeley reposent sur recv() et send(), garanties marcher sur des sockets.
read() ne marche que sur les systèmes où les sockets sont des descripteurs. En clair, pas sous Windows, alors que Windows respecte l'interface des sockets Berkeley.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Y'a pas de read() sous Windows... C'est recv().
Même débat que d'habitude, ce n'est pas à mon code d'être compatible avec Windows, mais à Windows d'être compatible POSIX, d'autre part, je suis presque sûr que cela est déjà implémenté avec cygwin.
Pourquoi ?
Il y a une API portable (sockets BSD), pourquoi ne pas l'utiliser ? De plus il y a un paramètre de plus qui pourrait avoir son rôle à jouer un jour ou l'autre... Utiliser read() et write() est un détournement de l'utilisation des sockets. Ce n'est pas la manière normale de procéder telle qu'elle a été conçue par BSD.
Une fois de plus, ce n'est pas parce que quelque chose est possible qu'elle est souhaitable.
P.S. Es-tu bien sûr que POSIX.1 définisse l'usage de read() et write() dans le cadre des sockets ?
Ici : http://www.opengroup.org/onlinepubs/.../socket.h.html
je ne vois pas de read() / write() ...
de même ici http://opengroup.org/onlinepubs/007908775/xsh/read.html
je ne vois pas de sockets.
Tu fais fausse route, les sockets Berkeley n'ont jamais été normalisé, ce n'est qu'une implémentation (reprise par Microsoft soit) mais pas une norme.
POSIX utilise le "fichier" comme abstraction, tout est fichier, si on regarde dans la norme on trouve :
alors que :pread, read - read from a file
...
If fildes refers to a socket, read() shall be equivalent to recv() with no flags set.
Donc sauf rare cas, pour être le plus générique possible, mieux vaut utiliser read() et write().recv - receive a message from a connected socket
Je ne comprends pas ton argument. La norme POSIX.1 dit clairement que les fonctions à utiliser pour les sockets sont recv() et send(). Je ne vois aucune raison valable d'utiliser autre chose que ce qui a été clairement défini et normalisé.
Cela est tout à fait normalisé, les fonctions que tu cites sont celles qui date des premiers BSD, POSIX ne fait que les reprendre, et ajoute la notion de généricité via les "fichiers".
2.10.7 Socket I/O Mode
The I/O mode of a socket is described by the O_NONBLOCK file status flag which pertains to the open file description for the socket. This flag is initially off when a socket is created, but may be set and cleared by the use of the F_SETFL command of the fcntl() function.
When the O_NONBLOCK flag is set, functions that would normally block until they are complete shall either return immediately with an error, or shall complete asynchronously to the execution of the calling process. Data transfer operations (the read(), write(), send(), and recv() functions) shall complete immediately, transfer only as much as is available, and then return without blocking, or return an error indicating that no transfer could be made without blocking. The connect() function initiates a connection and shall return without blocking when O_NONBLOCK is set; it shall return the error [EINPROGRESS] to indicate that the connection was initiated successfully, but that it has not yet completed.
Bonjour,
Pourquoi est-ce qu'il devrait être compatible avec une norme prévue pour les systèmes Unix ?
Où ?
J'ai déjà donné le lien (définition de <sys/socket.h>)
C'est malheureusement une idée reçue mais fausse. Le X de POSIX n'est là que pour rappeler le fait que la plupart des fonctions viennent du monde UNIX, mais il ne veut pas dire "pour UNIX", le plus important est Portable Operating system Interface, d'ailleurs, le commité de normalisation fait le maximum pour retirer ces ambiguïtés des noms, comme pour AF_UNIX qui est devenu AF_LOCAL, mais ce n'est pas toujours aussi simple.
Le lien que tu as donné est aussi un argument contre toi, il est par définition spécifique aux sockets, alors que read() et write ne le sont pas, elles peuvent être utilisé génériquement sur tout type de file descriptor. Si demain, pour une raison x ou y, ton file descriptor ne pointe plus sur une socket mais un pipe ou un fichier sur disque, tu es bon pour modifier ton code.
Argument irrecevable. Du moment qu'on a utilisé socket() pour ouvrir le flux, on a aucune raison d'utiliser autre chose que send() et recv(). Je ne comprends pas ton entêtement à vouloir écrire du code non portable.
et toi du code non générique!
Dans mon code, je remplace le socket() par un open() ou encore un pipe() peu importe, je passe le descripteur à une fonction qui va s'occuper des entrées sorties. Avec ta proposition, tu es bon pour réécrire la fonction qui s'occupe des I/O, avec la mienne, aucun problème. C'est d'ailleurs le genre de problématique que je dois souvent gérer au boulot, et heureusement que je reste générique (et portable).
Enfin, passer d'un fichier à un socket, ça ne voit pas tous les jours... Ou alors il y a de sérieux problèmes de spécifications !
Tu n'es pas un habitué d'UNIX, il n'y a pas besoin d'invoquer socket() pour avoir un descripteur qui pointe sur une socket, l'exemple le plus souvent rencontré est STDIN_FILENO, suivant comment ton programme est invoqué, ça peut être un fichier, un pipe, une socket, bref pratiquement tout. A partir de là, si on doit s'amuser à déterminer le type sous jacent puis invoquer un fonction d'entrée sortie différente en fonction de celui ci, on n'est pas sortie de l'auberge.
Et les tripatouillages qu'on peut faire sous Unix sont censés influencer notre manière de coder ? Je ne comprends pas.
Encore une fois, ce qui est possible n'est pas forcément ce qui est souhaitable.
@Emmanuel: Le débat ici, c'est entre la "généricité sous POSIX" et la "portabilité avec les systèmes non-POSIX respectant Berkeley" (en clair: Windows, et peut-être certains systèmes embarqués).
Sous POSIX, tu peux passer un socket à une fonction déjà existante qui ferait quelque chose sur un descripteur (ou à fdopen()).
Code C : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
Je comprends cet argument et reconnais sa validité, il s'agit ensuite de peser son importance face à celui de la compatibilité Windows.
Disons que si tu fais déjà quelque chose de spécifique à POSIX (du genre un select() avec un descripteur autre qu'un socket), tu n'es plus à ça près...
PS: Il serait intéressant de voir si la fonction Microsoft _open_osfhandle() marche sur les sockets. Car un socket n'est pas exactement un handle non plus (DuplicateHandle() marchotte dessus, mais pose des problèmes et son usage sur un socket est désormais déprécié).
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Je remonte ce thread pour conclure que non, ça ne marche pas:
WriteFile() sur un socket échoue avec ERROR_INVALID_PARAMETER (87), et write() utilise WriteFile()...
Un socket n'est donc pas assez "handle" pour être utilisé avec _open_osfhandle() & co...
De toute façon, il y aurait eu des problème à la fermeture, vu que close() appelle CloseHandle() et que CloseHandle() ne doit pas être utilisée sur les sockets...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Répondre avec citation
Partager