Langage Q - Communication inter-processus

KDB + permet à un processus de communiquer avec un autre processus via une communication interprocessus. Les processus Kdb + peuvent se connecter à n'importe quel autre kdb + sur le même ordinateur, le même réseau ou même à distance. Nous avons juste besoin de spécifier le port et ensuite les clients peuvent parler à ce port. Toutq processus peut communiquer avec tout autre q tant qu'il est accessible sur le réseau et qu'il écoute les connexions.

  • un processus serveur écoute les connexions et traite toutes les demandes

  • un processus client initie la connexion et envoie des commandes à exécuter

Le client et le serveur peuvent être sur la même machine ou sur des machines différentes. Un processus peut être à la fois un client et un serveur.

Une communication peut être,

  • Synchronous (attendez qu'un résultat soit renvoyé)

  • Asynchronous (pas d'attente et aucun résultat renvoyé)

Initialiser le serveur

UNE q le serveur est initialisé en spécifiant le port d'écoute,

q –p 5001 / command line
\p 5001   / session command

Poignée de communication

Un descripteur de communication est un symbole qui commence par «:» et a la forme -

`:[server]:port-number

Exemple

`::5001              / server and client on same machine
`:jack:5001          / server on machine jack
`:192.168.0.156      / server on specific IP address
`:www.myfx.com:5001  / server at www.myfx.com

Pour démarrer la connexion, nous utilisons la fonction «hopen» qui renvoie un descripteur de connexion entier. Ce handle est utilisé pour toutes les demandes client ultérieures. Par exemple -

q)h:hopen `::5001

q)h"til 5"
0 1 2 3 4

q)hclose h

Messages synchrones et asynchrones

Une fois que nous avons un handle, nous pouvons envoyer un message de manière synchrone ou asynchrone.

Synchronous Message- Une fois qu'un message est envoyé, il attend et renvoie le résultat. Son format est le suivant -

handle “message”

Asynchronous Message- Après l'envoi d'un message, commencez immédiatement à traiter l'instruction suivante sans avoir à attendre et renvoyer un résultat. Son format est le suivant -

neg[handle] “message”

Les messages qui nécessitent une réponse, par exemple des appels de fonction ou des instructions de sélection, utiliseront normalement la forme synchrone; tandis que les messages qui n'ont pas besoin de renvoyer une sortie, par exemple l'insertion de mises à jour dans une table, seront asynchrones.