bonjour,
je fais une application serveur tcp .
dans la doc il est marqué que la commande "accept" est bloquante et
c'est- ce qui se passe . Mais on peut mettre le socket en non-blocking
mais je n'ai pas vu comment faire ? Autrement un lien avec un exemple
simple ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
l'indien
On Tue, 28 Jun 2005 08:41:12 +0200, Fred Kap wrote:
bonjour, je fais une application serveur tcp . dans la doc il est marqué que la commande "accept" est bloquante et c'est- ce qui se passe . Mais on peut mettre le socket en non-blocking mais je n'ai pas vu comment faire ? Autrement un lien avec un exemple simple ?
Il y a 2 méthodes: - utiliser select: int check_connection (int sock) { struct timeval to; fd_set fds; int r;
FD_ZERO(&fds); FD_SET(sock, &fds); to.sec = 0; to.msec = TIMEOUT; r = select(sock + 1, &fds, NULL, NULL, &to); if (r > 0) { r = accept(...); }
return r; }
- utiliser fcntl pour passer la socket en mode non bloquant (flag O_NONBLOCK)
Mais tout celà est dans le man _et_ dans l'info, tu n'as pas du beaucoup chercher...
On Tue, 28 Jun 2005 08:41:12 +0200, Fred Kap wrote:
bonjour,
je fais une application serveur tcp .
dans la doc il est marqué que la commande "accept" est bloquante et
c'est- ce qui se passe . Mais on peut mettre le socket en non-blocking
mais je n'ai pas vu comment faire ? Autrement un lien avec un exemple
simple ?
Il y a 2 méthodes:
- utiliser select:
int check_connection (int sock)
{
struct timeval to;
fd_set fds;
int r;
FD_ZERO(&fds);
FD_SET(sock, &fds);
to.sec = 0;
to.msec = TIMEOUT;
r = select(sock + 1, &fds, NULL, NULL, &to);
if (r > 0) {
r = accept(...);
}
return r;
}
- utiliser fcntl pour passer la socket en mode non bloquant (flag
O_NONBLOCK)
Mais tout celà est dans le man _et_ dans l'info, tu n'as pas du beaucoup
chercher...
On Tue, 28 Jun 2005 08:41:12 +0200, Fred Kap wrote:
bonjour, je fais une application serveur tcp . dans la doc il est marqué que la commande "accept" est bloquante et c'est- ce qui se passe . Mais on peut mettre le socket en non-blocking mais je n'ai pas vu comment faire ? Autrement un lien avec un exemple simple ?
Il y a 2 méthodes: - utiliser select: int check_connection (int sock) { struct timeval to; fd_set fds; int r;
FD_ZERO(&fds); FD_SET(sock, &fds); to.sec = 0; to.msec = TIMEOUT; r = select(sock + 1, &fds, NULL, NULL, &to); if (r > 0) { r = accept(...); }
return r; }
- utiliser fcntl pour passer la socket en mode non bloquant (flag O_NONBLOCK)
Mais tout celà est dans le man _et_ dans l'info, tu n'as pas du beaucoup chercher...
Nicolas George
l'indien wrote in message :
- utiliser select:
À part si la compatibilité avec les Unix antédiluviens est nécessaire, poll vaut mieux (ou epoll si on a beaucoup de fd et que les performances sont plus importantes que la portabilité, ou pselect s'il y a des signaux à démasquer atomiquement) que select.
int check_connection (int sock)
Attention, ce genre de code incite à faire du polling. Quand on veut gérer plusieurs file descriptors, on let met _tous_ dans un même poll/select.
Mais tout celà est dans le man _et_ dans l'info, tu n'as pas du beaucoup chercher...
Et si ça ne suffit pas, _Unix Network Programming_ est la référence de base.
l'indien wrote in message <pan.2005.06.28.08.46.57.460315@magic.fr>:
- utiliser select:
À part si la compatibilité avec les Unix antédiluviens est nécessaire, poll
vaut mieux (ou epoll si on a beaucoup de fd et que les performances sont
plus importantes que la portabilité, ou pselect s'il y a des signaux à
démasquer atomiquement) que select.
int check_connection (int sock)
Attention, ce genre de code incite à faire du polling. Quand on veut gérer
plusieurs file descriptors, on let met _tous_ dans un même poll/select.
Mais tout celà est dans le man _et_ dans l'info, tu n'as pas du beaucoup
chercher...
Et si ça ne suffit pas, _Unix Network Programming_ est la référence de base.
À part si la compatibilité avec les Unix antédiluviens est nécessaire, poll vaut mieux (ou epoll si on a beaucoup de fd et que les performances sont plus importantes que la portabilité, ou pselect s'il y a des signaux à démasquer atomiquement) que select.
int check_connection (int sock)
Attention, ce genre de code incite à faire du polling. Quand on veut gérer plusieurs file descriptors, on let met _tous_ dans un même poll/select.
Mais tout celà est dans le man _et_ dans l'info, tu n'as pas du beaucoup chercher...
Et si ça ne suffit pas, _Unix Network Programming_ est la référence de base.
l'indien
On Tue, 28 Jun 2005 11:38:43 +0000, Nicolas George wrote:
l'indien wrote in message :
- utiliser select:
À part si la compatibilité avec les Unix antédiluviens est nécessaire, poll vaut mieux (ou epoll si on a beaucoup de fd et que les performances sont plus importantes que la portabilité, ou pselect s'il y a des signaux à démasquer atomiquement) que select.
Je préfère select, car en multithread, on a plus le choix, il faut utiliser pselect dont la syntaxe est très proche. Sinon, gare aux surprises avec les signaux...
int check_connection (int sock)
Attention, ce genre de code incite à faire du polling. Quand on veut gérer plusieurs file descriptors, on let met _tous_ dans un même poll/select.
Oui, je sais bien. C'est juste l'exemple le plus simple pour accepter une connection avec un select, ce qui ne veut pas dire qu'il faut le reprendre tel quel ;-)
Une autre solution élégante mais plus difficile à manier est d'utiliser les aio. Mais gérer tous les fd de façon asynchrone, surtout si on ne veut pas faire de threads est facilement piégeux...
On Tue, 28 Jun 2005 11:38:43 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.06.28.08.46.57.460315@magic.fr>:
- utiliser select:
À part si la compatibilité avec les Unix antédiluviens est nécessaire, poll
vaut mieux (ou epoll si on a beaucoup de fd et que les performances sont
plus importantes que la portabilité, ou pselect s'il y a des signaux à
démasquer atomiquement) que select.
Je préfère select, car en multithread, on a plus le choix, il faut
utiliser pselect dont la syntaxe est très proche.
Sinon, gare aux surprises avec les signaux...
int check_connection (int sock)
Attention, ce genre de code incite à faire du polling. Quand on veut gérer
plusieurs file descriptors, on let met _tous_ dans un même poll/select.
Oui, je sais bien. C'est juste l'exemple le plus simple pour accepter une
connection avec un select, ce qui ne veut pas dire qu'il faut le reprendre
tel quel ;-)
Une autre solution élégante mais plus difficile à manier est d'utiliser
les aio. Mais gérer tous les fd de façon asynchrone, surtout si on ne
veut pas faire de threads est facilement piégeux...
On Tue, 28 Jun 2005 11:38:43 +0000, Nicolas George wrote:
l'indien wrote in message :
- utiliser select:
À part si la compatibilité avec les Unix antédiluviens est nécessaire, poll vaut mieux (ou epoll si on a beaucoup de fd et que les performances sont plus importantes que la portabilité, ou pselect s'il y a des signaux à démasquer atomiquement) que select.
Je préfère select, car en multithread, on a plus le choix, il faut utiliser pselect dont la syntaxe est très proche. Sinon, gare aux surprises avec les signaux...
int check_connection (int sock)
Attention, ce genre de code incite à faire du polling. Quand on veut gérer plusieurs file descriptors, on let met _tous_ dans un même poll/select.
Oui, je sais bien. C'est juste l'exemple le plus simple pour accepter une connection avec un select, ce qui ne veut pas dire qu'il faut le reprendre tel quel ;-)
Une autre solution élégante mais plus difficile à manier est d'utiliser les aio. Mais gérer tous les fd de façon asynchrone, surtout si on ne veut pas faire de threads est facilement piégeux...
Nicolas George
l'indien wrote in message :
Je préfère select, car en multithread, on a plus le choix, il faut utiliser pselect dont la syntaxe est très proche. Sinon, gare aux surprises avec les signaux...
Mélanger select et du multithread, c'est à la base une mauvaise idée. Quant à la gestion des signaux, personnellement je fais toujours ça avec un siglongjmp.
l'indien wrote in message <pan.2005.06.29.07.12.55.338445@magic.fr>:
Je préfère select, car en multithread, on a plus le choix, il faut
utiliser pselect dont la syntaxe est très proche.
Sinon, gare aux surprises avec les signaux...
Mélanger select et du multithread, c'est à la base une mauvaise idée. Quant
à la gestion des signaux, personnellement je fais toujours ça avec un
siglongjmp.
Je préfère select, car en multithread, on a plus le choix, il faut utiliser pselect dont la syntaxe est très proche. Sinon, gare aux surprises avec les signaux...
Mélanger select et du multithread, c'est à la base une mauvaise idée. Quant à la gestion des signaux, personnellement je fais toujours ça avec un siglongjmp.
l'indien
On Wed, 29 Jun 2005 10:41:29 +0000, Nicolas George wrote:
l'indien wrote in message :
Je préfère select, car en multithread, on a plus le choix, il faut utiliser pselect dont la syntaxe est très proche. Sinon, gare aux surprises avec les signaux...
Mélanger select et du multithread, c'est à la base une mauvaise idée. Quant à la gestion des signaux, personnellement je fais toujours ça avec un siglongjmp.
Oui, c'est ce que je dis. Et le problème est le même avec poll. Le seul appel fiable en multi-thread est pselect. Je ne parlais pas de gestion des signaux, en passant, mais des problèmes qui peuvent se poser quand on reçoit des signaux pendant qu'on fait des select/poll dans un environnement multithreadé.
On Wed, 29 Jun 2005 10:41:29 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.06.29.07.12.55.338445@magic.fr>:
Je préfère select, car en multithread, on a plus le choix, il faut
utiliser pselect dont la syntaxe est très proche.
Sinon, gare aux surprises avec les signaux...
Mélanger select et du multithread, c'est à la base une mauvaise idée. Quant
à la gestion des signaux, personnellement je fais toujours ça avec un
siglongjmp.
Oui, c'est ce que je dis. Et le problème est le même avec poll.
Le seul appel fiable en multi-thread est pselect.
Je ne parlais pas de gestion des signaux, en passant, mais des problèmes
qui peuvent se poser quand on reçoit des signaux pendant qu'on fait des
select/poll dans un environnement multithreadé.
On Wed, 29 Jun 2005 10:41:29 +0000, Nicolas George wrote:
l'indien wrote in message :
Je préfère select, car en multithread, on a plus le choix, il faut utiliser pselect dont la syntaxe est très proche. Sinon, gare aux surprises avec les signaux...
Mélanger select et du multithread, c'est à la base une mauvaise idée. Quant à la gestion des signaux, personnellement je fais toujours ça avec un siglongjmp.
Oui, c'est ce que je dis. Et le problème est le même avec poll. Le seul appel fiable en multi-thread est pselect. Je ne parlais pas de gestion des signaux, en passant, mais des problèmes qui peuvent se poser quand on reçoit des signaux pendant qu'on fait des select/poll dans un environnement multithreadé.
