MYSQL Client C utilisant WINSOCK uniquement

**mickno** · 16/02/2007, 10h28

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

**granquet** · 17/02/2007, 03h56

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 ...)

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 :

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
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

**David.Schris** · 17/02/2007, 04h02

Envoyé par Dark_Ebola

[...]

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
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

De se priver de WSACleanup() ?

**granquet** · 17/02/2007, 04h18

Envoyé par David.Schris

De se priver de WSACleanup() ?

corrigé

**Emmanuel Delahaye** · 17/02/2007, 04h23

Envoyé par Dark_Ebola

corrigé

http://emmanuel-delahaye.developpez....eaux.htm#psock

**David.Schris** · 17/02/2007, 04h29

Envoyé par Dark_Ebola

corrigé

Envoyé par Dark_Ebola

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

**granquet** · 17/02/2007, 04h47

Envoyé par David.Schris

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

c'est une erreur

re-corrigé

jvais aller me coucher moi ...

**mickno** · 17/02/2007, 10h20

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

**souviron34** · 17/02/2007, 13h40

je ferais juste une remarque en passant..

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...

**Médinoc** · 17/02/2007, 20h43

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).

**souviron34** · 18/02/2007, 03h32

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 :

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
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

**Emmanuel Delahaye** · 18/02/2007, 08h37

Envoyé par souviron34

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

http://emmanuel-delahaye.developpez.com/reseaux.htm

**Médinoc** · 18/02/2007, 09h58

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).

**Médinoc** · 18/02/2007, 10h04

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).

**souviron34** · 18/02/2007, 15h14

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 :

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
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....)

MYSQL Client C utilisant WINSOCK uniquement

Réseau C

Vue hybride

Discussions similaires

Partager

Partager