Discussion :

[mickno]

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]

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]

[...]

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]

De se priver de WSACleanup() ?

corrig�

[Emmanuel Delahaye]

corrig�

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

[David.Schris]

corrig�

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]

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

c'est une erreur
re-corrig�

jvais aller me coucher moi ...

[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

[souviron34]

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

[Emmanuel Delahaye]

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.

[souviron34]

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

[Emmanuel Delahaye]

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.

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

[souviron34]

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]

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

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

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

[M�dinoc]

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]

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

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

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?

[David.Schris]

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

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