MYSQL Client C utilisant WINSOCK uniquement

Version imprimable

16/02/2007, 10h28
mickno

MYSQL Client C utilisant WINSOCK uniquement

Bonjour,

Je suis en train de développer un système d'information en Visual C/C++. Il s'agit d'un système complexe composé de magasins (boutiques) avec un serveur par magasin et d'un serveur dédié sur Internet pour synchroniser les stocks et permettre de gérer entre autre un catalogue global.

J'ai déjà développé pas mal de choses et il ne me reste plus qu'un problème. Mes bases de données sont en MySQL et pour le moment j'utilise le client en c de MySQL. Le problème c'est que je ne peux pas placer d'évènement FD_CLOSE pour détecter une éventuelle déconnexion entre un magasin et le serveur internet. (Si on peut le faire et que je ne l'ai pas vu le problème s'arrête ici :) )

Dans le cas contraire, je cherche donc un code-source "propre" et simple de connexion à une base MySQL utilisant Winsock et non des pipes des sockets unix...
J'ai bien pensé à prendre le code MySQL mais c'est tellement le bordel que j'hésite un peu, mais si je n'ai pas le choix je partirai là dessus.

J'aimerai votre avis?

Cordialement
Arnaud

quel est le probleme des sockets unix?

la seule difference avec les sockets windows ...
ben ... y'en as pas :yaisse2:

ha si ... sous windows faut "lancer" le merdier ... (WSAStart etc ...)

la libMySql est hyper bien foutue et fait tout ce qu'il faut ... comme il faut ...

et en plus, avec 3 petits #ifdef (un pour les includes, 1 pour le Close//fclose et un pour le WSAStartmachin), tu peux ecrire du code fonctionnel sous linux ...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 #ifdef WIN32 #include <winsock.h> typedef unsigned int u_int32_t; typedef size_t socklen_t; #elif defined(linux) #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <netdb.h> #define closesocket(a) close(a) #define SOCKET_ERROR (-1) // defined in winsock.h typedef struct sockaddr_in SOCKADDR_IN; #endif int my_sock_init (void) // init for winsock { #ifdef WIN32 WSADATA wsaData; WORD verreq; verreq = MAKEWORD (2, 2); if (WSAStartup (verreq, &wsaData) != 0) return -1; #endif return 0; } int my_sock_close(void) { #ifdef WIN32 return WSACleanup(); #else return 0; #endif }
moi je dis que ce serait bete de se priver :king:

Citation:

Envoyé par Dark_Ebola

[...]

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#ifdef WIN32
#include <winsock.h>
typedef unsigned int u_int32_t;
typedef size_t socklen_t;
#elif defined(linux)
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
 
#define closesocket(a) close(a)
#define SOCKET_ERROR (-1)       // defined in winsock.h
typedef struct sockaddr_in SOCKADDR_IN;
#endif
int
my_sock_init (void)             // init for winsock
{
#ifdef WIN32
  WSADATA wsaData;
  WORD verreq;
  verreq = MAKEWORD (2, 2);
  if (WSAStartup (verreq, &wsaData) != 0)
    return -1;
#endif
  return 0;
}

moi je dis que ce serait bete de se priver :king:

De se priver de WSACleanup() ?

17/02/2007, 04h18
granquet

Citation:

Envoyé par David.Schris

De se priver de WSACleanup() ?

corrigé ;)
17/02/2007, 04h23
Emmanuel Delahaye

Citation:

Envoyé par Dark_Ebola

corrigé ;)

http://emmanuel-delahaye.developpez....eaux.htm#psock 8-)
17/02/2007, 04h29
David.Schris
Citation:

Envoyé par Dark_Ebola

corrigé ;)
Citation:
Envoyé par Dark_Ebola

Code:

1 2 3 4 5 6 7 8 /* [...] */ int my_sock_close(void) { #ifdef WIN32 WSACleanup(); #endif return 0; }

[...]
Si tu ne testes jamais la valeur retournée par WSACleanup(), alors pourquoi pas comme ceci ?
Code:

1 2 3 4 5 #ifdef WIN32 #define my_sock_close WSACleanup #else #define my_sock_close #endif
PS : je ne dis pas que c'est mieux, je pose la question.
17/02/2007, 04h47
granquet

Citation:

Envoyé par David.Schris

Si tu ne testes jamais la valeur retournée par WSACleanup()

c'est une erreur :aie:
re-corrigé :oops:

jvais aller me coucher moi ...
17/02/2007, 10h20
mickno

Salut,

J'ai pas de problème avec les sockets UNIX mais je fais un projet complètement Win32 dans la mesure où c'est ce que j'ai comme OS sur les ordinateurs des magasins concernés.
Et faire une interface GTK ca me tente pas pour le moment...

Le problème ne réside pas dans les connexion Winsock! J'ai quelques années de Winsock, ça me pause pas de problème, mais faire un client MySQL c'est pas aussi simple.
J'ai cru voir dans les sources que ce qui est utilisé c'est yaSSL, donc avec yaSSL peut on dialoguer avec la base? Est-ce le seul bloc nécessaire?

Mon objectif c'est d'avoir du code clair et malheureusement je trouve que le code de la lib mysql n'est pas super clair entre autre à cause l'ambivalence (Win32 UNIX) qui leur est nécessaire me l'est pas!

Merci
17/02/2007, 13h40
souviron34

je ferais juste une remarque en passant..

Citation:

Dark_Ebola a écrit :

quel est le probleme des sockets unix?

la seule difference avec les sockets windows ...
ben ... y'en as pas

ha si ... sous windows faut "lancer" le merdier ... (WSAStart etc ...)

.
Je me permettrais d'attirer votre attention sur un point central de différence, que malheureusement bien peu de gens mettent en avant, et qui pourtant, dans ce monde de normes et d'objets et de séparation des couches, est crucial....

Simplement : les sockets Windows violent le modèle en couche...

Pourquoi leur faut-il un handle ? (et qui plus est pourquoi (et en lisant la doc système de Windows M$ est particulièrement fier de cette "feature") pour les messages (pour les sockets asynchrones) faut-il un handle de fenêtre ????? )

Autrement dit pourquoi faudrait-il qu'un standard téléphonique connaisse le type de télphone avec lequel je me branche sur la prise ????

C'est à mon avis une violation d'un élément central... Et personne n'a lair de s'en offusquer...
17/02/2007, 14h20
Emmanuel Delahaye

Citation:

Envoyé par souviron34

Pourquoi leur faut-il un handle ? (et qui plus est pourquoi (et en lisant la doc système de Windows M$ est particulièrement fier de cette "feature") pour les messages (pour les sockets asynchrones) faut-il un handle de fenêtre ????? )

Bah, les sockets en asynchrone, ça se fait à coup de select() et de threads... C'est pas un problème et c'est portable.
17/02/2007, 14h35
souviron34

Citation:

Envoyé par Emmanuel Delahaye

Bah, les sockets en asynchrone, ça se fait à coup de select() et de threads... C'est pas un problème et c'est portable.

mwé...

Mais les sockets et les sockets aysnchrones étaient portables .. jsqu'à Winsock... :mrgreen:
17/02/2007, 16h01
Emmanuel Delahaye

Citation:

Envoyé par souviron34

Mais les sockets et les sockets aysnchrones étaient portables .. jsqu'à Winsock...

Je ne connais pas Winsock qui est obsolète, mais avec Winsock2, c'est pareil que sous unixoïde.

A part l'initialisation (WSAtrucmuche()), la seule restriction est que select() ne traite pas autre chose que les sockets sous Windows.

Un thread et c'est réglé. Ca reste portable.
17/02/2007, 20h43
Médinoc

Les "sockets asynchrones" de Winsock2 permettent à une fenêtre d'être notifiée d'un événement sur un socket (genre: Un client essayant de se connecter) par un simple message, comme elle est prévenue de tout le reste (souris, clavier).
En fait, cela fait des événements sur un socket des événements comme les autres.
C'est très intéressant sous Windows, car cela centralise toute l'attente dans le GetMessage(), alors qu'on serait obligé d'utiliser plusieurs threads sous unixoïde pour cumuler interface graphique et sockets.

(Note: Les sockets asynchrones utilisent en fait un thread supplémentaire, mais c'est transparent et les fonctions utilisateur n'y ont pas accès : Tout le code utilisateur s'exécute dans le même thread).

je ne comprend pas ce que vous dites tous les 2...

Cela fait 12 ans que je programme des sockets sous Unix/HPUX et Linux, pour faire des serveurs et une bibliothèque sous-couche de fond pour une très grosse application avec plusieurs GUI.

1) je n'ai jamais ententu parlé (sauf par des gens venant du côté Windows et allant vers Linux) de thread.

2) ce n'est pas portable puisque les noms changent (WSA...)...

3) tout l'intérêt de la structure asynchrone telle qu'elle est définie sous U.x est justement d'être INDEPENDANT de comment on l'utilise : comme pour la fonction signal, on passe un (void *)fonction a être appelé.... Il me semble avoir compris qu'avec Winsock2 il faut passer un handle de fenêtre.. Mais par exemple dans le cas de mes serveurs je n'ai PAS de fenêtres (ce sont des processus (vrais services sous U.X))..

4) je pense que justement c'est un recul si on doit faire connaître à la couche basse quelque chose de la couche supérieure.

Pour reprendre un peu mon exemple cité plus haut :

J'ai un téléphone (fixe). Je le branche sur une prise. J'appelle un numéro au Japon. Je ne vois pas pourquoi MON téléphone devrait envoyer/connaître autre chose que les impulsions et les fréquences reconnues.. Il n'y a aucune raison pour que, afin de téléphoner, le CENTRAL ait besoin de connaître les caractéristiques de mon téléphone. Il connait juste le départ de ma ligne physique et le numéro attaché (pour nous le port), AU CENTRAL, et la série des fréquences que je lui envoie. Sans plus.

Si maintenant je prend l'exemple de mon application centrale :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Bibliothèque de communication <- HTTP(sockets) / \ / \ / \ Bibliothèque pour Bibliothèque de fabriquer des serveurs création de données | | | | Serveur1 Serveur2 Serveur3.... Bibliothèque "métier" (binaires lancés comme services) (sans fenêtres. C pur) / \ / \ / \ Bibliothèque GUI1 Bibliothèque GUI2 \ / \ / ------- / \ Application1 Application2 .... (binaires avec GUI)
Pourquoi faudrait-il que la couche sockets connaisse un id d'une fenêtre de la couche GUI ???

Ce que je dis c'est que la norme ISO de développement en couches est violée, et que ce n'est pas portable .

Mes serveurs n'ont PAS de fenêtres, sous les sytèmes U.X. Et d'autre part mes applis n'interfacent QUE le GUI.... Et le GUI n'interface QUE la couche métier. Et la couche métier n'interface QUE la couche création de données, qui ,elle, interface la couche HTTP...

De plus, si vous avez une solution pour que je ne fasse que recompiler et linker avec une autre bibliothèque, là je dis que c'est portable... Si il faut changer du code, ça ne l'est pas :mrgreen:

18/02/2007, 08h37
Emmanuel Delahaye

Citation:

Envoyé par souviron34

je ne comprend pas ce que vous dites tous les 2...

http://emmanuel-delahaye.developpez.com/reseaux.htm
18/02/2007, 09h58
Médinoc

souviron34 : Dans le schéma que tu nous montre, ce n'est pas le serveur qui a une interface graphique, mais le client. Ton serveur est exclusivement serveur et ne fait rien d'autre.

De plus, sous Unixoïde, un serveur peut avoir une interface texte (Command-line interface), parce que select() marche sur les flux standard, ce qui n'est pas le cas sous Windows.
Les sockets Asynchrones sous Windows permettent de mettre dans le même processus l'interface graphique (donc, des fenêtres) et des fonctions serveur, sans avoir à gérer soi-même la synchronisation entre threads (puisque tout le code utilisateur s'exécute dans un et un seul thread).

À présent, pourquoi un serveur aurait une interface utilisateur (texte ou grpahique) ? Pour l'instant, je ne vois qu'une raison valable: L'existence d'un protocole appelé "FTP actif", où le client FTP est lui-même un serveur (sans compter les clients-serveurs de P2P).
18/02/2007, 10h04
Médinoc
Citation:

Pourquoi faudrait-il que la couche sockets connaisse un id d'une fenêtre de la couche GUI ???

Ce que je dis c'est que la norme ISO de développement en couches est violée, et que ce n'est pas portable.

Il n'est pas question ici de problèmes de couche: il est question de système, de programmation événementielle, et de regrouper l'attente en un seul point du thread.
Cela est possible:
- avec aucune interface utilisateur (tout par sockets)
- avec une interface texte sous unixoïde (attente sur select())
- avec une interface graphique et les sockets asynchrones de Win32 (attente sur GetMessage() ou une fonction soeur).
Cela n'est pas possible (à ma connaissance) :
- avec une interface texte sous Win32 (select() ne marche pas sur les flux standard)
- avec une interface graphique sous unixoïde (ou bien si : Comme X-Window est en client-serveur, select() marche peut-être dessus).

Citation:

Envoyé par Médinoc

Il n'est pas question ici de problèmes de couche: il est question de système, de programmation événementielle, et de regrouper l'attente en un seul point du thread.

Si justement...

Ce que je veux dire, au cas où je me sois mal exprimé :

J'ai une bibliothèque de manipulation de sockets (Start_Serveur, Start_Client, Ecoute_Synchrone, Ecoute_Asynchrone, Envoie_Asynchrone, Envoie_Synchrone, etc..)

Encore une fois je répète je n'ai jamais eu besoin de la notion de thread... C'est uniquement un "wrapping" autour des fonctions standard de C (getpeername, gethostbyname, select, etc...)

La FONCTIONALITE est une fonctionalité de base (gérer la communication), sans plus... (au même titre que "coder une fréquence pour la convertir en chiffre" présente dans les standards téléphoniques)..

Maintenant je construit des applications différentes sur cette bibliothèque :

1) des serveurs de données (sans interfaces. fonctionnants uniquement via requêtes d'un protocole du style HTML) (donc programmation évènementielle)
2) un "interrogateur" de serveurs, avec une interface en mode texte, permettant de dialoguer avec les serveurs
3) des applications interactives (avec interfaces fenêtres (XWindow pour l'instant, mais justement pourrait être Windows ou Java)) se connectant à des serveurs et demandant/affichant/renvoyant des données. Ces applications sont bien entendu également à programmation évènementielle.
4) des applications non-interactives (avec interfaces, mais sans fenêtres (exemple : input : langage de commande, scripts; output : gif, jpeg..)) effectuant les mêmes fonctionalités que les applications interactives.

Si je change d'outil graphique, un découpage fonctionnel me dit que la présentation n'est que ça, une présentation... La fonctionalité réside en dessous. Et l'accès aux données encore en dessous.. Et la gestion de la communication encore en dessous....(après il y a la gestion "kernel" des sockets (le code exact des select etc...)).

Donc le fait de changer d'outil graphique ne devrait avoir AUCUN impact sur une couche basse...

Je vous montre un exemple, justement avec la routine gérant la mise en asynchrone des sockets :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 /*! --------------------------------------------------------------------- Nom : <InitialiserSocketAsynchrone> Creation : xxxx - fevrier 1997 But : Initialiser l'option de lecture asynchrone pour un socket. Lorsqu'un fichier est en mode asynchrone, le systeme avise le programme appelant lorsque le fichier est pret pour une lecture. Parametres : <requete> : numero du descripteur de fichier <fonction> : fonction appelee lors de la reception du signal systeme Retour : 0 si tout va bien < 0 il y a eu erreur > 0 : il y a deja des caracteres a lire sur le socket. Dans ce cas, on retourne le nobre de caracteres disponibles sans passer en mode asynchrone. Remarques : Aucune Modifications : Nom : Date : Description : ---------------------------------------------------------------------- !*/ int InitialiserSocketAsynchrone(int requete,void (*fonction)() ) { pid_t pid; int retour; int bidon; #ifdef DEBUGJS fprintf (stderr, " ESSAI MISE SOKCET ASYNC"); #endif /* *On verifie s'il y a des caracteres a lire sur le conduit *Si oui, on retourne le nombre de caracteres sans passer *en mode asynchrone *Ceci evite les interruptions lors de la lecture */ retour = ioctl(requete,FIONREAD,&bidon); if ( retour != 0 ) { #ifdef DEBUGJS fprintf (stderr, " PEUT PAS METTRE SOCKET ASYNC : %d ERREUR %d",requete,retour); #endif return(retour); } if(bidon > 0 ) { #ifdef DEBUGJS fprintf (stderr, " PEUT PAS METTRE SOCKET ASYNC : %d reste qquechose a lire",requete); #endif return(bidon); } /* *Il n'y a rien a lire, on passe en asynchrone *Obtenir le numero de ce processus pour pouvoir le refiler *a ioctl afin d'etre avise de tout changement sur le socket */ pid =getpid(); bidon = (int) pid; #ifndef LINUX retour = ioctl(requete,SIOCSPGRP,&bidon); #else retour = fcntl(requete,F_SETOWN,(long)bidon); #endif if ( retour < 0 ) return retour ; /* *Initialiser l'option asynchrone pour le socket */ #ifdef DEBUGJS fprintf (stderr, " DECLENCHE"); #endif #ifndef LINUX bidon = 1; retour = ioctl(requete,FIOASYNC,&bidon); #else bidon = O_ASYNC ; retour = fcntl(requete,F_SETFL,(long)bidon); #endif #ifdef DEBUGJS fprintf (stderr, " MISE SOCKET ASYNC : %d",retour); if ( retour < 0 ) fprintf (stderr, " => ERREUR"); #endif if ( retour < 0 ) return retour ; else { #ifdef DEBUGJS fprintf (stderr, " DECLENCHE SIGIO"); #endif signal(SIGIO,fonction); return (0); } }
On voit bien ici que RIEN ne justifie la connaissance de l'UTILISATION.... La fonction appelée lors du SIGIO peut être n'importe quoi : une fonction d'interface, une fonction pure code, etc..

Or donc cette routine est appellée dans les 4 cas cités plus haut (sans interface même texte, avec interface texte, avec interface graphique interactive, avec interface graphique non-interactive)...

Ce que je veux dire, c'est que cela fait partie des appels reconnus par le standard C... et que c'est logique..

Si maintenant je passe sous Windows avec Winsock2, je dois fournir une EXPLICATION de l'utilisation..... puisqu'il faut que je passe un handle...

Cela correspond donc à ce que je dis, cela viole le modèle de couches indépendantes (où chaque couche est IGNORANTE de la couche au dessus, mais dépend de la couche en dessous....)

18/02/2007, 15h43
Médinoc
Ton code sur les sockets asynchrones ne semble pas se baser sur une attente centralisée, mais sur des signaux, qui interrompent donc l'exécution potentiellement à n'importe quel moment. Ce n'est donc pas de la prorammation événementielle comme celle de Windows, mais un système basé sur l'interruption du flot de contrôle actuel.
Cela suppirme la difficulté dans Windows qui consiste à ATTENDRE qu'il se passe quelque chose.
Ou plus précisément, ATTENDRE des événements différents pouvant provenir de plusieurs sources différentes.

Exemple:
- Serveur sans interface, un seul type de source: sockets. --> Avec SIGIO tu fais ce que tu veux, avec select() ça marche aussi.
- Serveur avec interface texte, un seul type de source aussi, car les sockets sont des descripteurs.
- Serveur avec interface graphique dans le même processus, genre client FTP graphique : Ici, il y a deux sources d'événements : Les événements arrivant sur la fenêtre et ceux sur le réseau.
  En programmation événementielle, on attend en un seul point qu'un événement se passe. Problème, il faut avoir une fonction système pour ça. Si tu fais select(), la fenêtre ne réagira pas pendant le timeout. Si tu utilises la fonction d'attente d'un événement sur la fenêtre, tu ne réagiras pas aux sockets en programmation événementielle. Par contre, en programmation interruptible, tu peux attendre tranquillement un événement sur la fenêtre et être interrompu quand quelque chose arrive.
Eh bien sous Windows, tu n'as pas de programmation socket interruptible comme ça. Tu n'as que des fonctions d'attente d'événements. Deux sont dédiées aux sockets et à rien d'autre: Ce sont select() et WSAWaitForMultipleEvents().
D'autres sont dédiées aux événements d'une fenêtre : Ce sont GetMessage(), WaitMessage(), MsgWaitForMultipleObjects() et MsgWaitForMultipleObjectsEx(). Il semblerait qu'aucune de ces fonctions ne puisse attendre directement un événement sur un socket comme select() le fait. C'est pourquoi on doit utiliser une fonction qui traduit tout événement socket en message : WSAAsyncSelect() (comme select() asynchrone).

Citation:

Envoyé par MSDN

The WSAAsyncSelect function requests Windows message-based notification of network events for a socket.

Sur cette fonction, il reste tout de même la faille que tu as précisée : La question "pourquoi destiner le message à une fenêtre en particulier et non à un thread en général ?" ne possède pas de réponse valide à ma connaissance. Mais de toute façon, la fenêtre en question n'a pas besoin d'être ton interface graphique. Cela peut être une fenêtre cachée en permanence, voire même une message-only window à partir de Win 2000 et supérieur.
(d'ailleurs, par soucis de séparation, je vais en effet auditer mon code pour qu'il en soit ainsi, tiens).

PS: Il n'est pas nécessaire en effet d'évoquer la notion de thread.
Mais comme sous Windows, tout processus est composé d'un ou plusieurs threads, et comme toutes les fonctions d'attente interrompent le thread courant et non le processus courant (ce qui revient au même pour un processus mono-threadé), je parle d'attente "en un seul point du thread".
Mais si le terme "thread" t'offense, j'aurais aussi pu dire "en un seul point du flot d'exécution". Ça te va?
18/02/2007, 15h44
David.Schris

Citation:

Envoyé par souviron34

[...] un protocole du style HTML [...]

"HTML" : avec un "L" comme "Protocole" :mrgreen:
18/02/2007, 15h55
Emmanuel Delahaye

Citation:

Envoyé par David.Schris

"HTML" : avec un "L" comme "Protocole" :mrgreen:

Faut ménager les papys... Alors, on va dire http....

Citation:

Envoyé par David.Schris

"HTML" : avec un "L" comme "Protocole" :mrgreen:

ben que crois-tu qu'est :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 <body> <table width="100%" cellspacing="4"> <tr> <td align="center"> <table width="100%" cellspacing="0" cellpadding="0"> <tr> <td> <table width="100%" cellspacing="11"> <tr> <td> <a href="http://www.developpez.com"><img src="images/logo.gif" alt="Accueil" /></a>
C'est pas un protocole ???

HTML est un PROTOCOLE de formattage de document, HTTP est un PROTOCOLE de communication, etc....

19/02/2007, 01h15
souviron34

Citation:

Envoyé par Médinoc

Ce n'est donc pas de la prorammation événementielle comme celle de Windows, mais un système basé sur l'interruption du flot de contrôle actuel.

Ben désolé pour la sémantique, mais pour moi une programmation évènementielle c'est une programmation où on saute d'un point à un autre en fonction des évènements.... :P

Donc une connection asynchrone sur un socket qui par signal appelle une fonction est dans ma définition un événement....

Citation:

Envoyé par Médinoc

[*]Serveur avec interface graphique dans le même processus, genre client FTP graphique : Ici, il y a deux sources d'événements : Les événements arrivant sur la fenêtre et ceux sur le réseau.
En programmation événementielle, on attend en un seul point qu'un événement se passe.

Ah bon ?? Pourquoi en un seul point ? Justement si les événements viennent de plusieurs sources, tu devrait pouvoir avoir plusieurs points (c'est d'ailleurs ce que j'ai dans mes applications : le XMainLoop pour la gestion des événements fenêtre, et une fonction DialogWithServers qui simultanément dans la même application gère les événements sockets)(et sans X, un fgets par exemple pour l'interrogateur de serveur (attente prochaine commande) en parallèle avec la gestion interrupt)....

Citation:

Envoyé par Médinoc

Problème, il faut avoir une fonction système pour ça. Si tu fais select(), la fenêtre ne réagira pas pendant le timeout. Si tu utilises la fonction d'attente d'un événement sur la fenêtre, tu ne réagiras pas aux sockets en programmation événementielle. Par contre, en programmation interruptible, tu peux attendre tranquillement un événement sur la fenêtre et être interrompu quand quelque chose arrive.

Eh bien sous Windows, tu n'as pas de programmation socket interruptible comme ça. Tu n'as que des fonctions d'attente d'événements. Deux sont dédiées aux sockets et à rien d'autre: Ce sont select() et WSAWaitForMultipleEvents().
D'autres sont dédiées aux événements d'une fenêtre : Ce sont GetMessage(), WaitMessage(), MsgWaitForMultipleObjects() et MsgWaitForMultipleObjectsEx(). Il semblerait qu'aucune de ces fonctions ne puisse attendre directement un événement sur un socket comme select() le fait. C'est pourquoi on doit utiliser une fonction qui traduit tout événement socket en message : WSAAsyncSelect() (comme select() asynchrone).

:yaisse2:
BON !!! Là on commence à parler sérieusement....

Et c'était bien ce que je disais au début du thread, en disant que il y a VRAIMENT une différence fondamentale entre les sockets U.X et les sockets Windows... (et que ça ne se résume à WSAStart)... :mouarf:

Citation:

Envoyé par Médinoc

Sur cette fonction, il reste tout de même la faille que tu as précisée : La question "pourquoi destiner le message à une fenêtre en particulier et non à un thread en général ?" ne possède pas de réponse valide à ma connaissance. Mais de toute façon, la fenêtre en question n'a pas besoin d'être ton interface graphique. Cela peut être une fenêtre cachée en permanence, voire même une message-only window à partir de Win 2000 et supérieur.

:yaisse2:

je suis d'accord avec toi, mais c'est la notion même d'avoir à introduire un id de fenêtre (même si elle n'est pas visible) qui me choque profondément..

(ce qui fait d'ailleurs que porter une énorme application telle que la mienne, dont le point central réside dans la possibilité de pouvoir faire ce qui est décrit ci-dessus, génère un casse-tête éthique , esthétique, et de programmation, car rien n'était prévu pour traverser les couches...)

Et c'est pour ça que je tenais à le porter à votre attention, car je n'ai pas l'impression que beaucoup en soit conscients...

Citation:

Envoyé par Médinoc

PS: Il n'est pas nécessaire en effet d'évoquer la notion de thread.
Mais comme sous Windows, tout processus est composé d'un ou plusieurs threads, et comme toutes les fonctions d'attente interrompent le thread courant et non le processus courant (ce qui revient au même pour un processus mono-threadé), je parle d'attente "en un seul point du thread".
Mais si le terme "thread" t'offense, j'aurais aussi pu dire "en un seul point du flot d'exécution". Ça te va?

non ça m'offense pas du tout :lol: ... Mais c'est bien ce que je voulais dire au début... Il y a comme une teinte Windows ET dans le langage ET dans la pensée.... Et comme je ne viens pas de ce monde, ça m'énerve juste un peu qu'on utilise ce genre de termes/logique comme si c'état normal et naturel, alors que c'est originaire et principalement utilisé dans ce monde....

:traine:
19/02/2007, 06h05
Emmanuel Delahaye

Citation:

Envoyé par souviron34

ben que crois-tu qu'est :
HTML est un PROTOCOLE de formattage de document,

Bah, non. HyperText Markup Language, n'a rien d'un protocole...

Par contre HyperText Transfert Protocole, est bel et bien un protocole utilisé pour transférer du HTML et dérivés (XHTML, etc.).
19/02/2007, 09h08
Médinoc

Citation:

Envoyé par souviron34

Ben désolé pour la sémantique, mais pour moi une programmation évènementielle c'est une programmation où on saute d'un point à un autre en fonction des évènements.... :P

Donc une connection asynchrone sur un socket qui par signal appelle une fonction est dans ma définition un événement....

Là, il y a conflit, car je fais une différence entre programmation événementielle et programmation interruptible.
Pourtant, wikipédia semble de ton coté:

Citation:

Envoyé par [url=http://en.wikipedia.org/wiki/Event-driven_programming]Wikipédia[/url]

The method by which information on events is acquired by the underlying system is immaterial. Inputs can be polled in the event loop, or interrupt handlers can be registered to react to hardware events;

Mais le fonctionnement interruptiple n'est pas aussi propre que de la "vraie" programmation événementielle.

Citation:

Envoyé par [url=http://en.wikipedia.org/wiki/Signal_%28computing%29]Wikipédia[/url]

Signal handling is vulnerable to race conditions. Because signals are asynchronous, another signal (even of the same type) can be delivered to the process during execution of the signal handling routine. The sigprocmask() call can be used to block and unblock delivery of signals.

Citation:

Envoyé par [url=http://en.wikipedia.org/wiki/SIGPOLL]Wikipédia: SIGIO/SIGPOLL[/url]

By employing this mechanism, the user may accomplish true asynchronous I/O without the conceptual overhead of a multiplexing select loop. A possible disadvantage is that the technique lends itself to producing spaghetti code, with race conditions a danger.

De plus, ta fonciton DialogWithServer ne PEUT PAS s'exécuter simultanément si on ne parle pas de multi-thread.
Par contre, elle peut être appelée par un signal et donc INTERROMPRE ta XMainLoop() à tout moment, même pendant le traitement d'un événement X.
Ce qui n'est pas possible sous Windows.

Citation:

Envoyé par souviron34

je suis d'accord avec toi, mais c'est la notion même d'avoir à introduire un id de fenêtre (même si elle n'est pas visible) qui me choque profondément.

Là, je te rejoins.
Chaque thread sous Windows possède sa propre file de messages, et un message peut être destiné à une fenêtre ou au thread lui-même. Il n'est pas normal qu'un message réseau doive être destiné à une fenêtre.

PS: Pour moi, c'est le monde unix qui n'est pas normal, où les threads sont un bricolage par rapport aux processus au lieu d'être directement intégrés au kernel.
19/02/2007, 12h31
souviron34

Citation:

Envoyé par Médinoc

De plus, ta fonciton DialogWithServer ne PEUT PAS s'exécuter simultanément si on ne parle pas de multi-thread.

RIEN ne s'exécute simultanément... C'est le scheduler qui gère ça.. :P

Citation:

Envoyé par Médinoc

PS: Pour moi, c'est le monde unix qui n'est pas normal, où les threads sont un bricolage par rapport aux processus au lieu d'être directement intégrés au kernel.

Alors là pas du tout d'accord ;)

Comme tu le disais précedemment :

Citation:

Envoyé par Médinoc

C'est très intéressant sous Windows, car cela centralise toute l'attente dans le GetMessage(), alors qu'on serait obligé d'utiliser plusieurs threads sous unixoïde pour cumuler interface graphique et sockets.

Et le fait qu'ils soient très fiers de cette "feature" dans la doc. montre que c'est une violation volontaire et délibérée de la manière de faire généralement acceptée (pour mémoire, les unixoides étaient le consensus généralement acceptés par l'ensemble des constructeurs.. sauf qui vous savez ;-) )

Et contrairement à ce que tu disais plus haut, ça n'est pas une faiblesse.. C'est fait exprès...

Et comme je te le disais, jusquà vouloir porter sous Win. je n'ai jamais ni utilisé ni même entendu parler de la notion de thread...

Je ne rentrerais pas dans le débat des responsabilités, mais je pense qu'il faut bien être conscient pour tous les programmeurs qui s'occupent des sockets et créent des architectures que cette "feature" fait que l'on ne PEUT avoir une architecture fonctionnellement propre... C'est tout..

Et que c'est une déformation d'usage (pour ne pas dire plus) qui fait que l'on déporte sur d'autres systèmes une manière de faire qui n'était que propre à un système..

Enfin, pour Emmanuel et David, bien entendu que HTML est un langage, mais le principe est un protocole :

Citation:

Le grand Robert :

(1923). Techn. Modèle des signes; liste de conventions (utilisée pour la correction, comme mode d'emploi).

HTML est donc un protocole, par lequel un ensemble de signes est agréé....

Un langage (y compris le français ;-) est un protocole de communication...
19/02/2007, 14h09
Médinoc

Citation:

Envoyé par souviron34

RIEN ne s'exécute simultanément... C'est le scheduler qui gère ça.. :P

Citation:

Alors là pas du tout d'accord ;)

Citation:

Et contrairement à ce que tu disais plus haut, ça n'est pas une faiblesse.. C'est fait exprès...

Va dire ça aux proprios d'un serveur Win2003 à deux processeurs dual-core hyperthreadés (deux processeurs réels qui donnent huit processeurs virtuels). Avant Linux 2.6, tu n'avais qu'un seul processus, donc les avantages d'un multiprocesseur n'étaient pas exploitables. Depuis Linux 2.6, grâce à un astucieux bricolage appelé NPTL, tu as un processus PAR thread (et non l'inverse), qui permet d'utiliser le multiprocesseur pour un même "processus multithreadé". Pour les autres unixoïdes, je ne sais même pas si c'est implémenté...
De plus, c'est toi qui a dit "simultanément" et en informatique, simultanément signifie "dans deux flots de contrôle parallèles" alors que ton exemple sur les signaux ne montre qu'un seul flot de contrôle, interrompu (et le mien un seul pas interrompu du tout) : Même sur un multiprocesseur, il n'y aura qu'un seul flot dans ton exemple unix comme dans mon exemple Windows.

Citation:

Et le fait qu'ils soient très fiers de cette "feature" dans la doc montre que c'est une violation volontaire et délibérée de la manière de faire généralement acceptée (pour mémoire, les unixoides étaient le consensus généralement acceptés par l'ensemble des constructeurs.. sauf qui vous savez ;-) )

Citation:

Je ne rentrerais pas dans le débat des responsabilités, mais je pense qu'il faut bien être conscient pour tous les programmeurs qui s'occupent des sockets et créent des architectures que cette "feature" fait que l'on ne PEUT avoir une architecture fonctionnellement propre... C'est tout..

Citation:

Et que c'est une déformation d'usage (pour ne pas dire plus) qui fait que l'on déporte sur d'autres systèmes une manière de faire qui n'était que propre à un système..

Les sockets asynchrones étaient une extension des deux cotés. D'ailleurs, ta "bonne manière de faire" est maintenant dépréciée et une autre est conseillée...

Citation:

Envoyé par Wikipédia: SIGIO/SIGPOLL

From POSIX 1003.1 (2003), it is preferred to use the standardised system calls for asynchronous I/O defined in aio.h. These allow requests to be queued for asynchronous execution; return and error status can be retrieved with the aio_return and aio_error functions, respectively.

Si le kernel Windows ne supporte pas l'existant interruptible avec les signaux ou avec select(), un existant qui a les inconvénients déjà évoqués, autant faire mieux...
Et je rappelle que tu PEUX faire un serveur 100% sockets avec select() (là, ça devient du vrai événementiel)... Ils ont même rajouté le premier paramètre, inutile sous Windows et ch***t à obtenir sous unixoïde, uniquement pour la compatibilité...

Citation:

Et comme je te le disais, jusquà vouloir porter sous Win. je n'ai jamais ni utilisé ni même entendu parler de la notion de thread...

Normal, sous Unixoïde, on ne parle pas de thread tant qu'on n'évoque pas le multithread. Sous un vrai OS, on parle de processus monothreadé ou multithreadé...

Citation:

Enfin, pour Emmanuel et David, bien entendu que HTML est un langage, mais le principe est un protocole :
HTML est donc un protocole, par lequel un ensemble de signes est agréé....
Un langage (y compris le français ;-) est un protocole de communication...

FAUX. Le langage fait partie du protocole, mais n'est pas lui-même un protocole. Tu as perdu.
19/02/2007, 14h15
DaZumba

Citation:

Envoyé par souviron34

HTML est donc un protocole, par lequel un ensemble de signes est agréé....

C'est jouer sur les mots. HTML est un langage, HTTP est un protocole (comme leurs noms l'indiquent).
19/02/2007, 14h19
souviron34

Citation:

Envoyé par Médinoc

FAUX. Le langage fait partie du protocole, mais n'est pas lui-même un protocole. Tu as perdu.

euhh...

Wikipédia donne :

Citation:

Langue
Un article de Wikipédia, l'encyclopédie libre.

Une langue est un système de signes linguistiques vocaux, graphiques ou gestuels qui permet la communication entre les individus.

Une définition linguistique de la langue précise que c'est un système de signes doublement articulés, c'est-à-dire que la construction du sens se fait à deux niveaux d'articulation. On trouve tout d'abord celui des entités signifiantes (morphèmes et lexèmes, ou monèmes) formant les énoncés puis celui des unités distinctives de sens (phonèmes) formant les unités signifiantes. Ces deux niveaux d'articulation déterminent les premiers niveaux de la description linguistique : phonologie, morphologie et syntaxe. André Martinet précise que l'ordre de description est nécessairement inverse de l'ordre de perception ou d'usage de la langue : la description commence par le deuxième niveau d'articulation (les phonèmes) pour aller vers le premier (la combinatoire des unités signifiantes).

Langue et langage

On distingue généralement la langue (système de signes) et le langage (faculté humaine mise en œuvre au moyen d'un tel système).

.....

je rajouterais aussi :

Citation:

Protocole

On désigne sous ce terme tout ce qui rend la communication possible ou plus aisée sans rapport avec le contenu de la communication elle-même.

Attendre une tonalité pour numéroter, demander à l'interlocuteur de se répéter, épeler son nom, s'entendre tacitement sur le moment où une communication sera considérée comme terminée font partie des protocoles.

La mise en œuvre d'un protocole demande la définition de normes élaborées.

....

http://fr.wikipedia.org/wiki/Protocole_de_communication

Dans les réseaux informatiques et les télécommunications, un protocole de communication est une spécification de plusieurs règles pour un type de communication particulier.

Initialement, on nommait protocole ce qui est utilisé pour communiquer sur une même couche d'abstraction entre deux machines différentes. Par extension de langage, on utilise parfois ce mot aussi aujourd'hui pour désigner les règles de communication entre deux couches sur une même machine.

Les protocoles de communication les plus utilisés sont les protocoles réseau.

Le concept [modifier]
Communiquer consiste à transmettre des informations mais tant que les interlocuteurs ne lui ont pas attribué un sens il ne s'agit que de données pas d'information. Les interlocuteurs doivent donc non seulement parler un langage commun mais aussi maitriser des règles minimales d'émission et de réception des données. C'est le rôle d'un protocole de s'assurer de tout cela. Par exemple dans le cas d'un appel téléphonique:

l'interlocuteur apprend que vous avez quelque chose à transmettre (Vous composez son numéro pour faire sonner son combiné) ;
il indique qu'il est prêt à recevoir (vous attendez qu'il décroche et dise "Allo") ;
il situe votre communication dans son contexte (« Je suis Christophe. Je t'appelle pour la raison suivante... ») ;
un éventuel destinataire final peut y être identifié (« Peux-tu prévenir Michel que... ») ;
le correspondant s'assure d'avoir bien compris le message (« Peux-tu me répéter le nom ? ») ;
les procédures d'anomalies soient mises en place (« Je te rappelle si je n'arrive pas à le joindre ») ;
les interlocuteurs se mettent d'accord sur la fin de la communication (« Merci de m'avoir prévenu »).
Cette métacommunication n'est autre que la mise en œuvre de protocoles.

Mais vous avez déjà implicitement observé un autre protocole, avec une autre couche de communication, en attendant d'avoir la tonalité pour composer le numéro de votre correspondant. Et les standards téléphoniques de départ et d'arrivée, pour leur part, se sont coordonnés entre eux aussi : autant de protocoles.
19/02/2007, 16h18
souviron34

Citation:

Envoyé par Médinoc

Va dire ça aux proprios d'un serveur Win2003 à deux processeurs dual-core hyperthreadés (deux processeurs réels qui donnent huit processeurs virtuels). Avant Linux 2.6, tu n'avais qu'un seul processus, donc les avantages d'un multiprocesseur n'étaient pas exploitables. Depuis Linux 2.6, grâce à un astucieux bricolage appelé NPTL, tu as un processus PAR thread (et non l'inverse), qui permet d'utiliser le multiprocesseur pour un même "processus multithreadé". Pour les autres unixoïdes, je ne sais même pas si c'est implémenté....

Euhh... La parallèlisation multiprocesseurs existe depuis ... 20 ans ?? (et même en réseau)..

Il y a même un langage (:lol: ) associé : le MPI.

http://www-unix.mcs.anl.gov/mpi/
19/02/2007, 16h58
Médinoc

MPI, c'est du MultiprocessUS s'il te plait (donc, c'est évident que ça marche sur du multiprocessEUR).

Il est plus intéressant de parler d'OpenMP, dont Wikipédia ne dit pas grand-chose de l'implémentation sous-jacente sur un système unixoïde, mais il y a fort à supposer que ce soit là encore basé sur du multiprocessus+mémoire partagée puisqu'il serait impossible de répartir le même processus sur différents processeurs sur un kernel unixoïde (cela équivaudrait à répartir le même thread sur différents processeurs sous Windows!)

Donc là encore, c'est du bricolage: On prend plusieurs processus et on les regroupe, plutôt que d'avoir un seul vrai processus multi-thread...
19/02/2007, 17h21
souviron34

euh là je te suis plus....

Compiler une application en la rendant parallèle gràce aux outils de compilation, j'appelle pas ça du multi-processus...

Je me souviens que Silicon (je n'ai plus la réference en tête pour l'instant) avait directement une variable système à mettre en tête des programmes qui était quelque chose comme NumCPU(NCpus) et ça sous leur version de Unix en 1992. ... Et directement à la compile le code était parallèlisé en fonction du nombres de CPU.
Et il me semble bien que VMS permettait ça en 1989 ...

Moi j'appelle ça du multi-processeurs, non ?
19/02/2007, 17h45
Médinoc
Multi-processus, ça se voit selon ce que "voit" ou non le kernel pour une même application.
(sachant qu'un kernel unixoïde ne voit rien de plus petit qu'un processus).
- Si elle lui apparait comme un seul processus, c'est que soit elle est mono-threadée, soit elle fait sa tambouille dans son coin (et dans ce cas, impossible de la répartir sur plusieurs processeurs, puisque le kernel ne voit qu'une seule entité).
- Si elle apparait comme plusieurs processus, j'appelle ça du multiprocessus. Même si au niveau au-dessus, ça passe pour un "processus multi-thread", si pour le kernel c'est en réalité plusieurs processus, c'est du multiprocessus (même s'il est déguisé en multithread).
La question peut se poser aussi sous un noyau Windows selon les applications, mais lui peut voir trois choses différentes et non deux:
- Un seul processus monothreadé,
- Un seul processus multithreadé,
- Plusieurs processus, qu'ils soient monothreadés ou multithreadés.