npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

node-easysocket

v1.1.0

Published

Nodes Socket Protocol

Downloads

24

Readme

node-easysocket Build Status

No more headcache! This is a (very) simple snippet to save your time with socket communication!

Best fit for you project:

This is a nice snippet for simple communications purposes. If you need a more robust communcation solution, please check: https://github.com/irineu/hachi-nio-js

Why node-easysocket?

It is simple! When you test a simple socket communication, in the more of times everything works fine, but when your project grouw up, after publish and test remote and bad connections, you will get some problems with truncated messages or messages with extra data (part of the next message). It is normal. You will need create a protocol to handle that situation, maybe implement a header or a terminator (bad ideia), maybe you are already frustated with that notice.

node-easysocket solution:

It is a efficient plug-n-play solution for not change your code too much :P

Write operation:

Just replace the convencional write logic:

socket.write('Hello World!');
socket.write('{"message":"Hello World!"}');

To the easy write logic:

easysocket.send(socket, 'Hello World!');
easysocket.send(socket, '{"message":"Hello World!}', function(socket) {
    console.log("Message with callback sent!");
});
Read operation:

Just replace the convencional read logic:

socket.on('data', function(data) {
    console.log("Recieved message: " + data);
});

To the easy read logic:

//That method will be called when the procol read a message
function handleMessage(socket,buffer){
    console.log(buffer.toString(),"length:"+buffer.length);
    
    //Yes! No more problems with incomplete json!
    //var myObj = JSON.parse(buffer.toString());
    //You can also work with protobufs
    //var myProtoObj = proto.MyProtoByLargeBinaryData.decode(buffer);
}
socket.on('data', function(data) {
    console.log("bytes in:"+data.length);
    easysocket.recieve(socket,data,handleMessage);
});
NOTE:
  1. If a chunk contains 5 messages, the method handleMessage will be called 5 times with the respective message.
  2. If a chunk contains 2 messages and a half, it will be called 2 times, and when the end of the message comes on next chunk, the method will be called.
  3. And YES! If the first message is too much large (but no more than ~2.1GB**) and be splitted in many chunks, the handleMessage will be called only full message reach ;)
Limitations:

The embedded protocol use a header with 4 bytes to indicate the size of your message, so you can only send a message with: 2147483647 bytes (~2.1GB). If you need more than it, just fork this project on github and expand to fit your needs.