mangos is a pure Golang implementation of nanomsg's "Scalablilty Protocols"

Overview

mangos

Linux Status Windows Status Darwin Status Coverage Code Quality Discord GoDoc Apache 2.0 License Latest version

Mangos™ is an implementation in pure Go of the SP (“Scalability Protocols”) messaging system. These are colloquially known as a “nanomsg”.

mangos
The import path has changed! Please change any references from nanomsg.org/go/mangos/v2 to go.nanomsg.org/mangos/v3. The old v2 imports will still work for old applications, provided that a sufficiently modern version of Go is used. However, no further work will be done on v2.
Tip
Versions 1 and 2 of mangos were at different import locations. Those versions will still inter-operate with this version, except that within the same process the inproc transport can only be used by consumers using the same version of mangos.

The modern C implementation of the SP protocols is available as NNG™.

The original implementation of the SP protocols is available as nanomsg™.

Generally (modulo a few caveats) all of these implementations can inter-operate.

The design is intended to make it easy to add new transports with almost trivial effort, as well as new topologies (“protocols” in SP parlance.)

At present, all of the Req/Rep, Pub/Sub, Pair, Bus, Push/Pull, and Surveyor/Respondent patterns are supported. This project also supports an experimental protocol called Star.

Supported transports include TCP, inproc, IPC, WebSocket, WebSocket/TLS and TLS.

Basic interoperability with nanomsg and NNG has been verified (you can do so yourself with nanocat and macat) for all protocols and transports that NNG and nanomsg support, except for the ZeroTier transport and the PAIRv1 protocol, which are only supported in NNG at this time.

There are a number of projects that use these products together.

Documentation

Testing

This package supports internal self tests, which can be run in the idiomatic Go way. (Note that most of the tests are in a test subdirectory.)

$ go test go.nanomsg.org/mangos/v3/...

There are also internal benchmarks available:

$ go test -bench=. go.nanomsg.org/mangos/v3/test

Commercial Support

Examples

Some examples are posted in the directories under examples/ in this project.

These examples are rewrites (in Go) of Tim Dysinger’s Getting Started with Nanomsg.

Running go doc in the example directories will yield information about how to run each example program.

Enjoy!


Copyright 2020 The Mangos Authors

mangos™, Nanomsg™ and NNG™ are trademarks of Garrett D’Amore.

Comments
  • transport: add UDP support?

    transport: add UDP support?

    For networks with high latencies and for certain messaging scenarios where a reliable underlying transport protocol is not required, UDP transport support is desirable.

    In our REQ/REP scenario, with a worst-case RTT of 0.3 seconds, the initial TCP handshake alone would take 1 second, which is a lot of overhead for short exchanges.

    Question: whether UDP support is planned for go-mangos?

    For nanomessage, this was originally specified in sp-udp-mapping-01.txt.

    During a proof-of-concept, there were 2 challenges I ran into:

    1. asynchronous errors - in TCP, socket errors are instantaneously visible; UDP errors (via ICMP) are reported on the next socket call (which leads to e.g. 'connection refused' on send). Mitigations are
      • poll socket error queue (IP_RECVERR, Linux only);
      • retry operations multiple times (i.e. multiple send calls)
    2. different socket semantics: go-mangos PipeListener requires Accept. This can be mimicked in the REQ/REP case using a single listener socket, which de-multiplexes incoming connections. In the PUB/SUB case, this would not work, since the SUB sockets require a passive connection setup.

    As an alternative, TCP Fast Open might be an option. Go does not yet support it, but they are working on it.

    opened by grrtrr 22
  • Issue with using v2 in go module project

    Issue with using v2 in go module project

    I'm attempting to upgrade my project to use mangos v2 and am having issues compiling it. My project is using the go modules feature. When I compile my application from a simlinked direectory in the normal $GOPATH/src/github.com/... location it can compile just fine.

    When I try to compile the project with go modules turned on from my ~/projects/... directory I see the following error: cannot find module for path nanomsg.org/go/mangos/v2

    Is this library incompatible with go modules at this time? v1 works just fine which is confusing.

    opened by KayoticSully 21
  • [BUG] Panic on reconnect

    [BUG] Panic on reconnect

    Hello, first and thank you for this great project.

    I'm working with mangos as Req(master)/Resp(agents) protocol with 1 master listening for connections and distributing jobs and N agents connecting to the master and doing distributed work.

    I did a PoC as I commented here https://github.com/nanomsg/mangos/issues/189 , in the poc all working fine.

    But with real data we have Panics in the master, after agents have been restarted and trying to reconnect again.

    [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0xb81f89]
    
    goroutine 39 [running]:
    go.nanomsg.org/mangos/v3.(*Message).Dup(0x0, 0x419ff6)
    	/home/vant/go/pkg/mod/go.nanomsg.org/mangos/[email protected]/message.go:157 +0x29
    go.nanomsg.org/mangos/v3/protocol/req.(*socket).send(0xc0001f0240)
    	/home/vant/go/pkg/mod/go.nanomsg.org/mangos/[email protected]/protocol/req/req.go:89 +0x13d
    go.nanomsg.org/mangos/v3/protocol/req.(*socket).AddPipe(0xc0001f0240, 0x1004300, 0xc0000974a0, 0x0, 0x0)
    	/home/vant/go/pkg/mod/go.nanomsg.org/mangos/[email protected]/protocol/req/req.go:489 +0x13a
    go.nanomsg.org/mangos/v3/internal/core.(*socket).addPipe(0xc00032a000, 0x7f82e205bea0, 0xc000096960, 0x0, 0xc000290100)
    	/home/vant/go/pkg/mod/go.nanomsg.org/mangos/[email protected]/internal/core/socket.go:78 +0x176
    go.nanomsg.org/mangos/v3/internal/core.(*listener).serve(0xc000290100)
    	/home/vant/go/pkg/mod/go.nanomsg.org/mangos/[email protected]/internal/core/listener.go:59 +0xfe
    created by go.nanomsg.org/mangos/v3/internal/core.(*listener).Listen
    	/home/vant/go/pkg/mod/go.nanomsg.org/mangos/[email protected]/internal/core/listener.go:92 +0x1aa
    [Bra] 03-18 18:43:53 [ WARN] Fail to execute command: ./bin/synthetix-manager [] - exit status 2
    

    There is any workaround to avoid this error?

    bug 
    opened by toni-moreno 14
  • unknown revision nanomsg.org/go/mangos/v2.0.1

    unknown revision nanomsg.org/go/mangos/v2.0.1

    While trying to build a go project, which uses mangos-v2, I get the following error:

    go: finding nanomsg.org/go/mangos/v2 v2.0.1
    go: nanomsg.org/go/mangos/[email protected]: unknown revision nanomsg.org/go/mangos/v2.0.1
    go: error loading module requirements
    

    This is the require statement in my go.mod:

    ...
    require nanomsg.org/go/mangos/v2 v2.0.1
    ...
    

    I am using go-1.11.

    Not sure what I did wrong.

    opened by gabrielruiu 13
  • Multiple responses per request

    Multiple responses per request

    Hi,

    It's not clear to me whether Mangos supports sending multiple messages over one socket after receiving one single request. I was under the impression that using a OpenContext on a socket that uses a protocol that supports it, it would be possible to achieve something like:

    ctx, _ := sock.OpenContext()
    
    req, _ = ctx.Recv()
    
    // imaginary function that returns a response in multiple chunks from a request
    resp := getResponseChunks(req)
    
    for _, chunk := range resp {
    	ctx.Send(chunk)
    }
    

    But when doing so using a rep socket over tcp, the second call to ctx.Send returns an incorrect protocol state error, so I imagine that it's not possible.

    I haven't found detailed documentation on which protocol supports which operations, using contexts, so I might be doing something wrong. My use case is that I need to send a large amount of data (potentially multiple gigabytes) over the socket, so I want to split it into multiple responses. Maybe there's another, better way to achieve that using mangos?

    question 
    opened by Ullaakut 11
  • fixes #96 NewConnPipe can wait indefinitely on peer

    fixes #96 NewConnPipe can wait indefinitely on peer

    This fixes an important security and reliability concern -- a some of the early negotiation logic was on a synchronous path for dialing, and this could allow a bad peer to either slow or completely stall out any new connections from being established.

    The Dialer side is still synchronous, by necessity, as it only opens a single connection at a time.

    opened by gdamore 11
  • Want pairv1

    Want pairv1

    In https://github.com/nanomsg/nng - we have a new PAIRv1 protocol, which adds better resilience for loops in device plumbing.

    We should go ahead and add that. We might also use this opportunity to try to support polyamorous mode from nng in our new v1 pipes.

    opened by gdamore 11
  • How to connect zeroMQ client to server behind ELB/docker

    How to connect zeroMQ client to server behind ELB/docker

    Hi,

    I am looking for some suggestions to connect 0MQ client to 0MQ server behind ELB/Proxy.

    I have a client and server code as containers and not able to connect with docker. Same issue with connecting via ELB.

    Any suggestions?

    opened by subbu05 10
  • Problems integrating using CI pipeline

    Problems integrating using CI pipeline

    Hey guys,

    Great work, love the project, but when I try to install the application using our CI pipeline I run into a problem from my build script. The build process pulls the code from our private repo and then uses go get -t -v "./..." to pull go dependencies. There are problems with pulling the code, though, and that causes an exit code of 1 to be generated in our build script. This fails the build entirely, and I don't want to special case skip that check for all go packages because if Mangos. I'm hoping you can advise.

    The build script:

    #!/bin/bash -e
    
    # Ted: contact me when you make any changes
    
    PREFIX="${PREFIX:-$(pwd)/build}"
    
    SRC_DIR="$(dirname "${BASH_SOURCE[0]}")"
    source "$SRC_DIR/env.sh"
    
    GECKO_PKG=github.com/ava-labs/gecko
    GECKO_PATH="$GOPATH/src/$GECKO_PKG"
    if [[ -d "$GECKO_PATH/.git" ]]; then
        cd "$GECKO_PATH"
        go get -t -v "./..."
        cd -
    else
        go get -t -v "$GECKO_PKG/..."
    fi
    go build -o "$PREFIX/ava" "$GECKO_PATH/main/"*.go
    go build -o "$PREFIX/xputtest" "$GECKO_PATH/xputtest/"*.go
    

    The package DOES pull down, but it also generates errors which results in an exit code being produced. On my local environment, running the build script once fails. Running it a second time passes because the library is pulled down already and no errors are generated.

    The errors produced are as follows:

    get "go.nanomsg.org/mangos": found meta tag get.metaImport{Prefix:"go.nanomsg.org/mangos", VCS:"git", RepoRoot:"https://github.com/nanomsg/mangos"} at //go.nanomsg.org/mangos?go-get=1
    go.nanomsg.org/mangos (download)
    package go.nanomsg.org/mangos/protocol/pub: unrecognized import path "go.nanomsg.org/mangos/protocol/pub" (parse https://go.nanomsg.org/mangos/protocol/pub?go-get=1: no go-import meta tags ())
    package go.nanomsg.org/mangos/transport/ipc: unrecognized import path "go.nanomsg.org/mangos/transport/ipc" (parse https://go.nanomsg.org/mangos/transport/ipc?go-get=1: no go-import meta tags ())
    

    Any suggestions?

    opened by collincusce 10
  • Panic in Message.Dup

    Panic in Message.Dup

    I'm getting a panic in a client when I restart a server it is connected to:

    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x950c39]
    
    goroutine 151 [running]:
    nanomsg.org/go/mangos/v2.(*Message).Dup(0x0, 0x40c1c6)
    	/Users/nick/go/pkg/mod/nanomsg.org/go/mangos/[email protected]/message.go:124 +0x29
    nanomsg.org/go/mangos/v2/protocol/req.(*socket).send(0xc000251680)
    	/Users/nick/go/pkg/mod/nanomsg.org/go/mangos/[email protected]/protocol/req/req.go:92 +0x189
    nanomsg.org/go/mangos/v2/protocol/req.(*socket).AddPipe(0xc000251680, 0xc3e1a0, 0xc000061bc0, 0x0, 0x0)
    	/Users/nick/go/pkg/mod/nanomsg.org/go/mangos/[email protected]/protocol/req/req.go:487 +0x13a
    nanomsg.org/go/mangos/v2/internal/core.(*socket).addPipe(0xc00023e360, 0x7f595fadaca0, 0xc000061b60, 0xc000251920, 0x0)
    	/Users/nick/go/pkg/mod/nanomsg.org/go/mangos/[email protected]/internal/core/socket.go:78 +0x176
    nanomsg.org/go/mangos/v2/internal/core.(*dialer).dial(0xc000251920, 0xc000061401, 0x0, 0x0)
    	/Users/nick/go/pkg/mod/nanomsg.org/go/mangos/[email protected]/internal/core/dialer.go:173 +0x337
    nanomsg.org/go/mangos/v2/internal/core.(*dialer).redial(...)
    	/Users/nick/go/pkg/mod/nanomsg.org/go/mangos/[email protected].0.7/internal/core/dialer.go:215
    created by time.goFunc
    	/usr/local/Cellar/go/1.13.5/libexec/src/time/sleep.go:168 +0x44
    

    Setup

    • Kubernetes
    • Two pods with REP socket to load balance requests
    • Client REQ socket dials to headless service e.g. mystatefulset.default.svc.cluster.local:8000

    Requests properly alternate between each replica in the stateful set. When one server pod is deleted, the client dumps the above panic.

    • Is this the proper way to setup load balancing? Should I list the exact endpoint instead? dig would show multiple IPs for this address.
    • How can I get a status log when a client connects/disconnects in the Dialer during a redial attempt?
    • How would you handle removing members of a load balancing set? I only see socket.Dial(url) to connect to more.

    This is an amazing project! Thank you 💯

    bug 
    opened by nick-phillips-dev 10
  • Godoc: Missing Packages

    Godoc: Missing Packages

    The documentation on godoc.org for the custom import url seems to be missing packages (this page is referenced by the badge in README):

    • https://godoc.org/nanomsg.org/go/mangos/v2

    Godoc seems to properly detect everything when using the GitHub repo as the import path:

    • https://godoc.org/github.com/nanomsg/mangos

    I noticed that the go-get info page at https://nanomsg.org/go/mangos/v2?go-get=1 still references the old repository url. But I don't know whether that is the cause of the issue (go get generally works fine):

    <meta name="go-import" content="nanomsg.org/go/mangos/v2 git https://github.com/nanomsg/mangos-v2">
    <meta name="go-source" content="nanomsg.org/go/mangos/v2 https://github.com/nanomsg/mangos-v2 _ https://github.com/nanomsg/mangos-v2/tree/master{/dir} https://github.com/nanomsg/mangos-v2/blob/master{/dir}{file}#L{line}">
    
    opened by seoester 10
  • Bump github.com/Microsoft/go-winio from 0.5.2 to 0.6.0

    Bump github.com/Microsoft/go-winio from 0.5.2 to 0.6.0

    Bumps github.com/Microsoft/go-winio from 0.5.2 to 0.6.0.

    Release notes

    Sourced from github.com/Microsoft/go-winio's releases.

    v0.6.0

    What's Changed

    New Contributors

    Full Changelog: https://github.com/microsoft/go-winio/compare/v0.5.2...v0.6.0

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies go 
    opened by dependabot[bot] 1
  • Bump codecov/codecov-action from 3.1.0 to 3.1.1

    Bump codecov/codecov-action from 3.1.0 to 3.1.1

    Bumps codecov/codecov-action from 3.1.0 to 3.1.1.

    Release notes

    Sourced from codecov/codecov-action's releases.

    3.1.1

    What's Changed

    New Contributors

    Full Changelog: https://github.com/codecov/codecov-action/compare/v3.1.0...v3.1.1

    Changelog

    Sourced from codecov/codecov-action's changelog.

    3.1.1

    Fixes

    • #661 Update deprecation warning
    • #593 Create codeql-analysis.yml
    • #712 README: fix typo
    • #725 fix: Remove a blank row
    • #726 Update README.md with correct badge version
    • #633 Create scorecards-analysis.yml
    • #747 fix: add more verbosity to validation
    • #750 Regenerate scorecards-analysis.yml
    • #774 Switch to v3
    • #783 Fix network entry in table
    • #791 Trim arguments after splitting them
    • #769 Plumb failCi into verification function.

    Dependencies

    • #713 build(deps-dev): bump typescript from 4.6.3 to 4.6.4
    • #714 build(deps): bump node-fetch from 3.2.3 to 3.2.4
    • #724 build(deps): bump github/codeql-action from 1 to 2
    • #717 build(deps-dev): bump @​types/jest from 27.4.1 to 27.5.0
    • #729 build(deps-dev): bump @​types/node from 17.0.25 to 17.0.33
    • #734 build(deps-dev): downgrade @​types/node to 16.11.35
    • #723 build(deps): bump actions/checkout from 2 to 3
    • #733 build(deps): bump @​actions/github from 5.0.1 to 5.0.3
    • #732 build(deps): bump @​actions/core from 1.6.0 to 1.8.2
    • #737 build(deps-dev): bump @​types/node from 16.11.35 to 16.11.36
    • #749 build(deps): bump ossf/scorecard-action from 1.0.1 to 1.1.0
    • #755 build(deps-dev): bump typescript from 4.6.4 to 4.7.3
    • #759 build(deps-dev): bump @​types/node from 16.11.36 to 16.11.39
    • #762 build(deps-dev): bump @​types/node from 16.11.39 to 16.11.40
    • #746 build(deps-dev): bump @​vercel/ncc from 0.33.4 to 0.34.0
    • #757 build(deps): bump ossf/scorecard-action from 1.1.0 to 1.1.1
    • #760 build(deps): bump openpgp from 5.2.1 to 5.3.0
    • #748 build(deps): bump actions/upload-artifact from 2.3.1 to 3.1.0
    • #766 build(deps-dev): bump typescript from 4.7.3 to 4.7.4
    • #799 build(deps): bump openpgp from 5.3.0 to 5.4.0
    • #798 build(deps): bump @​actions/core from 1.8.2 to 1.9.1
    Commits
    • d9f34f8 release: update changelog and version to 3.1.1 (#828)
    • 0e9e7b4 Plumb failCi into verification function. (#769)
    • 7f20bd4 build(deps): bump @​actions/core from 1.8.2 to 1.9.1 (#798)
    • 13bc253 build(deps): bump openpgp from 5.3.0 to 5.4.0 (#799)
    • 5c0da1b Trim arguments after splitting them (#791)
    • 68d5f6d Fix network entry in table (#783)
    • 2a829b9 Switch to v3 (#774)
    • 8e09eaf build(deps-dev): bump typescript from 4.7.3 to 4.7.4 (#766)
    • 39e2229 build(deps): bump actions/upload-artifact from 2.3.1 to 3.1.0 (#748)
    • b2b7703 build(deps): bump openpgp from 5.2.1 to 5.3.0 (#760)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies github_actions 
    opened by dependabot[bot] 1
  • fixes #198 negative send/receive deadlines do not work

    fixes #198 negative send/receive deadlines do not work

    This actually affected pretty much all the protocols and both send and receive deadlines. While here we've also made sure that a non-blocking check will not fail if a message can immediately be sent or received.

    opened by gdamore 1
  • Want context.Context versions of send, receive

    Want context.Context versions of send, receive

    We code that uses timeout options, but these APIs were designed back before context.Context existed.

    It would be good to introduce APIs like

    RecvContext() and RecvMsgContext() that took a context as their first argument. Arguably, the former receive functions could then be implemented in terms of these. We would then deprecate the legacy options.

    This would also potentially provide a nice API for cancellation.

    opened by gdamore 0
  • Upgrade from http.ResponseWriter, *http.Request to mangos.Socket

    Upgrade from http.ResponseWriter, *http.Request to mangos.Socket

    Forgive me if I missed a way to do this.

    I know it's possible to upgrade from a "http.ResponseWriter, *http.Request" pair in Gorilla to a gorilla.Conn. I also understand that mangos uses gorilla underneath for it's websockets, right? It there a way I can upgrade "http.ResponseWriter, *http.Request" pair to a mangos.Socket somehow?

    If not, should I consider writing a PR ?

    opened by cameronelliott 1
  • negative send/receive deadlines do not work

    negative send/receive deadlines do not work

    If OptionRecvDeadline is set to a negative number on a sub socket (could apply to other protocols too, I did not test), calling the the Recv method will block until a data is received. According to the documentation, this should cause Recv to be a non-blocking operation.

    bug 
    opened by ahobsonsayers 1
Releases(v3.4.2)
  • v3.4.2(Aug 11, 2022)

  • v3.4.1(Mar 29, 2022)

    This removes the use of the insecure RSA-SHA1 cipher suites from the test suites. It also fixes a minor issue with a double import in the respondent code.

    Finally the CI/CD is updated to verify against more modern Go versions.

    Source code(tar.gz)
    Source code(zip)
  • v3.4.0(Mar 29, 2022)

    The principal new feature in this release is support for the new PairV1 protocol from NNG (see GitHub.com/nanomsg/nng).

    This implementation of PAIRv1 supports connecting to NNG peers that might be in monogamous or polyamorous mode. It does not support polyamorous mode itself. That is, you can use this to talk to a polyamorous peer, but your mangos socket itself can only have one partner. (Polyamorous mode is considered a deprecated feature in NNG, and will be replaced with a proper mesh protocol at some point in the future.)

    Various dependencies also were updated.

    Note that the next minor release will likely drop support for Go 1.14 and earlier.

    Source code(tar.gz)
    Source code(zip)
  • v3.3.0(Mar 29, 2022)

    This release principally updates our dependencies, and cleans up various parts of the documentation.

    The increase in the minor number was inadvertent, and we do not believe any new user accessible features were added since 3.2.1.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.1(Mar 29, 2022)

  • v3.2.0(Mar 29, 2022)

    This release introduces a new feature, OptionFailNoPeers, which causes a REQ socket to fail if there are no connected peers when the request is issued (via Send). This avoids having to wait a for requests that might otherwise have longer timeouts. See #224 for more information.

    Source code(tar.gz)
    Source code(zip)
  • v3.1.3(Mar 29, 2022)

  • v3.1.2(Oct 5, 2020)

  • v3.1.1(Oct 5, 2020)

    This release simply makes the option symbols for some IPC options available universally at compile time. Using these options where not supported (e.g. trying to set UNIX style ownership on a Windows named pipe) still fails, but this allows portable code to be written that can cope with these differences at run time, hopefully reducing friction in their use.

    (This release is busted, DO NOT USE.)

    Source code(tar.gz)
    Source code(zip)
  • v3.1.0(Oct 5, 2020)

    This minor release principally adds support for improved handling of credentials on UNIX systems.

    • On Linux and illumos/Solaris systems, it is possible to obtain IPC peer credentials and process ID from the pipe. See OptionPeerPID, OptionPeerUID, etc.
    • On all UNIX style systems, it is possible to set the socket permission and ownership using ipc.OptionIpcSocketPermissions, ipc.OptionSocketOwner, and ipc.OptionSocketGroup.
    Source code(tar.gz)
    Source code(zip)
  • v3.0.2(Sep 5, 2020)

  • v2.0.9(Aug 18, 2020)

    This is a bug fix release, and includes three fixes that were backported from the v3 (master) branch.

    This brings v2 inline with v3.0.1, at least as far as bug fixes and core functionality is concerned. (Test suites and the performance tests were not updated however.)

    These all relate to improvements in the stability and performance of the REQ protocol.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.1(Mar 24, 2020)

    Version 3.0.1 improves the performance of the REQ protocol, particularly when used with very large messages, by reducing data copies. It also contains a fix which could lead to a panic when REP peers disconnect while they are holding a request for service.

    Source code(tar.gz)
    Source code(zip)
  • v3.0.0(Mar 24, 2020)

    This release starts from the last version 2.0 release, but introduces a new import URL located on our own vanity server. If using this, import from "go.nanomsg.org/mangos/v3" Note that this requires modules, or at least a module aware version of the go toolchain.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.8(Jan 15, 2020)

    This is version 2.0.8, principally a bug fix release. Yes, we said v2.0.7 was going to the be the last v2.0.x release. We lied (but we didn't mean to!)

    This bug fix release addresses two bugs, but it includes a potential significant performance boost, particularly for PUB/SUB and SURVEYOR uses with many subscribers or respondents. (BUS and STAR also benefit.)

    • fixes #175 Use reference counting on messages to reduce copying
    • fixes #177 OptionSubscribe topic uses reference instead of copy
    • fixes #179 Panic in Message.Dup

    Some minor documentation fixups were included as well. If all goes according to plan, this will be the last v2.0.x release. (Famous last words...)

    Note that two new APIs were introduced for Message, the MakeUnique and Clone API. Callers are discouraged from using them in application code -- these are intended for use in protocol and transport implementations to reduce data copies. Incorrect use can lead to data corruption.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.7(Dec 20, 2019)

    This release includes yet more testing, to cover every single line of code in the project (though occasionally due to differences in timing some difficult to reach corner cases will not be tested on every single test run.)

    As a result, we've made a number of additional fixes -- the pipe redialing in particular was fairly busted, and it should be rock solid now. As a result of this testing we are also injecting protocol errors, and so we have a high level of confidence in mangos being robust against a remote attacker.

    macat grew some new flags (--count, --format) as well. Technically that probably should have warranted a minor release, but as that's not part of the API, we felt this safe. Also, macat now uses my new optopia (github.com/gdamore/optopia) library for parsing command line options.

    This will be the last release of 2.0,x, as the next set of updates planned are targetted at making the library easier to use by adding a number of additional API features -- hence needing a minor 2.1 release.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.6(Dec 9, 2019)

    This update includes sweeping changes intended to fix numerous bugs in the transports and protocols. Literally thousands of lines of code have been introduced, nearly all of them test suites -- but as a result of adding these test suites we have found and squashed a horde of bugs.

    Updating is highly recommended.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.5(Nov 25, 2019)

    NOTE: This fix addresses a security problem in the websocket transport. If you use ws:// or wss:// then you are strongly encouraged to upgrade.

    • Require v1.4.1 of Gorilla WebSocket to address DoS security fix
    • Significant refactoring of close handling for pipes and sockets -- should reduce lock contention and improve readability.
    • Work on expanded test coverage for protocols (start of work, will be ongoing)
    Source code(tar.gz)
    Source code(zip)
  • v2.0.4(Nov 25, 2019)

  • v2.0.3(Nov 18, 2019)

  • v2.0.0(Nov 3, 2018)

    This is the first version of mangos v2. This is built on top of mangos v1, but includes a number of breaking changes.

    • The compat package is gone.

    • A new OpenContext and support API for building concurrent applications is available for req, rep, surveyor, respondent, and sub protocols.

    • Dialing is "synchronous" by default now (so if a peer is down at first, the caller will get a chance to notice.) . This is tunable by the OptionDialAsynch socket option for dialers.

    • The old Port API has been completely revamped with a better Pipe API, which includes notifications before and after the pipe has been attached to the socket (and also detached from the socket).

    • Significant performance improvements have been made.

    • The REQ/REP pattern is much more responsive to the case where a peer drops while a request is outstanding.

    • It is now sufficient to just import a transport packet, the old method of explicitly adding a transport is gone.

    • The underlying API for transport and protocol implementations has undergone quite a lot of change. These APIs are still not really stable, so and may change further. (We consider these APIs "internal" for now.)

    Source code(tar.gz)
    Source code(zip)
Owner
nanomsg
Nanomsg Project
nanomsg
franz-go contains a high performance, pure Go library for interacting with Kafka from 0.8.0 through 2.7.0+. Producing, consuming, transacting, administrating, etc.

franz-go - Apache Kafka client written in Go Franz-go is an all-encompassing Apache Kafka client fully written Go. This library aims to provide every

Travis Bischel 761 Sep 29, 2022
A RabbitMQ connection pool write in pure go

A RabbitMQ connection pool write in pure go

LiangKai 3 Oct 8, 2021
Simple-messaging - Brokerless messaging. Pub/Sub. Producer/Consumer. Pure Go. No C.

Simple Messaging Simple messaging for pub/sub and producer/consumer. Pure Go! Usage Request-Response Producer: consumerAddr, err := net.ResolveTCPAddr

IchHabeKeineNamen 1 Jan 20, 2022
graylog-golang is a full implementation for sending messages in GELF (Graylog Extended Log Format) from Go (Golang) to Graylog

graylog-golang is a full implementation for sending messages in GELF (Graylog Extended Log Format) from Go (Golang) to Graylog

Robert Kowalski 79 Aug 12, 2022
🔊Minimalist message bus implementation for internal communication

?? Bus Bus is a minimalist event/message bus implementation for internal communication. It is heavily inspired from my event_bus package for Elixir la

Mustafa Turan 275 Aug 31, 2022
The implementation of the pattern observer

Event This is package implements pattern-observer Fast example import ( "github.com/agoalofalife/event" ) func main() { // create struct e := even

Ilya 48 Sep 27, 2022
Package notify provides an implementation of the Gnome DBus Notifications Specification.

go-notify Package notify provides an implementation of the Gnome DBus Notifications Specification. Examples Display a simple notification. ntf := noti

null 62 Sep 27, 2022
Server-sent live updates: protocol and reference implementation

Protocol and Reference Implementation Mercure is a protocol allowing to push data updates to web browsers and other HTTP clients in a convenient, fast

Kévin Dunglas 3k Sep 27, 2022
Implementation of the NELI leader election protocol for Go and Kafka

goNELI Implementation of the NELI leader election protocol for Go and Kafka. goNELI encapsulates the 'fast' variation of the protocol, running in excl

Obsidian Dynamics 58 Jul 6, 2022
Embedded, Fast and Persistent bigqueue implementation

bigqueue bigqueue provides embedded, fast and persistent queue written in pure Go using memory mapped (mmap) files. bigqueue is now thread safe as wel

null 432 Sep 24, 2022
ChizBroker is a fast and simple GRPC based implementation of kafka.

Chiz Broker: a broker for fun ChizBroker is a fast and simple GRPC based implementation of kafka. Features: Ready to be deployed on kubernetes Prometh

Sina Amininasab 41 Sep 7, 2022
POC of an event-driven Go implementation

Event Driven example in Golang This POC shows an example of event-driven architecture with a working domain event broker, an event producer and a cons

Fede Barcelona 0 Nov 2, 2021
Confluent's Apache Kafka Golang client

Confluent's Golang Client for Apache KafkaTM confluent-kafka-go is Confluent's Golang client for Apache Kafka and the Confluent Platform. Features: Hi

Confluent Inc. 3.6k Sep 27, 2022
socket.io library for golang, a realtime application framework.

go-socket.io go-socket.io is library an implementation of Socket.IO in Golang, which is a realtime application framework. Current this library support

Googol Lee 4.8k Sep 25, 2022
golang client library to Viessmann Vitotrol web service

Package go-vitotrol provides access to the Viessmann™ Vitotrol™ cloud API for controlling/monitoring boilers. See https://www.viessmann.com/app_vitoda

Maxime Soulé 20 Sep 27, 2022
golang long polling library. Makes web pub-sub easy via HTTP long-poll server :smiley: :coffee: :computer:

golongpoll Golang long polling library. Makes web pub-sub easy via an HTTP long-poll server. New in v1.1 Deprecated CreateManager and CreateCustomMana

J Cuga 607 Sep 18, 2022
Golang push server cluster

gopush-cluster gopush-cluster is a go push server cluster. Features light weight high performance pure golang implementation message expired offline m

Terry.Mao 2.1k Sep 29, 2022
A push notification server written in Go (Golang).

gorush A push notification micro server using Gin framework written in Go (Golang) and see the demo app. Contents gorush Contents Support Platform Fea

Bo-Yi Wu 6.6k Sep 26, 2022
websocket based messaging server written in golang

Guble Messaging Server Guble is a simple user-facing messaging and data replication server written in Go. Overview Guble is in an early state (release

Sebastian Mancke 152 Jul 19, 2022