Le contrôle Winsock, invisible à l'utilisateur, permet aux développeurs sous Microsoft Access, Visual Basic, Visual C++ ou Visual FoxPro, d'accéder facilement aux services de réseau TCP (Transfer Control Protocol) et UDP (User Datagram Protocol). Il n'est pas nécessaire de comprendre tous les détails d'une connexion TCP, ni de faire appel aux API Winsock de bas niveau pour écrire des applications client ou serveur. Il suffit de définir les propriétés et d'invoquer les méthodes du contrôle pour assurer la connexion vers une machine distante et pouvoir échanger des données dans l'une ou l'autre direction.

Éléments fondamentaux du protocole TCP

Le protocole de contrôle de transfert (TCP, Transfer Control Protocol) vous permet d'établir et de maintenir une connexion vers un ordinateur distant, qui permet aux deux ordinateurs d'échanger des données.

Pour créer une application client, vous devez connaître le nom de l'ordinateur serveur ou son adresse IP (propriété RemoteHost), ainsi que le port (propriété RemotePort) sur lequel il "sera à l'écoute", puis invoquer la méthode Connect.

Pour créer une application serveur, définissez le port (propriété LocalPort) de communication, et invoquez la méthode Listen. L'événement ConnectionRequest sera déclenché lorsque l'ordinateur client demandera une connexion. L'appel de la méthode Accept au sein de l'événement ConnectionRequest permet d'établir la connexion.

Une fois la connexion réalisée, chacun des ordinateurs peut envoyer et recevoir des données. La méthode SendData permet d'envoyer des données. À la réception des données, l'événement DataArrival se produit. L'appel de la méthode GetData dans l'événement DataArrival permet de récupérer les données.

Éléments fondamentaux du protocole UDP

Le protocole utilisateur Datagram (UDP, User Datagram Protocol) est un protocole sans connexion. Contrairement aux opérations TCP, les ordinateurs n'établissent pas de connexion. Une application UDP peut donc être client ou serveur.

Pour transmettre des données, définissez d'abord la propriété LocalPort de l'ordinateur client. L'ordinateur serveur doit alors affecter l'adresse Internet de l'ordinateur client à la propriété RemoteHost, et affecter à RemotePort le même port que celui attribué à la propriété LocalPort de l'ordinateur client, puis invoquer la méthode SendData pour commencer l'envoi de messages. L'ordinateur client utilise alors la méthode GetData dans l'événement DataArrival pour récupérer les messages envoyés.

Va voir l'aide de Winsock dans VB:

Quel genre de client/serveur veut tu faire ?

Le genre d'applications n-tiers avec le poste client, le serveur Web, le serveur de traitement et le serveur de données ou quelquechose qui va dans le sens des réponses précedentes.

C'est pas client serveur ça, c'est client léger. Il n'y a pas de logique d'affaire sur le poste. Pour une application c/s il y a une application de déployé sur chacun des postes, donc lors d'une nouvelle version elle doit être redéployer ce qui n'est pas le cas pour un client léger.

Client-serveur, client léger, ce n'est qu'une question de terminologie.
D'un organisme à l'autre, le nom qu'on donne varie quelque peu mais à la base, ça reste une architecture en couche de 2 à n couches. Très souvent dans les discussions j'entends les expressions "client-serveur Web" et "client-serveur VB". Les gens ajoutent le terme Web ou VB en parlant de la technologie qui sera utilisé pour réalisé l'interface utilisateur.