Bonjour,
je veux utiliser les socket unix pour que plusieurs processus independants (A,B,C) d'une meme chaine de traitement du signal communiquent entre eux des parametres. les donnees vont de A vers B puis vers C.
j'ai cree un serveur (D) par lequel passe tous les messages info I. pour envoyer une info I de A a B, A envoie l'info I a D qui la renvoie a B. Les infos sont independantes des data de la chaine de traitemnent du signal.
mon serveur de socket accepte les conections de A, B et C.
Un probleme particulier que j'ai est que :
- A arrive bien a envoyer une info I a D
- D envoie l'info I a B, B utilise un select() pour ne pas bloquer la chaine de traitement des donnees (recv() bloquant), mais le probleme c'est que B ne recoit pas l'info I tant qu'il y a du processing de data. Select() renvoie toujour 0. Par contre quand le processing de data se termine, select() renvoie bien l'indication que I est present.
Mes questions sont les suivantes: Y a t-il un mecanisme de priorite qui m'empeche de voir l'info I quand il y a du processing? Le select serait-il juste trop lent?
Remarque: quand je mets un sleep(1) avant le select(), je voit l'info I est presente. Mais dans la realite, je ne peux pas me permettre de mettre le sleep(1).
pouvez-vous m'aider?
merci.
# Demande de précision sur ton méchanisme
Posté par plr . Évalué à 2.
Bonjour,
Ce que tu appelles "processing de data", c'est bien l'algorithme de traitement du signal?
Peux-tu préciser quand ton "processing de data" commence: avant I? après I?
Peux-tu préciser le méchanisme que tu as mis en place pour que ton "processing de data" soit interrompu (temporairement) s'il a déjà commencé afin de recevoir I si ces infos sont prioritaires? D'ailleurs ce dernier point n'est pas clair: B doit-il traiter I durant le "processing de data" ou avant de commencer le "processing de data"?
L'algo simplifié (avec les différents threads) ou un diagramme temporel (même en ascii art) serait le bienvenu:
émission de I: _________________|-----|________________
processing data : ________|-------------------|__________
traitement de I: ___________________________________|-|__
a2g
[^] # Re: Demande de précision sur ton méchanisme
Posté par grab06 . Évalué à 1.
bonjour, merci pour la reponse.
oui le processing de data est bien un algorithme de traitement du signal.
Le processing de data commence avant I et est independant de I. Juste I va modifier a la volee les parametres de configuration du processing de data.
Le mecanisme en place est le suivant:
- B traite le flux de donnees provenant du stdin de facon continue. ces donnees sont extraites d'un fichier texte par un autre module A et les deux modules A et B sont pipes ensembles.
- Ce flux de donnees contient des entetes specifiques periodiques. Lorsqu'une entete est detectee, B appelle "select()" pour determner si un message I est arrive, auquel cas il le traite et ensuite continue le processing du flux de donnees. Le traitement de I est "cours" …
Entre temps, apres avoir discute des socket unix avec un ami, j'ai resolu mon probleme. celui-ci etait principalement lie au fait que je ne metrisait pas correctement ni mon flux d'entree (fichier texte), ni la gestion des sockets unix et du coup je n'etait pas capable d'avoir un interpretation correcte des logs que j'observais. en gros, mon probleme d'origine etait que je fermais la socket client a la fin du processing data et avant d'avoir recu I.
Merci pour votre aide. J'ai poste le message car etant debutant sur ce theme des socket unix qui ne me semble pas trivial, j'avais peur d'etre passe a cote de quelque chose de critique en rapport avec la gestion des priorites d'execution ou avec la perfomance attendue pour le traitement des socket unix.
# Que fait B ?
Posté par dyno partouzeur du centre . Évalué à 2.
Ce serait bien de décrire brièvement ce que B fait.
Quand exécute-t-il le select() ? Est-ce pendant le processus de traitement ? Y-a-t-il du multi-threading ?
Si les appels à select() sont dans le processus de traitement, Les appels à select() devraient détecter les données, sauf si le processus de traitement est bloqué en attente d'IO par exemple.
Si les appels à select() sont dans un autre process/thread, il faut que le process de traitement donne l'opportunité à l'autre process/thread de prendre la main via un sleep(0) régulier par exemple.
Et sinon, on dirait que tu nous demande de faire ton TP non ?
[^] # Re: Que fait B ?
Posté par grab06 . Évalué à 1. Dernière modification le 20 juin 2016 à 10:29.
Bonjour, j'apporte ici quelques informations supplementaires, j'ai deja repondu a un precedent message que vous pouvez consulter.
Le select() s'execute comme decrit dans le message precedent (suite a la detection d'un header dans le flux de donnees).
Il n'y a pas de muti-threading.
Le sujet de blocage en attente d'IO est un cas auquel je n'avais pas pense et je vais voir si cela peut poser un probleme global, merci pour cette remarque.
en fait, tous les clients (A,B,C) appellent select() et le serveur de socket aussi car c'est un systeme d'echange d'information I bi-directionnelle. Ma comprehension est que Linux va partager les resources entre tous les processus et ainsi donnera l'opportunite a chacun des processus d'appeler le select(). Il n'y a pas, a priori, de contraintes fortes de temps reel en ce qui concerne les messages I. cette contrainte de temps reel existe pour le traitement du flux de donnees et il est vrai qu'il faudra bien maitriser cet aspect des choses, mais un peu plus tard je pense.
Je voudrais bien etre encore etudiant … mais cela n'est plus le cas depuis longtemp. Non en fait, le temps n'est pas mon allie en ce moment et je dois chercher par moi meme la solution mais une fois mes pistes epuisees et que je n'ai toujours pas trouve la solution, je dois trouver de nouvelle pistes de recherche a l'exterieur pour ne pas rester bloque. C'est a ce moment que je me suis tourne vers le forum. Les socket unix sont quelque chose de nouveau pour moi.
Merci a vous pour l'interet et le temps que vous dedie aux autres
[^] # Re: Que fait B ?
Posté par dyno partouzeur du centre . Évalué à 2.
Du coup je pense que ton programme devrait avoir une structure du genre:
[^] # Re: Que fait B ?
Posté par grab06 . Évalué à 1.
oui tout a fait, mais c'est vrai que pour le moment, je n'avais pas inclu le stdin dans le select. Pour le moment, j'ai un "while(fread(&buf, sizeof(uint8_t), size, fin) == (size_t)size)", fin etant un FILE * redirige vers stdin. Mais effectiveent, le tout aura besoin d'un coup de nettoyage. Je precise que le code en est a un etat assez primaire pour le moment.
D'ailleurs, une ou deux petites choses me posent question sur les socket unix …
quand je cree (ouvre?) une socket, l'index commence toujours a 4 dans mon cas … je crois savoir que le 0 est pour le stdin, le 1 pour le stdout et le 2 pour le stderr … et le 3?
pouvez-vous me confirmer que les index retournes par socket() sont processus specifique? a chaque appel socket(), j'obtiens l'index 4 en premier pour le serveur et les clients. le seul element partage par le serveur et les clients etant le file descriptor lors du bind() et des connect().
merci a vous.
[^] # Re: Que fait B ?
Posté par grab06 . Évalué à 1.
bon … le 3 est alloue par le code lors de l'ouverture d'une socket comme prevu … il m'en manquait une que je ne verifiais pas.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.