Discussion :

[Higestromm]

Bonjour,

Je souhaiterais savoir si il existe une m�thode un peu comme select mais pour accepter des connections sur diff�rentes socket...

Aparemment select ne peux etre utilis� que sur une socket d�ja connect�e et ca m'�viterais de cr�er une thread pour chaque attente de connection vu que accept est bloquant.

Si quelqu'un connais la r�ponse ou bien si quelqu'un peux m'indiquer au moin une m�thode d'utilisation pour faire un accept non bloquant histoire de cr�er cette fonction moi meme a la limite, ca serait bien

merci

[ken_le_videur]

Pour rendre un socket non bloquant

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
	u_long argp=1;
	ioctlsocket(sock, FIONBIO, &argp);

[Higestromm]

j'ai besoin d'un ptit conseil la

On m'as toujours dit de ne pas utiliser les socket non blocante car elles �taient gourmandes en cpu... Cependant, je pense que la fonction select par exemple utilise ce genre de Proc�d� pour lire sur la liste de socket...

Comment cela se passe-til a l'interieur de ce genre de fonction ??? Il y a un timout dans la boucle d'attente ce qui ralentis les test et donc diminue la consommation CPU tout en diminuant la fr�quence des tests sur chaque socket (je trouve ca bof)...

Ou bien la en ecrivant je vien d'avoir l'id�e de cr�er une class qui gere la liste de socket en les placant dans des tread s�par�es dont elle aurais la gestion... Cela me parais tres compliquer et risque de poser pas mal de probleme de synchronisation cependant ca me parais moin gourmand et plus propre...

Est ce que je me trompe ?

[ken_le_videur]

C'est pas un read sur un socket non bloquant qui bouffe le cpu, c'est l'utilisation faite:
Si tu fait une boucle jusqu'� ce qu'il n'y ai plus rien � lire sans faire un petit temps d'attente ==> paf les perfs d�gringolent.
Il faut juste ins�rer un petit temps d'attente entre les lectures pour permettre au buffer de se remplir

[Higestromm]

Bah finalement ca vas pas :/ Le principe d'attente fonctionnais bien mais le probleme c'est que je doit effectu� des read / Write sur ce socket et eux doivent etres synchrone...

Donc si j attend d'autres client sur ce meme socket tout en communiquant avec les clients d�ja connect�s ca vas pas le faire...

Est ce que je doit faire toute mes lectures / ecritures en asynchrone ??? ca m'embete pas mal mais si j ai pas le choix ...

Vous en pensez quoi ?

[ken_le_videur]

Tu peux rerendre la connection bloquante :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
   u_long argp=0;
   ioctlsocket(sock, FIONBIO, &argp);

[Higestromm]

Oui je sais mais le probeme c'est que si je rend la connection blocante elle le devient aussi pour les attentes de connections... vu que j'utilise le meme socket pour accepter les connection et pour communiquer avec mes clients...
Je vais expliquer un peux mieux ce que fais mon serveur car j'ai �t� tres flou la dessus :

TantQue (ServeurActif)
{
Attente d'une connexion sur 3 socket diff�rente()
Si (UnClientSeConnecte)
{
Switch (PortSurLequelSeConnecteLeClient
case xxx : LancementThreadPourG�r�rLeClientSurLePortXXX();
case yyy : LancementThreadPourG�r�rLeClientSurLePortYYY();
}
}

Sachant que la Thread qui gere le client utilise le meme socket que la socket de connexion on vois bien ici que ca poserais un probleme...

Il doit bien y avoir un moyen d'effectu� une lecture sur une socket non blocante tout de meme... aparemment recv ne le permet pas mais bon. Je vais m accrocher

[Nico65]

vu que j'utilise le meme socket pour accepter les connection et pour communiquer avec mes clients...

:
ca fait un bout de temps que j'ai laiss� tomber les sockets de base, trop bas niveau pour moi, mais generalement quant le serveur fait accept(), on cree le client (thread) avec le socket que renvoie accept(), qui est different du "SuperSocket" (si je veux) du serveur

[Higestromm]

Oula attend la... je commence a me paum� dans mes sockets... G pas le code sous les yeux la mais je crois que je me sert du "supersocket" pour envoyer un message au socket de retour...

mhmhmhmm....

En tout cas je comprend pourquoi tu as arreter d'utiliser les sockets de bases LOL

Je vais v�rifier si g pas fais une connerie a ce niveau la (ca m arrangerais bien dailleur )

[Ti-R]

C'est toujours bien sympa les sockets de bases
D'ailleurs j'y suis en plein dedans en ce moment juste pour le fun en +, bon ok quand cela ne fonctionne pas c�est super lourd lol


Voil� un bout de code pour t�aider un peu dans ta recherche

Ton application n�est pas bloquante
Il attend un peu check s�il y a un message, s�il n�y en a pas il continu et revient via le while.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
	timeval time_socket;
	fd_set t_fd_recv_read;
	SOCKET current_socket;
.....
 
while(server_open)
{
	FD_ZERO(&t_fd_recv_read);
	FD_SET(current_socket, &t_fd_recv_read);
 
	// Time for the select
	time_socket.tv_sec=0;				//send_wait_time_s;
	time_socket.tv_usec=5000;			//send_wait_time_microsecond;
 
	select(current_socket, &t_fd_recv_read, 0, 0, &time_socket);
	if(FD_ISSET	(current_socket, &t_fd_recv_read))
	{
	// Un message est arrivé le traiter
.....
	}
}

[Goundy]

Je souhaiterais savoir si il existe une m�thode un peu comme select mais pour accepter des connections sur diff�rentes socket...

euh.. ?
select() fait �a hein
Tu set tes FDS en read et chaque fois qu'un fd *isset* tu accept()

[Obsidian]

Voir aussi �ventuellement du c�t� de poll() ...

Pour abonder dans le sens de Goundy, un extrait de la page de accept() manuel :

In order to be notified of incoming connections on a socket, you can use select(2) or poll(2). A readable event will be delivered when a new connection is attempted and you may then call accept() to get a socket for that connection. Alternatively, you can set the socket to deliver SIGIO when activity occurs on a socket; see socket(7) for details.

[loufoque]

Utilise boost.asio, c'est tellement plus simple.

[3DArchi]

Bonjour,
Tu peux aussi aller regarder du c�te de ce fil.
En gros:
Le select optimise les attentes d'�v�nements sur toutes tes sockets: socket serveur avant l'accept, socket client pour le connect, sockets connect�es pour les read/write. Une solution peut �tre de couper en deux threads: un d�di� � la connexion des clients et un d�di� aux �changes. Dans le premier thread, tu as juste une socket, qui fait un listen non bloquant et se met en attente sur un select. Lorsqu'elle en sort car demande de connexion, elle fait l'accept et envoi le nouvel handle de socket � l'autre thread. L'autre thread fait les read et les write en mode asynchrone en attendant avec un select. La sortie d'un select sur un �v�nement read signifie que tu pourras faire un read sans que cela bloque. La sortie sur un �v�nement write signifie que le buffer d'�mission est disponible. Attention, cela peut vouloir dire qu'un send va r�ussir mais pas forc�ment sur la totalit� du buffer demand�. Il faut toujours v�rifier que la taille effective prise en compte par le send. L'important est d'�crire alors le bon automate sur ce second thread.