kyranet/veza

IPC/TCP Networking Utility to connect several processes with great concurrency.

Veza

About

Veza is a protocol that operates over either IPC or TCP with the only difference of one line of code to switch between the two. Inspired on node-ipc, it seeks to use modern, fast, and intuitive APIs, as well as exposing all the underlying back-ends for much higher customizability and extensibility, as well as a HTTP-like protocol where you can send a message and optionally receive a response for it.

Socket Support

• Unix Socket or Windows Socket.
• TCP Socket.
• TLS Socket.
• UDP Sockets.

TLS: TLS sockets can be achieved by extending Veza to use SSL handshakes. To keep things simple and tidy, this is not shipped in core, but will be considered for future releases.

UDP: UDP sockets are not supported due to Veza's requirement for messages to be reliably received in order.

Messaging

All messages are encoded and decoded using binarytf, which allows a messages to be sent using the least amount of bytes possible, increasing throughput; plus a 11-byte header at the start of each message. More information available in PROTOCOL.

Documentation

All the documentation is available at veza.js.org and at the wiki. You can find examples of code here.

Contributing

1. Fork it!
2. Create your feature branch: git checkout -b my-new-feature
3. Commit your changes: git commit -am 'Add some feature'
4. Push to the branch: git push origin my-new-feature
5. Submit a pull request!

Author

veza © kyranet, released under the MIT License. Authored and maintained by kyranet.

Github kyranet - Twitter @kyranet_

veza's Issues

can not auto-reconnect

Describe the issue

First of all, great project! 👍

When client connected to a server, force exit the server and restart a new server, then the client seems to entered an infinity loop, it can never do a successful handshake with the new server, just keep reconnecting.

and when this happening, the client leak the NodeMessage for handshake as an message event, so I keep getting a handshake message on every reconnecting.

Code or steps to reproduce

Server:

import { Server } from 'veza';

async function main(): Promise<void> {
  const name = 'my_server';
  console.log('name', name);

  const server = new Server(name);
  await server.listen({
    host: '127.0.0.1',
    port: 11122,
  });
  setInterval(async () => {
    console.log('broadcast!', server.sockets.size);
    await server.broadcast({ hello: 'world' });
  }, 2000);
}

main();

Client:

import { Client } from 'veza';

async function main(): Promise<void> {
  const name = 'my_client';
  console.log('name', name);

  const client = new Client(name);
  client.on('message', message => {
    // Shouldn't get a handshake message in here.
    console.log('message!', message);
    message.reply({ world: 'hello' });
  });
  await client.connectTo({
    host: '127.0.0.1',
    port: 11122,
  });
}

main();

1. start server
2. start client
3. ctrl+c stop the server
4. restart server

Expected and actual behavior

• The client should reconnect with the new server
• The client's message event should be emitted with a handshake message

Further details

• node.js version: 13.2.0
• veza version: 1.1.0
• I have tested the issue on latest master. Commit hash:

[Help Wanted] Documentation Pages

Describe the proposal

One of the steps to take Veza further and make it more accessible to more developers, is to add a documentation page with generation via Azure Pipelines to gh-pages.

Once it's ready, I'll request veza.js.org and the documentation will be accessible there.

[Help Wanted] Connection Handshake

Describe the proposal

Currently, Veza resolves Node#connectTo way early:

Process A:

• NodeSocket Calls Socket#connect.
• Socket emits private connect, resolving the internal promise.
• NodeSocket emits client.ready.
• Node#connectTo resolves.

Process B:

• NodeServer receives connection, creating a NodeServerClient.
• NodeServerClient listens to all internal events, sends Identify packet.
• NodeServerClient receives Process A's NodeSocket's name as a response for Identify.
• NodeServerClient emits client.identify.

---

The ideal way is, Node#connectTo should send the Identify packet, not the NodeServerClient, so both ends have their respective names.

This would also remove the parameter name from Node#connectTo, as it will be retrieved from the handshake.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update actions/checkout digest to ee0669b
• chore(deps): update actions/setup-node digest to 7c12f80
• chore(deps): update all non-major dependencies (@sapphire/eslint-config, @types/node, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, eslint, eslint-config-prettier, eslint-plugin-prettier, prettier, typedoc, typescript, yarn)
• chore(deps): update actions/checkout action to v4
• chore(deps): update actions/setup-node action to v4
• chore(deps): update typescript-eslint monorepo to v7 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

github-actions

.github/workflows/continuous-integration.yml

• actions/checkout v2@ec3a7ce113134d7a93b817d10a8272cb61118579
• actions/setup-node v2@1f8c6b94b26d0feae1e387ca63ccbdc44d27b561
• actions/checkout v2@ec3a7ce113134d7a93b817d10a8272cb61118579
• actions/setup-node v2@1f8c6b94b26d0feae1e387ca63ccbdc44d27b561

.github/workflows/labelsync.yml

• actions/checkout v4
• crazy-max/ghaction-github-labeler v5

npm

package.json

• binarytf ^2.1.3
• @sapphire/eslint-config ^5.0.2
• @sapphire/prettier-config ^2.0.0
• @sapphire/ts-config ^5.0.0
• @types/node ^20.8.9
• @typescript-eslint/eslint-plugin ^6.9.0
• @typescript-eslint/parser ^6.9.0
• eslint ^8.52.0
• eslint-config-prettier ^9.0.0
• eslint-plugin-prettier ^5.0.1
• prettier ^3.0.3
• standard-version ^9.5.0
• typedoc ^0.25.2
• typescript ^5.2.2
• yarn 4.0.1

---

• Check this box to trigger a request for Renovate to run again on this repository

bug: MessageError: Failed to process message during connection, calling disconnect: Unknown type received: 1 [UnknownType]

Is there an existing issue for this?

• I have searched the existing issues

Description of the bug

If i leave the connection on from some time, it throws this error and shuts the whole process down

Steps To Reproduce

Expected behavior

No errors

Screenshots

Additional context

No response

Readme typos

Describe the issue

There is a readme in typo. I suppose you wanted to say UDP but it became UPD instead

Line 52:
> **UPD**: UPD sockets are not supported due to Veza's requirement for messages to be reliably received in order.

[Help Wanted] Test Suite

Describe the proposal

I am planning to release [email protected] very soon, but before I do so, I want to ensure full functionality for all developers, for which we will need a test suite.

Currently, the code is tested in "parts" inside test files, then once they are working correctly, they are implemented into the code. A downside of this is, it does not test the implementation (or at least, not fully). And having one would definitely increase the speed of development since I will be able to automatize the tests and run them anytime with a single command, as opposed to editing some examples and test with them.

[Help Wanted] Rewrite to Strict TypeScript

Describe the issue

Veza already supports TypeScript via its typings, but it's support for TS could be greatly improved by rewriting it to strict TypeScript. This might as well fix some hidden bugs.

[Help Wanted] G-Zip piping

Describe the issue

Messages in veza could be heavily compressed by piping the data through g-zip, improving the message throughput and latency.

Can you please unblock me from discord.js?

I opened an "issue" on discord.js about slash command builder I've made, if something like that could be implemented in discord.js and you banned me because me and the other guy were replying to each other. Nobody else was chatting there the issue thread was pretty much dead and you had some issues. I want to report a bug for discord.js but I can't now. Either I open another github account or you can unblock me which I'd prefer. I'm sorry that you took it personally :/ I didn't mean it

Disconnect overriden veza nodes

Describe the issue

When a new node is created with the same name as an exiting node, it will override that one and start receiving messages, the old one should disconnect as it is now doing nothing.

Code or steps to reproduce

Using the hello.js/world.js example, you can add this to the server (hello.js)

setInterval(() => {
	node.broadcast("ping", { timeout: 5000, receptive: false }).then(console.log).catch(console.error);
}, 3000);

and then, in the client (world.js)

.on('message', (message) => {
	console.log('New message on client');
	console.log(message);
});

next, start the server, and run the world.js file twice

Expected and actual behavior

Further details

• node.js version:
• veza version:
• I have tested the issue on latest master. Commit hash:

[Help Wanted] Update examples

Describe the issue

[email protected] has released today, but some of the things are still in the works.

This shouldn't take long to update, since the breaking changes are really small.