architecture d'un programme client/serveur asynchrone (win)
bonjour !!
je développe une petite application win32 en C, et vu que c ma 1ere, j'apprend au fur et a mesure que je code. Au point où elle en est elle fonctionne, cependant, de manière bloquante :(
en effet, je ne connaissait pas a ce stade les différentes techniques non bloquantes, alors, pdt un transfert de donnée un peu long... la fenetre ne répond plus aux messages :(
donc j'ai décidé de passer a un modèle asynchrone, non bloquant (tcp)
le problème qui se pose est que ce changement implique une réorganisation totale de mon code... je viens voir les experts, afin de savoir si des modèles de communications idéaux existent.
voici comment s'organise mon code actuel :
le client :
chargé d'envoyer en fonction du bouton cliqué par l'utilisateur, une requete au serveur afin que celui ci execute un service correspondant. ceci se fait par l'intermédiaire d'une fonction que j'appelerai "fonction d'appel"
lorsque l'utilisateur clique sur le bouton "service 1", la fonction d'appel de ce service est appelée, elle va envoyer au serveur un numéro d'identification, utilisé par ce dernier pour aiguiller son execution vers le service aproprié.
puis la fonction d'appel envoie un paquet de parametres qui seront reçu par la fonciton de service serveur, et utilisés pour son execution.
comme on le voit, le principe est simple, et une fois l'auiguillage fait, toute la communication se fait entre les fonction d'appel et de service.
pour l'organisation asynchrone, tout est différent, car un send, ou un recv doit se faire lorsqu'on est sur qu'il y a qqch a faire... qd on reçoit le message dans la fenetre. ainsi, on ne peut plus mettre emission, reception, soit tout le dialogue en fait, dans la fonction d'appel.
je propose un schéma d'organisation comme suit :
dans le switch principal de la boite de dialogue, sur mon évènement perso WM_SOCKET_EVENT, j'appele une fonction network( lParam, wParam), cette fonction jouera en quelque sorte le role d'un central de communications.
sont squelette sera un switch gérant les FD_CONNECT, FD_READ, FD_CLOSE.
dans le cas d'un FD_READ, elle appellera une fonction de reception, et aiguillera le paquet reçu vers la fonction appropriée a sont traitement. ce qui implique l'envoi d'un message d'entete, ou d'une variable spécifique, permettant l'aiguillage.
maintenant, les questions que je me pose :
1) est-ce un modèle raisonnable, pour l'efficacité, la programation ? en existe t-il des meilleurs ?
2) après la création de mon socket, je fais un WSAAsyncSelect, ce qui signifie que mon socket est en mode non bloquant. alors, si une fonction doit faire un send, ou un recv, seront ils bloquant ?
ce que j'ai compris, c'est qu'avec ce modèle de message, on est sûr qu'en faisant un recv, il y a qqch a recevoir, cependant, la reception va-t-elle encore bloquer ma fenetre ?
3) puis-je continuer a utiliser mes recv/send que je connais, ou dois-je utiliser WSASend et WSARecv ?
merci pour votre aide !
