2017-10-18 19 views
0

sous Debian 8 avec NodeJS 6 et jouent autour de la plate-forme IBM Watson IdO: https://github.com/ibm-watson-iot/iot-nodejsGarder objet de connexion NodeJS dans la base de données partagée/mémoire

J'ai créé une passerelle IBM, et sont en mesure pour se connecter et publier des données avec le code suivant:

var gatewayClient = new iotf.IotfGateway(config); 

gatewayClient.connect(); 

gatewayClient.on('connect', function(){ 
    gatewayClient.publishGatewayEvent("status","json",'{"d" : { "cpu" : 60, "mem" : 50 }}'); 

}); 

La configuration contient des informations uniques concernant ma passerelle unique.

Mon défi est maintenant, que je voudrais être en mesure de réutiliser ce gatewayClient dans d'autres instances de NodeJS. Donc, je pense à quelque chose comme ce qui suit (pseudo-code):

var gatewayClient = new iotf.IotfGateway(config); 
gatewayClient.connect(); 

sharedDatabase-perhaps-Redis[unique-gatewayClient-ID].push(gatewayClient); 

Et puis je peux appeler tout NodeJS sur le même serveur:

sharedDatabase-perhaps-Redis[unique-gatewayClient-ID].publishGatewayEvent("status","json",'{"d" : { "cpu" : 60, "mem" : 50 }}'); 

J'espère que ce sens, mais Je suis un peu confus si c'est archivable et comment, et si Redis pourrait être une solution ou une autre base de données-genre-de-chose. L'idée est de pouvoir garder la connexion active/persistante et de faire en sorte que les clients de différentes instances NodeJS transmettent des données via celle-ci, sans créer de nouvelles connexions.

Répondre

1

Les connexions réseau ne sont pas sérialisables et ne peuvent pas être facilement partagées entre les processus. Au lieu de cela, vous devriez envisager de créer un seul processus «maître» qui maintient la connexion avec le backend IBM et les clients communiqueront avec ce maître plutôt qu'avec IBM directement (pour les objets IoT, une méthode de communication commune utilise MQTT).

En outre, qu'est-ce qui vous empêche d'exécuter le code qui sera exécuté dans ces processus Node.js distincts en un seul processus? Cela résoudrait aussi le problème, car chaque pièce pourrait utiliser directement la connexion. D'après ce que je comprends, vous avez déjà un seul processus serveur qui accepte les messages client et devrait relayer ces messages au backend IBM. Pour chaque client unique, vous souhaitez créer une nouvelle connexion au backend ou réutiliser une connexion créée précédemment.

Vous pouvez utiliser quelque chose comme ça (gestion des erreurs retenu par souci de concision):

// Function to get the connection for a particular client id, 
// or, if one doesn't exist yet, create a new one. 

let clients = {}; 
function connectionForClient(uniqueGatewayClientID) { 
    // Check if we already have a connection for this client. 
    if (! clients[uniqueGatewayClientID]) 

    // No, create a new one, represented by a promise. 
    clients[uniqueGatewayClientID] = new Promise(function(resolve) { 
     let client = new iotf.IotfGateway(config); 

     client.connect(); 

     client.on('connect', function() { 
     resolve(client); 
     }); 
    }); 

    } 
    return clients[uniqueGatewayClientID]; 
} 

Pour utiliser:

connectionForClient(uniqueGatewayClientID).then(function(client) { 
    client.publishGatewayEvent("status","json",'{"d" : { "cpu" : 60, "mem" : 50 }}'); 
}); 
+0

Je mes périphériques publier des données JSON à mon application de NodeJS qui utilise Express pour écouter sur le port 80. Ces données doivent être envoyées à IBM via la connexion à la passerelle, qui peut ou non être établie. S'il est établi, il devrait être utilisé, si ce n'est pas le cas, il devrait être établi afin que d'autres puissent le réutiliser à l'avenir. –

+0

Oh, je pense que je vois ce que vous voulez dire maintenant: vous devez créer une nouvelle connexion pour chaque client unique. Laissez-moi y réfléchir un instant. – robertklep

+0

Ok, je pense que j'ai fait une démonstration maintenant où je fais simplement un tableau en dehors de mon Express où je stocke IBM gatewayClients. Et vérifiez ensuite isConnected lors de la réception d'un POST HTTP. Cela semble dû à l'astuce, mais la mise à l'échelle sur les serveurs (dans le futur) pourrait être difficile ... –