Discussion :

[Ceylo]

Bonjour à tous,

Cela fait quelque jours que j'apprends à me servir des sockets pour réaliser deux mini-applications (client/serveur). J'utilise le mode de transfert TCP et mon serveur est "multi-threadé". Tout fonctionne nickel pour l'instant (je n'ai pas encore effectué les modifications nécessaires pour la portabilité sous Windows, donc pour l'instant c'est fonctionnel sous Linux et Mac OS X uniquement). J'aimerais cependant améliorer certains points et obtenir certaines informations.

J'ai remarqué (même si je sais que c'est normal) que lorsque j'utilise read() sur un flux, si rien n'est reçu le temps d'expiration est assez long. Je pensais me servir de setsockopt() mais les paramètres contrôlant ce temps d'expiration (SO_SNDTIMEO et SO_RCVTIMEO) ne sont pas modifiables d'après ce site de référence. Du coup la seule solution que je vois pour raccourcir moi-même ce temps serait de limiter le temps d'exécution de cette fonction grâce à SIGALRM, mais je ne trouve pas ça très propre. Y a-t-il une autre solution ?

Sinon je me demandais s'il y avait une différence entre utiliser read()/write() pour les flux sur le réseau et recv()/send(). J'ai vu que ces deux dernières fonctions peuvent prendre un 4e argument mais je ne m'en sers jamais. J'ai voulu l'utiliser une fois lorsque je ne comprenais pas pourquoi j'obtenais un SIGPIPE chez le serveur quand le client interrompait la connexion et l'argument MSG_NOSIGNAL m'aurait peut-être servi s'il existait sur mon OS... je n'ai pas trouvé la définition de la constante alors qu'elle devrait normalement être dans /usr/include/sys/socket.h il me semble. Donc pour en revenir à read()/write() et recv()/send(), y a-t-il une différence ?

Et enfin dernier point, est-il possible d'utiliser en simultané le même flux par deux threads distincts, l'un s'occupant de la lecture et l'autre de l'écriture ? Je doute très franchement que cela soit faisable mais je préfère m'en assurer. J'ai envisagé cette solution car je cherche à permettre à l'utilisateur de se servir du logiciel tout en ayant en fond la connexion et les envois/réceptions au serveur. Je trouve gênant de ne pas pouvoir envoyer d'informations simplement parce que je surveille aussi l'arrivée de requêtes ou d'autres informations. Je ne sais pas comment est organisé l'envoi et la réception des données sur ce genre de logiciels, donc si vous avez des avis sur ce point, je suis preneur .

Merci pour votre aide,
Spootnik

[granquet]

Y a-t-il une autre solution ?

oui, la séléction ou le polling
man select où man poll (et en plus c'est portable) ... et avec ça tu peux même te passer de threads
(faut que je finisse mon article moi )

Donc pour en revenir à read()/write() et recv()/send(), y a-t-il une différence ?

le dernier argument ne sers en général pas sur recv/send (fin, pas en AF_INET)
la différence majeure entre read/write et send/recv ... c'est que les 2 derniers font parti de l'API socket ... et sont donc plus approprié.
certains OS n'ont pas de fonction read/write fonctionnelle sur des sockets.
disons que read/write c'est la maniére unix/linux ... et recv/send c'est la maniére portable

est-il possible d'utiliser en simultané le même flux par deux threads distincts, l'un s'occupant de la lecture et l'autre de l'écriture ?

oui, c'est tout à fait possible, et sans aucune précaution particulière.

sinon, y'as un forum prévut pour les questions dans ce genre
developpement réseau

[Goundy]

Salut, je vais essayer de te répondre \o/

J'ai remarqué (même si je sais que c'est normal) que lorsque j'utilise read() sur un flux, si rien n'est reçu le temps d'expiration est assez long. Je pensais me servir de setsockopt() mais les paramètres contrôlant ce temps d'expiration (SO_SNDTIMEO et SO_RCVTIMEO) ne sont pas modifiables d'après ce site de référence. Du coup la seule solution que je vois pour raccourcir moi-même ce temps serait de limiter le temps d'exécution de cette fonction grâce à SIGALRM, mais je ne trouve pas ça très propre. Y a-t-il une autre solution ?

Pour ça rien ne vaut select . Tu sais régler un timeout comme bon te semble donc je pense que c'est ce que tu veux.
Et en effet, faire celà avec SIGALRM quand on a une sexy function comme select c'est pas très M. propre :>

Sinon je me demandais s'il y avait une différence entre utiliser read()/write() pour les flux sur le réseau et recv()/send(). J'ai vu que ces deux dernières fonctions peuvent prendre un 4e argument mais je ne m'en sers jamais. J'ai voulu l'utiliser une fois lorsque je ne comprenais pas pourquoi j'obtenais un SIGPIPE chez le serveur quand le client interrompait la connexion et l'argument MSG_NOSIGNAL m'aurait peut-être servi s'il existait sur mon OS... je n'ai pas trouvé la définition de la constante alors qu'elle devrait normalement être dans /usr/include/sys/socket.h il me semble. Donc pour en revenir à read()/write() et recv()/send(), y a-t-il une différence ?

Je pense que la seule différence réside dans le fait que send/recv sont "mieux adaptées" aux Léctures/Ecritures sur le réseau, j'entend par là le fait d'avoir un flag en plus, par rapport à read/write, qui permet de gérer certains aspects de la socket, comme le oob et tout ça.
Personnellement j'utilise toujours send/recv mais je vois souvent des read/write partout

Et enfin dernier point, est-il possible d'utiliser en simultané le même flux par deux threads distincts, l'un s'occupant de la lecture et l'autre de l'écriture ? Je doute très franchement que cela soit faisable mais je préfère m'en assurer. J'ai envisagé cette solution car je cherche à permettre à l'utilisateur de se servir du logiciel tout en ayant en fond la connexion et les envois/réceptions au serveur. Je trouve gênant de ne pas pouvoir envoyer d'informations simplement parce que je surveille aussi l'arrivée de requêtes ou d'autres informations. Je ne sais pas comment est organisé l'envoi et la réception des données sur ce genre de logiciels, donc si vous avez des avis sur ce point, je suis preneur .

Biensûr que si, c'est tout à fait possible. Dans un socket, tu as, si j'ose dire, deux sorte de "canaux" celui de lécture et celui d'écriture.
Le seul truc c'est que pour la lécture y'a pas de soucis N threads peuvent lire dessus, par contre pour l'écriture, si tu envisages avoir un facteur externe exécutant une écriture sur la socket pense à mettre en place une mutex.
Mais si tu n'as qu'un seul thread qui écrit tu peux y aller les yeux fermer.

Voilà, si je me suis gouré quelque part qu'on me corrige

Edit: GRILLED

[Ceylo]

oui, la séléction ou le polling
man select où man poll (et en plus c'est portable) ... et avec ça tu peux même te passer de threads

Code Terminal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
man poll
No manual entry for poll

par contre pour select j'ai plein d'infos et ça à l'air de correspondre merveilleusement bien à ce que je cherchais .

le dernier argument ne sers en général pas sur recv/send (fin, pas en AF_INET)
la différence majeure entre read/write et send/recv ... c'est que les 2 derniers font parti de l'API socket ... et sont donc plus approprié.
certains OS n'ont pas de fonction read/write fonctionnelle sur des sockets.
disons que read/write c'est la maniére unix/linux ... et recv/send c'est la maniére portable

C'est noté !

oui, c'est tout à fait possible, et sans aucune précaution particulière.

Cool...

Et pour le forum sur le réseau je sens que je vais m'en imbiber , merci pour toutes ces infos.

Je pense que la seule différence réside dans le fait que send/recv sont "mieux adaptées" aux Léctures/Ecritures sur le réseau, j'entend par là le fait d'avoir un flag en plus, par rapport à read/write, qui permet de gérer certains aspects de la socket, comme le oob et tout ça.

oob ?

Biensûr que si, c'est tout à fait possible. Dans un socket, tu as, si j'ose dire, deux sorte de "canaux" celui de lécture et celui d'écriture.
Le seul truc c'est que pour la lécture y'a pas de soucis N threads peuvent lire dessus, par contre pour l'écriture, si tu envisages avoir un facteur externe exécutant une écriture sur la socket pense à mettre en place une mutex.
Mais si tu n'as qu'un seul thread qui écrit tu peux y aller les yeux fermer.

Je n'aurai qu'une seule écriture à la fois donc je suis tranquille .

Sinon merci pour ton aide (même grillé).

Je ne pensais pas avoir toutes les réponses à mes problèmes aussi vite, quand je pense que ça fait 3 jours que je demandais de l'aide sur un autre forum ... sans aucune réponse (enfin c'est plutôt un forum pour débutants, je saurai où poster pour des questions plus techniques à l'avenir ).

[Goundy]

http://www.linux-kheops.com/doc/man/...n2/poll.2.html

[Emmanuel Delahaye]

http://www.linux-kheops.com/doc/man/...n2/poll.2.html

poll() est plutôt Linux. select(), plutôt UNIX, et pselect() est POSIX.1.

En fait, les 3 sont POSIX.1

http://www.opengroup.org/onlinepubs/...ions/poll.html
http://www.opengroup.org/onlinepubs/...ns/select.html
http://www.opengroup.org/onlinepubs/...s/pselect.html

après, chaque implémentation fait ce qu'elle veut...

[clampin]

Pour Mac Os X j'ai trouvé ça :

http://developer.apple.com/documenta...n2/poll.2.html

[corrector]

Bien sûr que si, c'est tout à fait possible. Dans un socket, tu as, si j'ose dire, deux sorte de "canaux" celui de lecture et celui d'écriture.

Oui, mais sont-ils parfaitement indépendants?

Le seul truc c'est que pour la lecture y'a pas de soucis N threads peuvent lire dessus,

Tu veux dire : plusieurs threads peuvent lire sur la même socket en même temps, sans synchronisation d'aucune forme?

[Emmanuel Delahaye]

Oui, mais sont-ils parfaitement indépendants?

Oui, c'est le principe du 'full duplex'.

C'est au-dessus qu'éventuellement un protocole fait la régulation de flux avec des acquittements...

Tu veux dire : plusieurs threads peuvent lire sur la même socket en même temps, sans synchronisation d'aucune forme?

Non.

Dans un serveur, il y a un socket serveur et un socket par client. En principe, il y a un thread par client qui utilise évidemment son socket client.

Il peut y avoir d'autres architectures basées sur select(), voire sur une combinaison thread+select()....

[corrector]

Oui, c'est le principe du 'full duplex'.

Mais si les deux threads veulent lire l'état d'erreur de la socket avec getsockopt (... SO_ERROR ...) ils vont interférer, non?