[résolu] Socket et process

Programmation
#1

Alors, j’ai mis en place le socket entre le client et le serveur, mais ça bloque le programme. Comment faire en sorte que le socket tourne en arrière plan de façon à ce que l’utilisateur puisse continuer à utiliser l’application ?? (Problème classique des sockets j’imagine)

#2

Euh, si tu parles de shell, tu peux balancer une commande en tache de fond avec &
Si tu veux que l’execution soit immortelle: nohup
Mais ça m’etonne que tu ne connaisses pas ça, dc ca ne doit pas être ce que tu cherches.

#3

La solution est d’utiliser les threads pour tes sockets mais comme je ne sais pas dans quel langage tu programme difficile de te donner des bons liens correspondant. En voici quand meme quelques un pour le C et pour Java :slightly_smiling:

mapage.noos.fr/emdel/pthreads.htm
java.sun.com/j2se/1.4.2/docs/api … hread.html
www-gtr.iutv.univ-paris13.fr/Cou … hread.html

#4

C’est en C (C C bien). En fait, avec la fonction socket, le serveur, comme le client, bloque sur la connexion. Je veux dire, le programme établi la connexion, et se focalise uniquement dessus. Impossible de quitter le programme par exemple. Les threads… ouaip, je pensais pouvoir les éviter. Merci Ash pour les liens. J’m’en vais les visiter.

#5

La solution, ce n’est certainement pas les threads.

La solution, c’est d’utiliser select ou poll, et peut être d’utiliser des socket non bloquantes.
A+

#6

[quote=“ed”]La solution, ce n’est certainement pas les threads.

La solution, c’est d’utiliser select ou poll, et peut être d’utiliser des socket non bloquantes.
A+[/quote]IL est gentil.
TU pourrais être un peu moins laconique: même moi ( :laughing: ) je ne sais pas ce que sont select et poll, et trouver des infos dans un moteur avec ces mots clés là :wink: …
Quand au sockets non bloquantes, si quelqu’un ici avait la moindre idée de comment le faire, on l’aurait indiqué à Damsss…

#7

Bon, la piste des sockets non bloquantes est immédiatement exploitable:
gnosis.cx/publish/programming/sockets.html

#8

En voyant le message d’ed, j’ai repris quelques recherches sur select et poll. voir laissus.fr/cours/node17.html
et plus précisement
laissus.fr/cours/node20.html … 0000000000
laissus.fr/cours/node20.html … 0000000000

#9

Mon gode (comme dise les aut’), on a reveillé un chercheur qui reprend ses recherches.
Ash: je ne te savais pas cette qualité.

#10

[quote=“MattOTop”][quote=“ed”]La solution, ce n’est certainement pas les threads.

La solution, c’est d’utiliser select ou poll, et peut être d’utiliser des socket non bloquantes.
A+[/quote]IL est gentil.
TU pourrais être un peu moins laconique: même moi ( :laughing: ) je ne sais pas ce que sont select et poll, et trouver des infos dans un moteur avec ces mots clés là :wink: …
Quand au sockets non bloquantes, si quelqu’un ici avait la moindre idée de comment le faire, on l’aurait indiqué à Damsss…[/quote]

Faut pas pousser les mecs, merde, on fais du C ou quoi la ?

man 2 socket
man 7 socket

       On peut faire des entrées-sorties non-bloquantes  sur  les  sockets  en
       fixant  l'attribut  O_NONBLOCK  sur  le  descripteur  de la socket avec
       fcntl(2).  Ensuite toutes les opérations qui devraient normalement blo-
       quer se terminent immédiatement avec l'erreur EAGAIN (l'opération devra
       être  retentée  ultérieurement).   connect(2)  renverra  l'erreur  EIN-
       PROGRESS.   L'utilisateur  peut  alors  attendre divers événements avec
       poll(2) ou select(2).

Faudrais peut être aprendre a se servir de la documentation …

Quant a poll ou select

man 2 poll
man 2 select

A+

#11

ed: :blush:
Et dire que je suis le premier à rappeler que l’essentiel de la doc systême en C est dans le man…

#12

:stuck_out_tongue:

#13

[quote=“MattOTop”]Mon gode (comme dise les aut’), on a reveillé un chercheur qui reprend ses recherches.
Ash: je ne te savais pas cette qualité.[/quote]Ben en fait ed a soulevé un point que je ne connaissais pas et comme je n’aime pas ne pas savoir :smiley:

#14

Merci, c’est sympa. Mais j’ai une erreur de segmentation lorsque le serveur udp veut faire la connexion.
Extrait de code :

//connexion udp serveur 

 if ((sock = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP))<0) {
                        printf ("impossible d'ouvrir le socket\n");exit(1);
                }

        //      bzero((char*) &serv_addr, sizeof(serv_addr));
                serv_addr.sin_family       = PF_INET;
                serv_addr.sin_addr.s_addr  = htonl(INADDR_ANY);
                serv_addr.sin_port         = htons(3888);
          
               if ((bind(sock,(struct sockaddr*)&serv_addr,sizeof(serv_addr)))<0){
                        printf ("impossible de faire le bind\n");exit(1);
                }

                /* écoute sur le port du socket */
                listen(sock,5);
[...]

Ca plante à l’amorçage, avant même le premier printf.
L’erreur est :

C’est tout ce que renvoie la console. Et le programme quitte. :confused:
C’est comme si il n’arrivait pas à choper le port UDP.
Dans le fichier d’entête :
int sock;
struct sockaddr_in cli_addr,serv_addr;

#15

tu as mis un ulimit convenable pour génèrer un core et l’analyser avec un debugger ? Ou même, tu as essayé de tracer ton pgm pas à pas ?

#16

Essaye en remplaçant IPPROTO_UDP par 0 pour voir…

Mais une erreur de segmentation signifie plutôt que la douille est bien crée mais que serv_addr n’a pas été alloué. D’où le segfault… La structure a bien été créee (j’imagine que tu as vérifié)…

#17

Bon ben ok, aparament, vous avez jamais fais de C !!

Bon, commençons par le début:

apt-get install gdb valgrind

compilation de votre programme avec les symboles de debug:

gcc -ggdb programme.c -o programme

Lancement de gdb:

gdb ./programme

r [arguments si il en existe]

le programme se lance. Paf segfault.

backtrace

Collez nous le backtrace, ainsi que le source COMPLET et a cette UNIQUE condition, nous seront en mesure de t’aider.

#18

Avec le debugger, j’ai trouvé l’erreur, merci Ed. En fait, ça venait du strlen, qui ne pouvait pas trouver la taille du buffer, puisque celui-ci était un pointeur. Je l’ai changé en char[MAXCHAR], et ça passe.

Du coup, je pense qu’en continuant à debugger, ça devrait aller à present. Pour le code source entier, je ne peux pas le mettre pour l’instant, ce ne serait pas trés fair-play vis-à-vis de mes camarades de classe (projet noté).

#19

Envoi le en mp je suis interressé :slightly_smiling:

#20

[quote=“Damsss”]Avec le debugger, j’ai trouvé l’erreur, merci Ed. En fait, ça venait du strlen, qui ne pouvait pas trouver la taille du buffer, puisque celui-ci était un pointeur. Je l’ai changé en char[MAXCHAR], et ça passe.

Du coup, je pense qu’en continuant à debugger, ça devrait aller à present. Pour le code source entier, je ne peux pas le mettre pour l’instant, ce ne serait pas trés fair-play vis-à-vis de mes camarades de classe (projet noté).[/quote]

tu aurais pu faire un mystring = malloc(MAXCHAR+1); memset(mystring, 0, MAXCHAR+1);

Puis un free bien placé :slightly_smiling:

Mais ce n’étais qu’une autre façon de faire… Bravo pour la remarque a propos de tes camarades, je comprends mieux pourquoi j’avais pas le source :slightly_smiling:

Bon courage pour la suite,