MCPcopy
hub / github.com/lesismal/nbio

github.com/lesismal/nbio @v1.6.11 sqlite

repository ↗ · DeepWiki ↗ · release v1.6.11 ↗
656 symbols 2,126 edges 58 files 529 documented · 81%
README

NBIO - NON-BLOCKING IO

Mentioned in Awesome Go MIT licensed Go Version Build Status Go Report Card

Recommendation

Based on years of development and testing of nbio, I have drawn some conclusions:

For massive connection scenarios, combined with memory pools and goroutine pools, it can effectively reduce the number of goroutines and objects, thereby lowering memory consumption and GC pressure, avoiding OOM and significant STW. For example, in a million WebSocket 1k payload echo test, nbio can maintain memory at 1GB with 100k TPS.

For regular connection scenarios, nbio's performance is inferior to the standard library due to goroutine affinity, lower buffer reuse rate for individual connections, and variable escape issues.

The vast majority of business scenarios using Golang do not require support for massive connections. The few scenarios that do require massive connections are mostly infrastructure such as gateways and proxies, and these types of infrastructure have higher requirements for performance and hardware resource overhead, where C/C++/Rust are more suitable.

Therefore, the scenarios where nbio can demonstrate its advantages are very limited.

For WebSocket in regular connection scenarios

I recommend: - https://github.com/lxzan/gws - https://github.com/antlabs/quickws

While gorilla/websocket is mature and stable, its default ReadMessage performance is poor, and it requires additional encapsulation for reading and writing to avoid consistency issues, concurrent timing problems, and the issue where a single connection's write blocking in broadcast scenarios causes other connections to wait.

nbio, gws and quickws all provide better out-of-the-box designs, which spare users the trouble of doing more encapsulation work on gorilla/websocket.

However, as mentioned above, nbio has no advantage in regular connection scenarios, and it supports more features with more complex compatibility code. Its performance in regular connection scenarios is inferior to gws and quickws, so I recommend gws and quickws.

Some other well-implemented epoll libs

nbio's functionality is somewhat complex.

If anyone is just interested in exploring the epoll wrapper part, I recommend: - https://github.com/urpc/uio - https://github.com/antlabs/pulse

Contents

Features

Cross Platform

  • [x] Linux: Epoll with LT/ET/ET+ONESHOT supported, LT as default
  • [x] BSD(MacOS): Kqueue
  • [x] Windows: Based on std net, for debugging only

Protocols Supported

  • [x] TCP/UDP/Unix Socket supported
  • [x] TLS supported
  • [x] HTTP/HTTPS 1.x supported
  • [x] Websocket supported, Passes the Autobahn Test Suite, OnOpen/OnMessage/OnClose order guaranteed

Interfaces

  • [x] Implements a non-blocking net.Conn(except windows)
  • [x] SetDeadline/SetReadDeadline/SetWriteDeadline supported
  • [x] Concurrent Write/Close supported(both nbio.Conn and nbio/nbhttp/websocket.Conn)

Quick Start

package main

import (
    "log"

    "github.com/lesismal/nbio"
)

func main() {
    engine := nbio.NewEngine(nbio.Config{
        Network:            "tcp",//"udp", "unix"
        Addrs:              []string{":8888"},
        MaxWriteBufferSize: 6 * 1024 * 1024,
    })

    // handle new connection
    engine.OnOpen(func(c *nbio.Conn) {
        log.Println("OnOpen:", c.RemoteAddr().String())
    })
    // handle connection closed
    engine.OnClose(func(c *nbio.Conn, err error) {
        log.Println("OnClose:", c.RemoteAddr().String(), err)
    })
    // handle data
    engine.OnData(func(c *nbio.Conn, data []byte) {
        c.Write(append([]byte{}, data...))
    })

    err := engine.Start()
    if err != nil {
        log.Fatalf("nbio.Start failed: %v\n", err)
        return
    }
    defer engine.Stop()

    <-make(chan int)
}

Examples

TCP Echo Examples

UDP Echo Examples

TLS Examples

HTTP Examples

HTTPS Examples

Websocket Examples

Websocket TLS Examples

Use With Other STD Based Frameworkds

More Examples

1M Websocket Connections Benchmark

For more details: go-websocket-benchmark

# lsb_release -a
LSB Version:    core-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.6 LTS
Release:        20.04
Codename:       focal

# free
              total        used        free      shared  buff/cache   available
Mem:       24969564    15656352     3422212        1880     5891000     8899604
Swap:             0           0           0

# cat /proc/cpuinfo | grep processor
processor       : 0
processor       : 1
processor       : 2
processor       : 3
processor       : 4
processor       : 5
processor       : 6
processor       : 7
processor       : 8
processor       : 9
processor       : 10
processor       : 11
processor       : 12
processor       : 13
processor       : 14
processor       : 15


# taskset
run nbio_nonblocking server on cpu 0-7

--------------------------------------------------------------
BenchType  : BenchEcho
Framework  : nbio_nonblocking
TPS        : 104713
EER        : 280.33
Min        : 56.90us
Avg        : 95.36ms
Max        : 2.29s
TP50       : 62.82ms
TP75       : 65.38ms
TP90       : 89.38ms
TP95       : 409.55ms
TP99       : 637.95ms
Used       : 47.75s
Total      : 5000000
Success    : 5000000
Failed     : 0
Conns      : 1000000
Concurrency: 10000
Payload    : 1024
CPU Min    : 0.00%
CPU Avg    : 373.53%
CPU Max    : 602.33%
MEM Min    : 978.70M
MEM Avg    : 979.88M
MEM Max    : 981.14M
--------------------------------------------------------------

Magics For HTTP and Websocket

Different IOMod

IOMod Remarks
IOModNonBlocking There's no difference between this IOMod and the old version with no IOMod. All the connections will be handled by poller.
IOModBlocking All the connections will be handled by at least one goroutine, for websocket, we can set Upgrader.BlockingModAsyncWrite=true to handle writing with a separated goroutine and then avoid Head-of-line blocking on broadcasting scenarios.
IOModMixed We set the Engine.MaxBlockingOnline, if the online num is smaller than it, the new connection will be handled by single goroutine as IOModBlocking, else the new connection will be handled by poller.

The IOModBlocking aims to improve the performance for low online service, it runs faster than std. The IOModMixed aims to keep a balance between performance and cpu/mem cost in different scenarios: when there are not too many online connections, it performs better than std, or else it can serve lots of online connections and keep healthy.

Using Websocket With Std Server

package main

import (
    "fmt"
    "net/http"

    "github.com/lesismal/nbio/nbhttp/websocket"
)

var (
    upgrader = newUpgrader()
)

func newUpgrader() *websocket.Upgrader {
    u := websocket.NewUpgrader()
    u.OnOpen(func(c *websocket.Conn) {
        // echo
        fmt.Println("OnOpen:", c.RemoteAddr().String())
    })
    u.OnMessage(func(c *websocket.Conn, messageType websocket.MessageType, data []byte) {
        // echo
        fmt.Println("OnMessage:", messageType, string(data))
        c.WriteMessage(messageType, data)
    })
    u.OnClose(func(c *websocket.Conn, err error) {
        fmt.Println("OnClose:", c.RemoteAddr().String(), err)
    })
    return u
}

func onWebsocket(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        panic(err)
    }
    fmt.Println("Upgraded:", conn.RemoteAddr().String())
}

func main() {
    mux := &http.ServeMux{}
    mux.HandleFunc("/ws", onWebsocket)
    server := http.Server{
        Addr:    "localhost:8080",
        Handler: mux,
    }
    fmt.Println("server exit:", server.ListenAndServe())
}

Credits

Contributors

Thanks Everyone: - acgreek - acsecureworks - arunsathiya - byene0923 - guonaihong - isletnet - liwnn - manjun21 - maxkidd - om26er - rfyiamcool - sunny352 - sunvim - wuqinqiang - wziww - yicixin - [youzhixiaomutou](https:

Extension points exported contracts — how you extend this code

Processor (Interface)
Processor . [3 implementers]
nbhttp/processor.go
Allocator (Interface)
(no doc) [4 implementers]
mempool/allocator.go
Logger (Interface)
Logger defines log interface. [1 implementers]
logging/log.go
Protocol (Interface)
(no doc) [2 implementers]
protocol_stack.go
ParserCloser (Interface)
(no doc) [2 implementers]
nbhttp/parser.go
DebugAllocator (Interface)
(no doc) [1 implementers]
mempool/allocator.go

Core symbols most depended-on inside this repo

Unlock
called by 99
conn.go
Close
called by 99
nbhttp/processor.go
Lock
called by 73
conn.go
Write
called by 53
protocol_stack.go
Error
called by 51
logging/log.go
Add
called by 47
protocol_stack.go
String
called by 46
mempool/allocator.go
Free
called by 41
mempool/allocator.go

Shape

Method 414
Function 171
Struct 58
Interface 7
TypeAlias 5
FuncType 1

Languages

Go100%

Modules by API surface

nbhttp/processor.go55 symbols
conn_unix.go52 symbols
nbhttp/websocket/conn.go49 symbols
nbhttp/websocket/upgrader.go33 symbols
nbhttp/engine.go31 symbols
conn_std.go30 symbols
nbhttp/client.go25 symbols
engine.go25 symbols
poller_kqueue.go17 symbols
poller_epoll.go17 symbols
logging/log.go17 symbols
conn.go17 symbols

Dependencies from manifests, versioned

github.com/lesismal/llibv1.2.3 · 1×

For agents

$ claude mcp add nbio \
  -- python -m otcore.mcp_server <graph>

⬇ download graph artifact