MYSQL Client C utilisant WINSOCK uniquement

**Emmanuel Delahaye** · 18/02/2007, 15h55

Envoyé par David.Schris

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

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

**souviron34** · 19/02/2007, 00h48

Envoyé par David.Schris

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

ben que crois-tu qu'est :

Code :

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

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

**souviron34** · 19/02/2007, 01h15

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

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

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

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

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

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.

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

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

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

**Emmanuel Delahaye** · 19/02/2007, 06h05

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

**Médinoc** · 19/02/2007, 09h08

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

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

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.

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.

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.

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.

**souviron34** · 19/02/2007, 12h31

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

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 :

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 :

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

**Médinoc** · 19/02/2007, 14h09

Envoyé par souviron34

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

Alors là pas du tout d'accord

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.

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

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

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

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

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

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.

**DaZumba** · 19/02/2007, 14h15

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

**souviron34** · 19/02/2007, 14h19

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 :

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 :

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.

**souviron34** · 19/02/2007, 16h18

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 (

) associé : le MPI.

http://www-unix.mcs.anl.gov/mpi/

**Médinoc** · 19/02/2007, 16h58

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

**souviron34** · 19/02/2007, 17h21

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 ?

**Médinoc** · 19/02/2007, 17h45

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.

MYSQL Client C utilisant WINSOCK uniquement

Réseau C

Discussions similaires

Partager

Partager