nanomsg library

Overview

Welcome to nanomsg

Release MIT License Linux Status Windows Status Coverage Gitter

The nanomsg library is a simple high-performance implementation of several "scalability protocols". These scalability protocols are light-weight messaging protocols which can be used to solve a number of very common messaging patterns, such as request/reply, publish/subscribe, surveyor/respondent, and so forth. These protocols can run over a variety of transports such as TCP, UNIX sockets, and even WebSocket.

For more information check the website.

Prerequisites

  1. Windows.

    • Windows Vista or newer (Windows XP and 2003 are NOT supported)
    • Microsoft Visual Studio 2010 (including C++) or newer, or mingw-w64. (Specifically mingw and older Microsoft compilers are *NOT supported, and we do not test mingw-w64 at all, so YMMV.)
    • CMake 2.8.7 or newer, available in $PATH as cmake
  2. POSIX (Linux, MacOS X, UNIX)

    • ANSI C compiler supporting C89
    • POSIX pthreads (should be present on all modern POSIX systems)
    • BSD sockets support for both TCP and UNIX domain sockets
    • CMake (http://cmake.org) 2.8.7 or newer, available in $PATH as cmake
  3. Documentation (optional)

Quick Build Instructions

These steps here are the minimum steps to get a default Debug build. Using CMake you can do many other things, including setting additional variables, setting up for static builds, or generation project or solution files for different development environments. Please check the CMake website for all the various options that CMake supports.

POSIX

This assumes you have a shell in the project directory, and have the cmake and suitable compilers (and any required supporting tools like linkers or archivers) on your path.

  1. % mkdir build
  2. % cd build
  3. % cmake ..
  4. % cmake --build .
  5. % ctest .
  6. % sudo cmake --build . --target install
  7. % sudo ldconfig (if on Linux)

Windows

This assumes you are in a command or powershell window and have the appropriate variables setup to support Visual Studio, typically by running vcvarsall.bat or similar with the appropriate argument(s). It also assumes you are in the project directory.

  1. md build
  2. cd build
  3. cmake ..
  4. cmake --build . --config Debug
  5. ctest -C Debug .
  6. cmake --build . --config Debug --target install NB: This may have to be done using an Administrator account.

Alternatively, you can build and install nanomsg using vcpkg dependency manager:

  1. git clone https://github.com/Microsoft/vcpkg.git
  2. cd vcpkg
  3. ./bootstrap-vcpkg.bat
  4. ./vcpkg integrate install
  5. ./vcpkg install nanomsg

The nanomsg port in vcpkg is kept up to date by microsoft team members and community contributors. If the version is out of date, please create an issue or pull request on the vcpkg repository.

Static Library

We normally build a dynamic library (.so or .DLL) by default.

If you want a static library (.a or .LIB), configure by passing -DNN_STATIC_LIB=ON to the first cmake command.

POSIX

POSIX systems will need to link with the libraries normally used when building network applications. For some systems this might mean -lnsl or -lsocket.

Windows

You will also need to define NN_STATIC_LIB in your compilation environment when building programs that use this library. This is required because of the way Windows changes symbol names depending on whether the symbols should be exported in a DLL or not.

When using the .LIB on Windows, you will also need to link with the ws2_32, mswsock, and advapi32 libraries, as nanomsg depends on them.

Support

This library is considered to be in "sustaining" mode, which means that new feature development has ended, and bug fixes are made only when strictly necessary for severe issues.

New development is now occurring in the NNG project, which offers both protocol and API compatibility with this project. Please consider using NNG for new projects.

Please see the file SUPPORT for more details.

Resources

Website: http://nanomsg.org

Source code: https://github.com/nanomsg/nanomsg

Documentation: http://nanomsg.org/documentation.html

Bug tracker: https://github.com/nanomsg/nanomsg/issues

Mailing list: [email protected]

Gitter Chat: https://gitter.im/nanomsg/nanomsg

IRC chatroom: #nanomsg at irc.freenode.net/8001

Comments
  • Change from malloc to calloc

    Change from malloc to calloc

    changes to make sure that the alloced memory block is zero filled, takes a little more time but ALWAYS worth it.. to keep garbage out of the memory block.

    These changes are submitted under the MIT License

    opened by marchon 50
  • Memory leak on nn_send from REQ endpoint

    Memory leak on nn_send from REQ endpoint

    nn_device is seen to fail, where the client will receive 4 bytes too many (probably the request ID) from the server when used over a device.

    Please read down til near the end, to get the full details; the history of messages that led us to this conclusion is -- convoluted.

    Original description (which ultimately led to this bug, below):

    Using req/rep model, on NN_REQ enpoint I send messages with nn_send(..., NN_DONTWAIT) and wait for NN_POLLIN event of nn_poll with dynamic timeout. If nothing recieved, another message can be send after some time (during which the response to the previous can come). If the response really comes, then we have a memory leak. At least, it looks like this. The workaround is call of nn_recv(..., NN_DONTWAIT) just before any nn_send; but it seems strange.

    opened by romanoved 43
  • Providing test to demonstrate hang in nn_close on websocket transport

    Providing test to demonstrate hang in nn_close on websocket transport

    This test demonstrates an occasional hang (at least on Windows) on line 100 when the PUB socket is closed. Creating PR in order to kick off automated builds on other platforms to see if they fail here as well, or if it is limited to just Windows.

    This only appears to hang on the WebSocket transport. This could be just a problem with the WebSocket transport implementation (the most likely scenario), or it could be because the WebSocket transport incidentally requires more time to connect and perhaps disconnect sockets, as compared to say TCP, and is thus more likely to trigger a race condition.

    opened by JackDunaway 41
  • Nanomsg an order of magnitude slower than zmq

    Nanomsg an order of magnitude slower than zmq

    I thought nanomsg is supposed to be faster than zmq, but when I tested on my Thinkpad W520 running Centos6.4, I was very surprised to find out that it was an order of magnitude slower.

    Here is my program:

    #include "../src/nn.h"
    #include "../src/pair.h"
    #include <cstdio>
    #include <unistd.h>
    #include <cstring>
    #include <cassert>
    #include <pthread.h>
    #include <sys/time.h>
    
    void* Send(void* context)
    {
        int responder = nn_socket(AF_SP, NN_PAIR);
        assert(responder != -1);
        int rc = nn_connect(responder, "inproc://test");
        assert(rc >= 0);
    
        char buf[1024];
        unsigned long bytes = 0;
        int sz[] = { 16,32,64,96,128,160,192,224,256,384,512,768,1024};
        int p =0;
        for (unsigned count = 1048576; count--;)
        {
        unsigned len = sz[p];
            nn_send(responder, buf, len, 0);
        bytes += len;
        p = (p+1) % (sizeof(sz)/sizeof(sz[0]));
        }
        nn_send(responder, buf, 0, 0);
        printf("sent %lu bytes\n", bytes);
        nn_close(responder);
        return NULL;
    }
    
    
    void* Receive(void* arg)
    {
        int receiver = (long)arg;
        char buf[1024];
        unsigned long bytes = 0;
        while (1)
        {
            int len = nn_recv(receiver, buf, sizeof(buf), 0);
        if (!len)
            break;
        if (len < 0)
        {
            perror("zmq_recv");
            break;
        }
        bytes += len;
        }
        printf("received %lu bytes\n", bytes);
        return NULL;
    }
    
    int main ()
    {
        int receiver = nn_socket(AF_SP, NN_PAIR);
        assert(receiver != -1);
        int rc = nn_bind(receiver, "inproc://test");
        assert(rc >= 0);
    
        struct timeval tv;
        gettimeofday(&tv, NULL);
        unsigned long t0 = tv.tv_usec + tv.tv_sec * 1000000;
    
        pthread_t th;
        pthread_create(&th, NULL, Receive, (void*)receiver);
        Send(NULL);
        void* ret;
        pthread_join(th, &ret);
    
        gettimeofday(&tv, NULL);
        unsigned long t = tv.tv_usec + tv.tv_sec * 1000000 - t0;
        printf("elapsed=%.3f\n", t/1000000.);
        return 0;
    }
    

    On my Thinkpad W520, it takes about 3.6-4.3s to run; whereas a similar version using zmq only took 0.4s. Can someone please point out what I did wrong? Thanks!

    opened by wuz73 37
  • Mac OS X: assertion failed (aio_posix.inc)

    Mac OS X: assertion failed (aio_posix.inc)

    I have written a small echo client/server example in LuaJIT. It runs fine on Linux but on OS X I sometimes have the following error on the client side:

    Assertion failed: errno == ECONNRESET || errno == ETIMEDOUT || errno == EPIPE (/[...]/nanomsg/src/utils/aio_posix.inc:779)
    Abort trap: 6
    

    The error occurs on that line (nn_recv).

    opened by catwell 36
  • assertion failure (NN_QUEUE_NOTINQUEUE)

    assertion failure (NN_QUEUE_NOTINQUEUE)

    Assertion failed: self->next == NN_QUEUE_NOTINQUEUE (/home/mike/nanomsg/src/utils/queue.c:78)

    Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff1e37700 (LWP 2527)] 0x00007ffff707f425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff707f425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff7082b8b in __GI_abort () at abort.c:91 #2 0x00007ffff795d379 in nn_err_abort () from /usr/local/lib/libnanomsg.so.0.0.0 #3 0x00007ffff795e3ec in nn_queue_item_term () from /usr/local/lib/libnanomsg.so.0.0.0 #4 0x00007ffff795bf9f in nn_worker_task_term () from /usr/local/lib/libnanomsg.so.0.0.0 #5 0x00007ffff7959457 in nn_usock_term () from /usr/local/lib/libnanomsg.so.0.0.0 #6 0x00007ffff796af36 in nn_aipc_term () from /usr/local/lib/libnanomsg.so.0.0.0 #7 0x00007ffff796bceb in nn_bipc_handler () from /usr/local/lib/libnanomsg.so.0.0.0 #8 0x00007ffff795789e in nn_fsm_event_process () from /usr/local/lib/libnanomsg.so.0.0.0 #9 0x00007ffff795763b in nn_ctx_leave () from /usr/local/lib/libnanomsg.so.0.0.0 #10 0x00007ffff795c53f in nn_worker_routine () from /usr/local/lib/libnanomsg.so.0.0.0 #11 0x00007ffff795e8d4 in nn_thread_main_routine () from /usr/local/lib/libnanomsg.so.0.0.0 #12 0x00007ffff56efe9a in start_thread (arg=0x7ffff1e37700) at pthread_create.c:308 #13 0x00007ffff713cccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #14 0x0000000000000000 in ?? ()

    (gdb)

    on another thread: Assertion failed: 0 (/home/mike/nanomsg/src/transports/utils/streamhdr.c:284)

    Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff1e37700 (LWP 2533)] 0x00007ffff707f425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff707f425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff7082b8b in __GI_abort () at abort.c:91 #2 0x00007ffff795d379 in nn_err_abort () from /usr/local/lib/libnanomsg.so.0.0.0 #3 0x00007ffff7968962 in nn_streamhdr_handler () from /usr/local/lib/libnanomsg.so.0.0.0 #4 0x00007ffff795789e in nn_fsm_event_process () from /usr/local/lib/libnanomsg.so.0.0.0 #5 0x00007ffff795763b in nn_ctx_leave () from /usr/local/lib/libnanomsg.so.0.0.0 #6 0x00007ffff795c53f in nn_worker_routine () from /usr/local/lib/libnanomsg.so.0.0.0 #7 0x00007ffff795e8d4 in nn_thread_main_routine () from /usr/local/lib/libnanomsg.so.0.0.0 #8 0x00007ffff56efe9a in start_thread (arg=0x7ffff1e37700) at pthread_create.c:308 #9 0x00007ffff713cccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x0000000000000000 in ?? ()

    (gdb)

    another: Assertion failed: self->next == NN_QUEUE_NOTINQUEUE (/home/mike/nanomsg/src/utils/queue.c:78)

    Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff1e37700 (LWP 2539)] 0x00007ffff707f425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff707f425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff7082b8b in __GI_abort () at abort.c:91 #2 0x00007ffff795d379 in nn_err_abort () from /usr/local/lib/libnanomsg.so.0.0.0 #3 0x00007ffff795e3ec in nn_queue_item_term () from /usr/local/lib/libnanomsg.so.0.0.0 #4 0x00007ffff795bf9f in nn_worker_task_term () from /usr/local/lib/libnanomsg.so.0.0.0 #5 0x00007ffff7959457 in nn_usock_term () from /usr/local/lib/libnanomsg.so.0.0.0 #6 0x00007ffff796af36 in nn_aipc_term () from /usr/local/lib/libnanomsg.so.0.0.0 #7 0x00007ffff796bceb in nn_bipc_handler () from /usr/local/lib/libnanomsg.so.0.0.0 #8 0x00007ffff795789e in nn_fsm_event_process () from /usr/local/lib/libnanomsg.so.0.0.0 #9 0x00007ffff795763b in nn_ctx_leave () from /usr/local/lib/libnanomsg.so.0.0.0 #10 0x00007ffff795c53f in nn_worker_routine () from /usr/local/lib/libnanomsg.so.0.0.0 #11 0x00007ffff795e8d4 in nn_thread_main_routine () from /usr/local/lib/libnanomsg.so.0.0.0 #12 0x00007ffff56efe9a in start_thread (arg=0x7ffff1e37700) at pthread_create.c:308 #13 0x00007ffff713cccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #14 0x0000000000000000 in ?? ()

    (gdb)

    code:

    int main(int argc, char *argv[]) { void *data = NULL; int r_len = 0; int timeout = 1000; unsigned char *s_data = NULL; int s_len = 0; int s; int a; int len; int _time=time(0); int i; int found_command=0; char file[1024]; char ipc[1024]; int ipc_num = 0;

    if (argc > 1) {
        ipc_num = atoi(argv[1]) + 1;
    } else ipc_num = 1;
    
    if (strstr(argv[0], "curl") || strstr(argv[0], "adreplace")) {
        sprintf(file, "/tmp/curl%d.ipc", ipc_num);
        sprintf(ipc, "ipc:///tmp/curl%d.ipc", ipc_num);
    
    } else {
        sprintf(file, "/tmp/adserver%d.ipc", ipc_num);
        sprintf(ipc, "ipc:///tmp/adserver%d.ipc", ipc_num);
    }
    
    // initialize mysql
    init();
    //mysql_reopen();
    s = nn_socket(AF_SP, NN_REP);
    nn_setsockopt(s, NN_SOL_SOCKET, NN_RCVTIMEO, &timeout, sizeof(timeout));
    nn_setsockopt(s, NN_SOL_SOCKET, NN_SNDTIMEO, &timeout, sizeof(timeout));
    a = nn_bind(s, ipc);
    chmod(file, 0777);
    
    printf("Bound to IPC: %s\n", ipc);
    
    _time = time(0);
    while (1) {
    
        s_len = 0;
        s_data = NULL;
        found_command=0;
    
        len = nn_recv(s, &data, NN_MSG, 0);
    

    // if (len) { if (data && ((unsigned)len >= (unsigned)sizeof(NanoPkt))) { // do whatever with data here... always be sure to set s_data, and s_len NanoPkt _pkthdr = (NanoPkt *)data; printf("NN recv len %d nanopkt cmd %d nanopkt len %d - %d %d %d\n", len, pkthdr->type, pkthdr->len, sizeof(Genreplace_Req), sizeof(Findrep_Req), sizeof(Final_Req)); for (i = 0; Commands[i].func != NULL; i++) { if (pkthdr->type == Commands[i].type) { (_Commands[i].func)((unsigned char *)data, len, &s_data, &s_len); found_command=1; break; } }

            printf("FOund command: %d\n", found_command);
    
            // just in case something went wrong.. we have to return something or we will force a stall
            if (s_data == NULL || !s_len) {
                //printf("sending null\n");
                nn_send(s, "NULL", 4, 0);
            } else {
                //printf("sending %d bytes of real data %p\n", s_len, s_data);
                nn_send(s, s_data, s_len, 0);
    

    // free(s_data); } // nn_freemsg(data); data = NULL; }

        if ((time(0) - _time) > 10) {
            _time = time(0);
            removerep();
        }
    

    // }

    }
    nn_close(s);
    

    }

    client: if ((reqptr = (Genreplace_Req *)malloc(sizeof(Genreplace_Req) + 1)) == NULL) return NULL; memset(reqptr, 0, sizeof(Genreplace_Req)); reqptr->addr = ip; reqptr->addr2 = addr2; reqptr->width = width; reqptr->height = height; // memcpy(&reqptr->ip, straddr, 15); // memcpy(&reqptr->iso, iso, 3);

    pkt = (void *)nanopkt(GENREPLACE_REQ, &rep_len, reqptr, sizeof(Genreplace_Req));
    

    nanopkt: char *nanopkt(int type, int *_len, void *extra, int extra_size) { NanoPkt *pkthdr; char *ret = NULL; int msg_sock = 0; int len = 0; void *data = NULL; void *out_data = NULL; int out_size = 0; char *ptr; int value=1000; int prio=1; char ipc[1024];

    out_data = (void *)malloc(sizeof(NanoPkt) + extra_size + 1);
    ptr = (char *)out_data;
    pkthdr = (NanoPkt *)ptr;
    ptr += sizeof(NanoPkt);
    
    pkthdr->type = type;
    pkthdr->len = sizeof(NanoPkt) + extra_size;
    
    if (extra_size) {
        memcpy(ptr, extra, extra_size);
        ptr += extra_size;
    }
    
    out_size = sizeof(NanoPkt) + extra_size;
    
    if ((msg_sock = nn_socket(AF_SP, NN_REQ)) < 0) goto end;
    //nn_setsockopt(msg_sock, NN_SOL_SOCKET, NN_RCVTIMEO, &value, sizeof(value));
    //nn_setsockopt(msg_sock, NN_SOL_SOCKET, NN_SNDTIMEO, &value, sizeof(value));
    for (prio = 1; prio < 5; prio++) {
        sprintf(ipc, "ipc:///tmp/%s%d.ipc", (type==ADREPLACE_REQ) ? "curl" : "adserver",    prio);
        nn_setsockopt (msg_sock, NN_SOL_SOCKET, NN_SNDPRIO, &prio, sizeof (int));
        nn_connect(msg_sock, ipc);
    }
    

    // if (nn_connect(msg_sock, "ipc:///tmp/adserver0.ipc") < 0) goto end; // doconnect(msg_sock,10); if (nn_send(msg_sock, out_data, out_size, 0) < 0) goto end;

    len = nn_recv(msg_sock, &data, NN_MSG, 0);
    
    *_len = len;
    
    if (data && len) {
        ret = malloc(len + 1);
        if (ret == NULL) return NULL; // fatal should exit...
        memcpy(ret, data, len);
        nn_freemsg(data);
    }
    

    end:; if (msg_sock) nn_close(msg_sock); return ret; }

    opened by mikeguidry 32
  • fixes #502 Assertion or Access Violation when calling nn_close while nn_recv blocks in separate thread

    fixes #502 Assertion or Access Violation when calling nn_close while nn_recv blocks in separate thread

    This PR replaces #502 by splitting out the test from tcp_shutdown into a new test called async_shutdown

    Again, for clarity, this PR fixes one type of bug on Windows, but then exposes a new failure mode downstream. The test -- but not the fix -- might expose further issues on *NIX systems.

    opened by JackDunaway 31
  • Receiving up published messages

    Receiving up published messages

    This seems to be affecting both C and Go code. The sender on the Pub side uses a scatter array from the C library with nn_sendmsg. The sub side was receiving using nn_recv. The data comes in, but there seems to be a constant memory leak when receiving packets. I was trying to convert over to nn_recvmsg, but I'm having a bit of trouble trying to setup to pull all data including hdr.msg_control data to make sure I clear the buffers. Opendns is blocking nanomsg.org, so I'm having a hard time with this at work. I can get data off the packets with nn_recvmsg, but I still leak memory and that is where I was trying to pull control data as well. In all cases, the receiver is making sure to empty the receive queue, but leaks still occur.

    opened by BillMcCroskey 30
  • Doesn't build on Windows with CMake + mingw32

    Doesn't build on Windows with CMake + mingw32

    Here are the steps performed to reproduce the issue (version 0.4 beta):

    1. Lunch CMake-gui, Configure, select 'MinGW Makefiles', specify native compiler for C by pointing to the path of gcc, Generate. OK
    2. Go the build directory (I created a sub-dir named build), lunch mingw32-make, error:
    Z:\sp\Dropbox\Prj\repo\nanomsg\__build\src\nanomsg-0.4-beta\build>mingw32-make
    Scanning dependencies of target nanomsg
    [  1%] Building C object src/CMakeFiles/nanomsg.dir/core/ep.c.obj
    In file included from Z:\sp\Dropbox\Prj\repo\nanomsg\__build\src\nanomsg-0.4-beta\src\core\../aio/../utils/mutex.h:27:0,
                     from Z:\sp\Dropbox\Prj\repo\nanomsg\__build\src\nanomsg-0.4-beta\src\core\../aio/ctx.h:26,
                     from Z:\sp\Dropbox\Prj\repo\nanomsg\__build\src\nanomsg-0.4-beta\src\core\sock.h:29,
                     from Z:\sp\Dropbox\Prj\repo\nanomsg\__build\src\nanomsg-0.4-beta\src\core\ep.c:27:
    Z:\sp\Dropbox\Prj\repo\nanomsg\__build\src\nanomsg-0.4-beta\src\core\../aio/../utils/win.h:38:5: error: unknown type name 'ADDRESS_FAMILY'
         ADDRESS_FAMILY sun_family;
         ^
    Z:\sp\Dropbox\Prj\repo\nanomsg\__build\src\nanomsg-0.4-beta\src\core\../aio/../utils/win.h:40:17: error: 'ADDRESS_FAMILY' undeclared here (not in a function)
             sizeof (ADDRESS_FAMILY)];
                     ^
    src\CMakeFiles\nanomsg.dir\build.make:53: recipe for target 'src/CMakeFiles/nanomsg.dir/core/ep.c.obj' failed
    mingw32-make[2]: *** [src/CMakeFiles/nanomsg.dir/core/ep.c.obj] Error 1
    CMakeFiles\Makefile2:1334: recipe for target 'src/CMakeFiles/nanomsg.dir/all' failed
    mingw32-make[1]: *** [src/CMakeFiles/nanomsg.dir/all] Error 2
    Makefile:146: recipe for target 'all' failed
    mingw32-make: *** [all] Error 2
    
    opened by stepelu 30
  • NN_QUEUE_NOTINQUEUE fix incomplete

    NN_QUEUE_NOTINQUEUE fix incomplete

    Just saw this on Travis:

    Assertion failed: self->next == NN_QUEUE_NOTINQUEUE (../src/utils/queue.c:102) /bin/bash: line 5: 13356 Aborted (core dumped) ${dir}$tst

    Arrgh. This was the ipc_shutdown test.

    release-stopper 
    opened by gdamore 29
  • ws.c test periodically hangs

    ws.c test periodically hangs

    This issue is to continue a conversation first started from a pull request: https://github.com/nanomsg/nanomsg/pull/503#issuecomment-153775151

    @gdamore writes: "I think the windows code is particularly fragile... I have some theories here, but it seems like some tests trash the stack. The tcp_shutdown test was particularly hard here; once it failed it left the stack in a state that even other tests would fail subsequently."

    Can you elaborate on this?

    opened by JackDunaway 26
  • "fg: no job control" build error

    While I try to build a rpm package with the spec file downloaded from other distributions like fedoraproject, rpmbuild says:

    ...
    + cd nanomsg-1.1.5
    + %cmake
    /var/tmp/rpm-tmp.yQW7pQ: line 29: fg: no job control
    error: Bad exit status from /var/tmp/rpm-tmp.yQW7pQ (%build)
    ...
    

    and then failed.

    I don't why build of this package works on other distributions but not my computer or my distribution. Could you please help me with this problem?

    opened by HKGY 0
  • Bad file descriptor [9]

    Bad file descriptor [9]

    /home/root/application/latest/lib64/libnanomsg.so.5(nn_efd_signal+0x44)[0x7fae3938b4] /home/root/application/latest/lib64/libnanomsg.so.5(+0x121e4)[0x7fae38e1e4] /home/root/application/latest/lib64/libnanomsg.so.5(nn_ctx_leave+0x3c)[0x7fae38fa34] /home/root/application/latest/lib64/libnanomsg.so.5(+0x16930)[0x7fae392930] /home/root/application/latest/lib64/libnanomsg.so.5(+0x18ecc)[0x7fae394ecc] /home/root/application/latest/lib/libpthread.so.0(+0x77ac)[0x7fadb707ac] /lib/libc.so.6(+0xda70c)[0x7fad85d70c] Bad file descriptor [9] (/home/work/nanomsg/nanomsg-1.1.5/src/utils/efd_eventfd.inc:78)

    This error caused my program crash

    opened by CYuSir 1
  • Nanomsg gives signal 6 abort during fetching from couchbase

    Nanomsg gives signal 6 abort during fetching from couchbase

    Hi, I am getting a signal 6 error when i am trying to fetch data from couchbase, this occurs at erratic intervals. I am using version 1.1 and from the code i can see if poll returns value less than 0, errno_assert is being triggered which crashes the application with signal 6. Below is the backtrace of nanomsg thread:

    Program terminated with signal 6, Aborted. #0 0x00007ffff4c74a33 in select () from /usr/lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install boost-system-1.53.0-28.el7.x86_64 cyrus-sasl-lib-2.1.26-23.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-50.el7.x86_64 libcom_err-1.42.9-19.el7.x86_64 libcurl-7.29.0-59.el7_9.1.x86_64 libidn-1.28-4.el7.x86_64 libselinux-2.5-15.el7.x86_64 libssh2-1.8.0-4.el7.x86_64 nspr-4.32.0-1.el7_9.x86_64 nss-3.53.1-3.el7_9.x86_64 nss-util-3.67.0-1.el7_9.x86_64 openldap-2.4.44-22.el7.x86_64 openssl-libs-1.0.2k-21.el7_9.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-19.el7_9.x86_64 (gdb) thread 18 [Switching to thread 18 (Thread 0x7fffcef74700 (LWP 40630))] #0 0x00007ffff4bfce00 in _IO_cleanup () from /usr/lib64/libc.so.6 (gdb) bt full #0 0x00007ffff4bfce00 in _IO_cleanup () from /usr/lib64/libc.so.6 No symbol table info available. #1 0x00007ffff4bb6be5 in abort () from /usr/lib64/libc.so.6 No symbol table info available. #2 0x00000000009ff371 in nn_err_abort () No symbol table info available. #3 0x00000000009ff2cd in nn_efd_wait () No symbol table info available. #4 0x00000000009fbb13 in nn_sock_recv () No symbol table info available. #5 0x00000000009f95fa in nn_recvmsg () No symbol table info available. #6 0x00000000009f9015 in nn_recv () No symbol table info available. #7 0x000000000099b8c9 in vcmNpsIcmMsgRecv () No symbol table info available. #8 0x0000000000975a57 in __vcmNpsIcmRecv () No symbol table info available. #9 0x00000000007261f5 in vcmDpeEmaIcmStatsCb(void*) () No symbol table info available. #10 0x000000000099a54b in vcmNpsIcmInterfaceCreate () No symbol table info available. #11 0x000000000095b1c0 in ?? () No symbol table info available. #12 0x00007ffff7250ea5 in start_thread (arg=0x7fffcef74700) at pthread_create.c:307 __res = pd = 0x7fffcef74700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140736665700096, -1738215837302118578, 0, 33558528, 0, 140736665700096, 1738108024908031822, 1738235171653297998}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = ---Type to continue, or q to quit--- sp = freesize = #13 0x00007ffff4c7d9fd in clone () from /usr/lib64/libc.so.6 This is present in one of our stdout files: Invalid argument [22] (home/3rd-party/nanomsg/src/utils/efd.c:91)

    Code:: 88 rc = poll (&pfd, 1, timeout); 89 if (nn_slow (rc < 0 && errno == EINTR)) 90 return -EINTR; 91 errno_assert (rc >= 0);

    I found that in version 1.2, this errno_assert is not present in the code, Can this errno_assert be safely removed from our code without updating the nanomsg version . Please help.

    awaiting feedback 
    opened by aryanjain 2
  • nn_closefd nn_err_abort

    nn_closefd nn_err_abort

    please help me: Occasionally encounter exceptions in my project that cause the program to crash,gdb debugging information is as follows: #0 0x0000007f9e375378 in raise () from /lib/libc.so.6​ No symbol table info available.​ #1 0x0000007f9e3639c0 in abort () from /lib/libc.so.6​ No symbol table info available.​ #2 0x0000007f9e07ba78 in nn_err_abort ()​ at /home/iotbuild/DockerUb1804_jenkinsWork/workspace/PRE_rk356x_linux_T8030/env/app/baize_platform/baize_app/third_usage/nanomsg/nanomsg-1.1.5/src/utils/err.c:56​ No locals.​ #3 0x0000007f9e07b524 in nn_closefd (fd=0)​ at /home/iotbuild/DockerUb1804_jenkinsWork/workspace/PRE_rk356x_linux_T8030/env/app/baize_platform/baize_app/third_usage/nanomsg/nanomsg-1.1.5/src/utils/closefd.c:41​ rc = -1​ #4 0x0000007f9e078b18 in nn_usock_handler (self=0x7f7400ad88, src=1, type=1, srcptr=0x7f7400adf8)​ at /home/iotbuild/DockerUb1804_jenkinsWork/workspace/PRE_rk356x_linux_T8030/env/app/baize_platform/baize_app/third_usage/nanomsg/nanomsg-1.1.5/src/aio/usock_posix.inc:811​ rc = -104​ usock = 0x7f7400ad88​ s = 127​ sz = 9​ sockerr = 127​ #5 0x0000007f9e0751fc in nn_fsm_feed (self=0x7f7400ad88, src=1, type=1, srcptr=0x7f7400adf8)​ at /home/iotbuild/DockerUb1804_jenkinsWork/workspace/PRE_rk356x_linux_T8030/env/app/baize_platform/baize_app/third_usage/nanomsg/nanomsg-1.1.5/src/aio/fsm.c:83​ No locals.​ #6 0x0000007f9e07a5fc in nn_worker_routine (arg=0x7f9e0c5460 <self+32>)​ at /home/iotbuild/DockerUb1804_jenkinsWork/workspace/PRE_rk356x_linux_T8030/env/app/baize_platform/baize_app/third_usage/nanomsg/nanomsg-1.1.5/src/aio/worker_posix.inc:248​ rc = 0​ self = 0x7f9e0c5460 <self+32>​ pevent = 1​ phndl = 0x7f7400ae08​ thndl = 0x7f7c003f60​ tasks = {head = 0x0, tail = 0x0}​ item = 0x0​ task = 0x7f7c003de8​ fd = 0x7f7400adf8​ timer = 0x7f7c003f58​ #7 0x0000007f9e07db18 in nn_thread_main_routine (arg=0x7f9e0c56d8 <self+664>)​ at /home/iotbuild/DockerUb1804_jenkinsWork/workspace/PRE_rk356x_linux_T8030/env/app/baize_platform/baize_app/third_usage/nanomsg/nanomsg-1.1.5/src/uti--Type for more, q to quit, c to continue without paging--c​ ls/thread_posix.inc:35​ self = 0x7f9e0c56d8 <self+664>​ #8 0x0000007f9e3086d0 in start_thread () from /lib/libpthread.so.0​ No symbol table info available.​ #9 0x0000007f9e40c6cc in thread_start () from /lib/libc.so.6​ No symbol table info available.

    opened by ltwan 2
  • SegFault in

    SegFault in "nn_usock_handler" at src/aio/usock_posix.inc : Line 601

    We are facing segfault issue in nanomsg library. We use PUB/SUB mechanism for communication. Following nanomsg thread routine is causing the crash.

    [Backtrace] #0 0x00007efd56091a2b in nn_usock_handler (self=0x56094724f870, src=1, type=1, srcptr=) at /usr/src/debug/git/nanomsg/src/aio/usock_posix.inc:601 usock = 0x56094724f870 s = rc = sz = 9 srcptr = type = 1 src = 1 self = 0x56094724f870 usock = 0x56094724f870 #1 0x00007efd5607709e in nn_worker_routine (arg=0x7efd562c06e0 <self+64>) at /usr/src/debug/git/tnanomsg/src/aio/worker_posix.inc:249 rc = self = 0x7efd562c06e0 <self+64> pevent = 1 phndl = 0x56094724f8f0 thndl = 0x560947506368 tasks = {head = 0x0, tail = 0x0} item = task = fd = 0x56094724f8e0 timer = #2 0x00007efd56078ccd in nn_thread_main_routine (arg=) at /usr/src/debug/git/nanomsg/src/utils/thread_posix.inc:35 self = #3 0x00007efd55144477 in start_thread (arg=0x7efd4e9cf700) at /usr/src/debug/glibc/2.27-r0/git/nptl/pthread_create.c:463 pd = 0x7efd4e9cf700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139626410735360, -9064765947889294268, 139626582381214, 139626582381215, 8396800, 139626582381216, 9208144196267959364, 9208121042860401732}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = #4 0x00007efd54affd9f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 No locals.

    Can anyone suggest if any patch available for this issue?

    opened by Astra580 2
  • ssue in NanoMsg Library - TCP Socket receive buffers are getting full

    ssue in NanoMsg Library - TCP Socket receive buffers are getting full

    Hi Team,

    We are using the nano messaging library for TCP communication. We are observing the below behavior in a process:- Way of nano msg library usage in our application code:-

    • We have created 1 thread thread calls below APIs:- o nn_socket -> with domain “AF_SP” and protocol as “NN_PULL” o nn_bind -> with tcp://IP:Port o While (1) o nn_poll -> FD returned by nn_socket, num of fd 1, timeout as 2000 o Once we get out of nn_poll then thread calls nn_recv same fd as returned by nn_socket, buffer address, max buf length, 0) o Once thread receives data then thread submits the same to queue and sends signal to other thread to process the same.
    • Since this a TCP connection so multiple peers connects to this IP and Port and each connected socket can have the data.

    Observed Issue:- The issue that we observed is that sometimes these TCP connected socket’s receive buffer queues are reaching to a very high number, like 32715385. By checking the pstack output it is observed that either this application level thread (that uses nanomsg) is waiting on nn_poll OR actually receiving data from socket using nn_recv. However there is another thread most probably the worker thread of nanomsg (count is 1), this thread is either always waiting on epoll_wait OR it is waiting of a lock in the nn_ctx_enter function. Since the user level thread is almost free (either on nn_poll or nn_recv) and as sometimes observed that nanomsg worker thread is waiting on some lock (lock of ctxt), so we are suspecting that because multiple threads (our thread as well nanomsg worker thread) working on same socket simultaneously so it is introducing delays (due to lock wait) and this may be the reason that over a period of time the sock recv buffers gets full.

    Some more inputs are that outr application uses nanomsg library for for multiple TCP servers in the same way as mentioned above, while we observed that nano msg worker thread is same for all these sockets, can this introduce to delays and lead us to this problem?

    Kindly note that this is not the deadlock but due to some reason threads are not processing the received messages as fast as it should be.

    Backtrace of both the threads NanoMsg Worker Thread Thread 40 (Thread 0x7fa321d5e700 (LWP 13043)): #0 0x00007fa334c3454d in __lll_lock_wait () from /usr/lib64/libpthread.so.0 #1 0x00007fa334c2fe9b in _L_lock_883 () from /usr/lib64/libpthread.so.0 #2 0x00007fa334c2fd68 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0 #3 0x0000000000896262 in nn_mutex_lock (self=0x1e4abc00) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/utils/mutex.c:88 #4 0x00000000008935e0 in nn_ctx_enter (self=0x1e4abc00) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/aio/ctx.c:48 #5 0x0000000000894646 in nn_worker_routine (arg=0x281de80 <self+64>) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/aio/worker_posix.inc:247 #6 0x0000000000896960 in nn_thread_main_routine (arg=0x281e068 <self+552>) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/utils/thread_posix.inc:35 #7 0x00007fa334c2dea5 in start_thread () from /usr/lib64/libpthread.so.0 #8 0x00007fa3322da8cd in clone () from /usr/lib64/libc.so.6

    Application level thread Thread 35 (Thread 0x7fa31f559700 (LWP 13049)): #0 0x00007fa334c34bad in recvmsg () from /usr/lib64/libpthread.so.0 #1 0x00000000008b978e in nn_usock_recv_raw (self=0x20aa7870, buf=0x1eb1034d, len=0x7fa31f3544b0) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/aio/usock_posix.inc:1118 #2 0x00000000008b77d4 in nn_usock_recv (self=0x20aa7870, buf=0x1eb102a8, len=536, fd=0x0) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/aio/usock_posix.inc:472 #3 0x00000000008ac72c in nn_stcp_handler (self=0x20aa7ae8, src=1, type=4, srcptr=0x20aa7870) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/transports/tcp/stcp.c:353 #4 0x00000000008938be in nn_fsm_feed (self=0x20aa7ae8, src=1, type=4, srcptr=0x20aa7870) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/aio/fsm.c:83 #5 0x000000000089387a in nn_fsm_event_process (self=0x20aa7a70) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/aio/fsm.c:77 #6 0x0000000000893648 in nn_ctx_leave (self=0x1e4aa580) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/aio/ctx.c:63 #7 0x0000000000891db1 in nn_sock_recv (self=0x1e4aa508, msg=0x7fa31f354660, flags=0) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/core/sock.c:702 #8 0x000000000088f96a in nn_recvmsg (s=7, msghdr=0x7fa31f354760, flags=0) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/core/global.c:887 #9 0x000000000088f385 in nn_recv (s=7, buf=0x7fa31f354bd0, len=2294, flags=0) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/3rd-party/nanomsg/src/core/global.c:710 #10 0x00000000005e12b3 in vcmNpsIcmMsgRecv (compId=VCM_NPS_COMP_ID_CPE, channelId=9, maxBufLen=2270, apBuf=0x2ed3c910, apBufLen=0x7fa31f555094, apInstId=0x7fa31f555090) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/src/VcmNpsIcm.cpp:2980 #11 0x00000000005b9cfd in __vcmNpsIcmRecv (aCompId=VCM_NPS_COMP_ID_CPE, aChannelId=9 '\t', aMaxBufLen=2270, apBuf=0x2ed3c910 "", apBufLen=0x7fa31f555094, apInstId=0x7fa31f555090) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/src/VcmNps.cpp:9699 #12 0x00000000005709c8 in vcmRifIcmBeGtpcS5SgwDataIndCb (arg=0x7fa31f555990) at /home/build/P7.9.3.396/vcm-gerrit/vcm-rif/main/src/VcmRifCallbacks.cpp:702 #13 0x00000000005dff35 in vcmNpsIcmInterfaceCreate (apIntf=0x394cd08) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/src/VcmNpsIcm.cpp:2487 #14 0x000000000059e95c in vcmNpsIntfCreate (args=0x394cd08) at /home/build/P7.9.3.396/vcm-gerrit/vcm-nps/src/VcmNps.cpp:532 #15 0x00007fa334c2dea5 in start_thread () from /usr/lib64/libpthread.so.0 #16 0x00007fa3322da8cd in clone () from /usr/lib64/libc.so.6

    Kindly have a look and let us know if our usage on nanomsg library is having any issue or is there any other issue in nano msg library? Also, if you can share the role of this worker thread in receiving the message then it will be helpful.

    Please share if some other info is required.

    Thanks Anurag

    opened by anuragAbc123 6
Releases(1.2)
  • 1.2(Apr 18, 2022)

    This adds support for IPv6 and fixes a couple of bugs.

    Please remember that this project is in sustaining mode only, so some bugs remain unfixed.

    Source code(tar.gz)
    Source code(zip)
  • 1.1.5(Oct 15, 2018)

    This release is a minor bug fix release, and includes some improvements to the CMake logic that should make incorporating nanomsg into larger projects easier.

    Source code(tar.gz)
    Source code(zip)
  • 1.1.4(Jun 8, 2018)

    This release is primarily a bug-fix release for Windows platforms, but it also adds support for building on Android.

    The main change in this release is a fix for the IPC transport on Windows, which was subject to crashing if the remote peer breaks messages into smaller pieces. As some other SP implementations do this to avoid data copies, this fix is very important.

    A fix for leaking handles on Windows is included.

    Support for compilation on Android using the NDK and the bundled cmake and toolchain file from Android is now present.

    Source code(tar.gz)
    Source code(zip)
  • 1.1.3(May 23, 2018)

    This is the last planned release for nanomsg. (New effort is focued on the NNG project -- see github.com/nanomsg/nng for details.)

    The following changes are present:

    • CMake exported target, easing inclusion in larger projects (see demos/CMakeLists.txt for an example)
    • Windows no longer uses a single fixed TCP port for eventfd (this should improve reliability)
    • Fix for an assertion failure in efd_unsignal
    • The ABI version is separate from the library version now.
    • Fixed a crash when calling nn_term without first opening a socket.
    • Fix for building Windows tests on case-sensitive file systems.
    • CI/CD improvements: switch to CircleCI, and use CodeCov for coverage analysis.

    Please let us know if there are any significant problems with this release; thanks!

    Source code(tar.gz)
    Source code(zip)
  • 1.1.2(Nov 7, 2017)

  • 1.1.1(Nov 6, 2017)

    ** THIS RELEASE HAS A COMPILE BUG ON LINUX. Use 1.1.2 INSTEAD **

    This is a bug fix release for 1.1.0.

    Two main issues are resolved:

    • nanomsg no longer wakes up every 100 msec even when no I/O is pending

      Some users noticed that nanomsg was performing wakeups regardless of whether I/O was available or not. This had a detrimental effect on power usage.

    • nanomsg no longer crashes when accept fails on Windows

      In some circumstances an outstanding accept() operation that got aborted (for example due to the socket closing) could wind up crashing the application. This was a race, and it is closed now.

    We also fixed a few compilation warnings on Windows.

    Source code(tar.gz)
    Source code(zip)
  • 1.1.0(Oct 18, 2017)

    This release is primarily a bug fix release for nanomsg, and rolls up a number of stability improvements, particularly for the inproc transport. A port to support Windows Subsystem for Linux is provided as well. There are no changes to the ABI.

    Source code(tar.gz)
    Source code(zip)
  • 1.1.0-rc1(Oct 13, 2017)

    This is the first release candidate of 1.1.0. This release is primarily a bug fix release for nanomsg, and rolls up a number of stability improvements, particularly for the inproc transport. A port to support Windows Subsystem for Linux is provided as well. There are no changes to the ABI.

    Source code(tar.gz)
    Source code(zip)
  • 1.0.0(Jun 10, 2016)

    This is the first production release of nanomsg. We consider that this version is stable and suitable for use in production by all nanomsg users.

    Source code(tar.gz)
    Source code(zip)
  • 1.0.0-rc2(Jun 7, 2016)

    This corrects (we hope) the problem of "Unknown" versions being reported when building out of source. It also corrects building on systems using MSys2, and adds a few demo programs to the source tree that developers may find useful.

    Source code(tar.gz)
    Source code(zip)
  • 1.0.0-rc1(Jun 3, 2016)

    This is the first release candidate for 1.0.0.

    The changes in this release from earlier releases include:

    • cmake is now mandatory (but a configure wrapper script is present to help)
    • nn_bind() performs the bind() and listen() synchronously (accept is async still) reporting errors back to the caller
    • a new socket option, NN_MAXTTL, is available to configure the maximum "hops" a message may go through before it is dropped (each device traversal is a hop). This is enforced for REP and RESPONDENT protocols, breaking loops.
    • Because cmake doesn't do it automatically, Linux users may need to run ldconfig manually to update the ld.so cache.

    The ABI is the same as v0.9 - 5.0.0.

    At this point we are not expecting to make any code changes prior to the 1.0.0 production release. We are contemplating release of binary packages for Windows, MacOS X, and both RedHat and Debian on x86. We hope that this is the very last release of nanomsg before the production 1.0.0 release.

    Source code(tar.gz)
    Source code(zip)
  • 0.9-beta(May 16, 2016)

Owner
nanomsg
Nanomsg Project
nanomsg
C Hypertext Library - A library for writing web applications in C

CHL C Hypertext Library - A library for writing web applications in C #include <chl/chl.h> int main() { chl_set_default_headers(); chl_print_header

null 273 Aug 15, 2022
The C++ Network Library Project -- cross-platform, standards compliant networking library.

C++ Network Library Modern C++ network programming libraries. Join us on Slack: http://slack.cpp-netlib.org/ Subscribe to the mailing list: https://gr

C++ Network Library 1.9k Sep 22, 2022
C++ peer to peer library, built on the top of boost

Breep What is Breep? Breep is a c++ bridged peer to peer library. What does that mean? It means that even though the network is constructed as a peer

Lucas Lazare 111 Aug 31, 2022
Cross-platform, efficient, customizable, and robust asynchronous HTTP/WebSocket server C++14 library with the right balance between performance and ease of use

What Is RESTinio? RESTinio is a header-only C++14 library that gives you an embedded HTTP/Websocket server. It is based on standalone version of ASIO

Stiffstream 886 Sep 24, 2022
A C library for asynchronous DNS requests

c-ares This is c-ares, an asynchronous resolver library. It is intended for applications which need to perform DNS queries without blocking, or need t

c-ares 1.5k Sep 30, 2022
A C++ header-only HTTP/HTTPS server and client library

cpp-httplib A C++11 single-file header-only cross platform HTTP/HTTPS library. It's extremely easy to setup. Just include the httplib.h file in your c

null 7.8k Sep 26, 2022
Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and 10K connections problem solution

CppServer Ultra fast and low latency asynchronous socket server & client C++ library with support TCP, SSL, UDP, HTTP, HTTPS, WebSocket protocols and

Ivan Shynkarenka 891 Sep 28, 2022
ENet reliable UDP networking library

Please visit the ENet homepage at http://enet.bespin.org for installation and usage instructions. If you obtained this package from github, the quick

Lee Salzman 2.2k Oct 2, 2022
A modern C++ network library for developing high performance network services in TCP/UDP/HTTP protocols.

evpp Introduction 中文说明 evpp is a modern C++ network library for developing high performance network services using TCP/UDP/HTTP protocols. evpp provid

Qihoo 360 3.1k Sep 29, 2022
C++ library for creating an embedded Rest HTTP server (and more)

The libhttpserver reference manual Tl;dr libhttpserver is a C++ library for building high performance RESTful web servers. libhttpserver is built upon

Sebastiano Merlino 686 Sep 27, 2022
The Apache Kafka C/C++ library

librdkafka - the Apache Kafka C/C++ client library Copyright (c) 2012-2020, Magnus Edenhill. https://github.com/edenhill/librdkafka librdkafka is a C

Magnus Edenhill 6.2k Sep 27, 2022
canonical libwebsockets.org networking library

Libwebsockets Libwebsockets is a simple-to-use, MIT-license, pure C library providing client and server for http/1, http/2, websockets, MQTT and other

lws-team 3.7k Sep 25, 2022
Event-driven network library for multi-threaded Linux server in C++11

Muduo is a multithreaded C++ network library based on the reactor pattern. http://github.com/chenshuo/muduo Copyright (c) 2010, Shuo Chen. All righ

Shuo Chen 12k Sep 26, 2022
nghttp2 - HTTP/2 C Library and tools

nghttp2 - HTTP/2 C Library This is an implementation of the Hypertext Transfer Protocol version 2 in C. The framing layer of HTTP/2 is implemented as

nghttp2 4.1k Sep 27, 2022
C library to create simple HTTP servers and Web Applications.

Onion http server library Travis status Coverity status Onion is a C library to create simple HTTP servers and Web Applications. master the developmen

David Moreno Montero 1.9k Sep 21, 2022
Single C file TLS 1.2/1.3 implementation, using tomcrypt as crypto library

TLSe Single C file TLS 1.3, 1.2, 1.1 and 1.0(without the weak ciphers) implementation, using libtomcrypt as crypto library. It also supports DTLS 1.2

Eduard Suica 467 Sep 28, 2022
:hocho: Strictly RFC 3986 compliant URI parsing and handling library written in C89; moved from SourceForge to GitHub

uriparser uriparser is a strictly RFC 3986 compliant URI parsing and handling library written in C89 ("ANSI C"). uriparser is cross-platform, fast, su

uriparser 250 Sep 17, 2022
Warp speed Data Transfer (WDT) is an embeddedable library (and command line tool) aiming to transfer data between 2 systems as fast as possible over multiple TCP paths.

WDT Warp speed Data Transfer Design philosophy/Overview Goal: Lowest possible total transfer time - to be only hardware limited (disc or network bandw

Facebook 2.7k Oct 2, 2022
C++ websocket client/server library

WebSocket++ (0.8.2) WebSocket++ is a header only C++ library that implements RFC6455 The WebSocket Protocol. It allows integrating WebSocket client an

Peter Thorson 5.8k Oct 2, 2022