Socket
Socket
Sign inDemoInstall

cote

Package Overview
Dependencies
58
Maintainers
1
Versions
88
Alerts
File Explorer

Advanced tools

Install Socket

Detect and block malicious and high-risk dependencies

Install

Comparing version 0.20.0 to 0.20.1

4

dist/components/requester.js

@@ -114,2 +114,6 @@ "use strict";

const timeoutHandle = setTimeout(() => {
// Remove the request from the request queue so that it's not sent to responders (#183)
const req = sock.queue.findIndex(r => r[r.length - 1] == messageCallback);
if (req > -1) sock.queue.splice(req, 1); // Remove the request callback
delete sock.callbacks[messageCallback.id];

@@ -116,0 +120,0 @@ cb(new Error('Request timed out.'));

4

package.json
{
"name": "cote",
"version": "0.20.0",
"version": "0.20.1",
"keywords": [

@@ -41,3 +41,3 @@ "microservices",

"eventemitter2": "5.0.1",
"lodash": "^4.17.11",
"lodash": "^4.17.15",
"portfinder": "1.0.20",

@@ -44,0 +44,0 @@ "socket.io": "2.2.0",

@@ -11,2 +11,3 @@ ![cote](https://user-images.githubusercontent.com/698308/32996603-1517088a-cd85-11e7-85c5-8ef9b3ae2e49.png)

[![GitHub license](https://img.shields.io/badge/license-MIT-blue.svg)](https://raw.githubusercontent.com/dashersw/cote/master/LICENSE)
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fdashersw%2Fcote.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fdashersw%2Fcote?ref=badge_shield)

@@ -76,3 +77,2 @@ **cote lets you write zero-configuration microservices in Node.js without nginx,

+ Docker compose configuration for running the system locally
+ Docker cloud configuration for running the system in Docker Cloud

@@ -915,3 +915,3 @@ cote plays very well with Docker, taking advantage of its network overlay

```
To connect publisher and sockend, you need to add `broadcasts:` parameter to your options
To connect publisher and sockend, you need to add `broadcasts:` parameter to your options

@@ -942,3 +942,3 @@ ```js

You can check complete code for `Responder`s and `Publisher`s in the `examples` folder. Fire them up
You can check complete code for `Responder`s and `Publisher`s in the `examples` folder. Fire them up
on default or 'rnd' namespace and watch them glow with magic on

@@ -1047,12 +1047,28 @@ `http://localhost:5555`.

Since every component discovers and tries to communicate with every other
component on the horizon (this is called a "mesh network"), it might be
desirable to tune the performance of an application by grouping certain
components together over the use of a `key`.
component on the horizon (this is called a "mesh network"), if different
services request and respond to different types of messages, you will
experience lost messages. In other words, if service A responds to messages X
and Y, and service B responds to messages Z and T, you will lose half of the
messages, because messages Z and T will also end up at service A, but it won't
know how to handle them. The same is true for service B: messages X and Y
will end up at it, but service B won't know how to respond to them.
Keys are useful in this scenario: requesters and responders around service A
and messages X and Y should use one particular key, and requesters and
responders around service B and messages Z and T should use another key. In
this case, no messages will be lost, and the services will be segregated.
In our experience, the best way to segregate services is to follow the
principles of domain-driven design. In this regard, for example, each domain
could have its own `key`.
could have its own `key`. If you need more granular services, you should use
multiple keys inside the same domain. The principle is to ensure distinct keys
for a distinct set of messages. In other words, keys should represent a
distinct set of requests.
`key`s are are also given as parameters to the configuration objects.
Please refer to [Creating the arbitration service]
(https://github.com/dashersw/cote#creating-the-arbitration-service) for an
example of keys in action.
`key`s are given as parameters to the configuration objects.
When deciding whether to create a connection to another service, cote components

@@ -1225,3 +1241,2 @@ make use of `key`s and `environment`s together. Therefore, two components with

| `COTE_BROADCAST_ADDRESS` | See [Broadcast address](#broadcast-address).
| `DOCKERCLOUD_IP_ADDRESS` | Default broadcast address in Docker Cloud is `10.7.255.255`. Passing any value to this variable will change default broadcast value from `255.255.255.255` to `10.7.255.255`. This setting shouldn't be changed by users, but rather is there to make cote play extremely well with Docker Cloud.
| `COTE_USE_HOST_NAMES` | In certain, extremely rare conditions, auto-discovery might fail due to components reporting wrong IP addresses. If you find out that is the case, you can command cote to use the reported host names instead.

@@ -1231,2 +1246,3 @@ | `COTE_DISCOVERY_REDIS` | See [Using centralized discovery tools](#using-centralized-discovery-tools).

| `COTE_DISCOVERY_REDIS_HOST` | See [Using centralized discovery tools](#using-centralized-discovery-tools).
| `DISCOVERY_HOSTNAME` | See [Using centralized discovery tools](#using-centralized-discovery-tools).
| `COTE_REQUEST_TIMEOUT` | See [Requester Timeout](#timeout).

@@ -1241,3 +1257,3 @@ | `COTE_LOG` | Boolean. Whether to display hello and status logs for other discovered services. Has precedence over `COTE_STATUS_LOGS_ENABLED` and `COTE_HELLO_LOGS_ENABLED`.

## Deploying with Docker Cloud
## Deploying with Docker Cloud (deprecated)

@@ -1265,5 +1281,5 @@ cote plays extremely well with Docker Cloud. Even if your cloud provider doesn't

cote is built to be zero-configuration, and relies on IP broadcast/multicast
to work. However, as of 2017, cloud providers don't support this functionality
out of the box. In these cases, one can use Docker Cloud and its Weave network
integration. However, Docker Cloud may not be suitable for everyone, due to
to work. cloud providers don't support this functionality (and they won't)
out of the box. In these cases, one can use the Weave network overlay
integration. However, this may not be suitable for everyone, due to
varying reasons.

@@ -1274,3 +1290,3 @@

In these cases, in order to let cote work, we developed a plugin mechanism to
accomodate different solutions that can serve as the automated service
accommodate different solutions that can serve as the automated service
discovery tool. Currently, redis is supported out of the box, and cote

@@ -1283,2 +1299,6 @@ makes use of the [node_redis](https://github.com/NodeRedis/node_redis)

You should also set `DISCOVERY_HOSTNAME` to the **IP address**
of the container/instance since it defaults to machine's hostname which in
most cloud/docker setups is not routable.
### Configuring redis

@@ -1304,6 +1324,7 @@

| --------------------------: | :---------- |
| COTE_DISCOVERY_REDIS | If you are running redis on localhost, setting this variable to true will use the locally available redis at port 6379. If you need any other redis URL or host, you don't need to use this variable.
| COTE_DISCOVERY_REDIS_URL | Sets the redis connection URL. Has to start with either `redis://` or `//`. Enables the redis plugin.
| COTE_DISCOVERY_REDIS_HOST | Sets the redis connection host name. Enables the redis plugin.
| COTE_DISCOVERY_REDIS_PORT | Sets the redis connection port. Enables the redis plugin.
| `COTE_DISCOVERY_REDIS` | If you are running redis on localhost, setting this variable to true will use the locally available redis at port 6379. If you need any other redis URL or host, you don't need to use this variable.
| `COTE_DISCOVERY_REDIS_URL` | Sets the redis connection URL. Has to start with either `redis://` or `//`. Enables the redis plugin.
| `COTE_DISCOVERY_REDIS_HOST` | Sets the redis connection host name. Enables the redis plugin.
| `COTE_DISCOVERY_REDIS_PORT` | Sets the redis connection port. Enables the redis plugin.
| `DISCOVERY_HOSTNAME` | This defaults to your machine's `hostname`. If this is not routable you need to set this to the routable IP address of this instance.

@@ -1317,3 +1338,3 @@ cote also supports other connection options supported by

```sh
COTE_DISCOVERY_REDIS_HOST=redis node service.js
COTE_DISCOVERY_REDIS_HOST=redis DISCOVERY_HOSTNAME=127.0.0.1 node service.js
```

@@ -1374,6 +1395,5 @@

network. For this purpose, Docker is the best tool. Deploy your application in
Docker containers and you can take advantage of its overlay networks. cote works
out of the box with Docker Cloud and users of Docker Swarm can make use of the
[Weave Net plugin](https://www.weave.works/docs/net/latest/plugin-v2/). Weave
also has [an addon](https://www.weave.works/docs/net/latest/kube-addon/) for
Docker containers and you can take advantage of its overlay networks. Users of
Docker Swarm can make use of the [Weave Net plugin](https://www.weave.works/docs/net/latest/plugin-v2/).
Weave also has [an addon](https://www.weave.works/docs/net/latest/kube-addon/) for
enabling multicast/broadcast for Kubernetes.

@@ -1423,1 +1443,3 @@

SOFTWARE.
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fdashersw%2Fcote.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fdashersw%2Fcote?ref=badge_large)

Sorry, the diff of this file is not supported yet

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc