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().
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
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.
[^] # Re: Que fait B ?
Posté par grab06 . En réponse au message probleme d'utilisation de socket unix. É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.
[^] # Re: Que fait B ?
Posté par grab06 . En réponse au message probleme d'utilisation de socket unix. É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 . En réponse au message probleme d'utilisation de socket unix. É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: Demande de précision sur ton méchanisme
Posté par grab06 . En réponse au message probleme d'utilisation de socket unix. É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.