UCOMmandIt/uci-socket

Fork 0

TCP socket(server) and client(consumer) modules using the UCI packet format for communication. Primary a dependent of the UCI base module

Find a file

David Kebler 18a65b42c5 0.2.22 add active getter emit status active when connect state changes		2019-11-21 10:04:48 -08:00
examples	0.2.20 emit status events in consumer	2019-09-08 19:49:35 -07:00
src	0.2.22	2019-11-21 10:04:48 -08:00
test	upgrade to esm from @std/esm	2018-05-16 07:21:51 -07:00
.eslintrc.js	0.2.18 Major refactor of consumer/client. Initial connect with promise resolution now separate from listening and reconnect handling. Added server ping and conusmer ping monitoring to know when to try a reconnect. Other errors will give a reconnect as well.	2019-08-20 10:52:02 -07:00
.gitignore	bind close method	2019-03-17 13:51:36 -07:00
.npmignore	0.2.11 refactored consumer connect/reconnect to be more robust	2019-04-12 08:00:45 -07:00
.travis.yml	initial commit	2017-12-21 15:50:05 -08:00
package.json	0.2.22	2019-11-21 10:04:48 -08:00
readme.md	removed context processing from modules (will be done in uci-base)	2018-01-30 17:49:31 -08:00

readme.md

UComandIt Extenson of Nodejs `net` `Socket` and `Server` classes

What is it

the Server and Socket Classes in the 'net' package are rudimentary. This library extends these two classes into something more useable and robust. I have changed the class name convention to make more "sense" (at least to me). Server extends to Socket and Socket extends to Consumer With these you then .create() a Socket instance and .connect() a Consumer instance to a Socket instance.

Both sockets by default stream JSON objects between each other better know as packets. The properties of these json packets can then be used to do all manner of processing at either the socket or consumer end. The classes allow attaching a custom packet processor (MQTT if you so desire). See @uci/base for an example of extending these classes with a particular processor that supports a simple 'cmd' packet property protocol for calling functions at either the socket or the consumer.

TL/DR;

See the one server and two client files in the /examples folder, Fire up the server file and then in another termial one of the two client files.

Note: these are ES6 (.mjs) modules you must either

use -r @std/esm when running as in node -r @std/esm server or
must use babel or the like.

This repo DOES NOT provide a /dist folder with preprocessed ES6 since as of node 9+ ES6 modules (.mjs) mixed with CommonJS (.js) are supported with the @std/esm flag.

What's it good for

With the two classes you can create either an IPC(Unix) or TCP socket/consumer. This means you can have inter process communication between the processes on one machine (Unix) and at the same time send/receive packets to processes on other machines (TCP). See UCI's base repo for a class which allows you to make intances that do that.

Why Bother

You could just start with the net classes like I did but look but I've made a number of useful additions without creating a lot of dependencies. Iv'e made it super easy to fire off instances with sensible defaults, socket data stream chunking and processing of JSON to/from JS objects, consumer connect retry, registering custom packet processor.

On the flip side you could just use the MQTT repos but they require running a broker and there is a lot of overhead before you get down to doing something with the packet you just sent and received. That's really overkill and slow for IPC on the same machine. It's even overkill for direct TCP communication between a couple SBCs in local system. Still since you can change the packet processor with a register command it's easy to process MQTT packets with these classes.