Skip to content

Releases: lesismal/nbio

v1.3.13

09 May 04:11
6e2a0b1
Compare
Choose a tag to compare
  1. websocket: fix goroutine leak for blocking mod connection with async write
  2. github actions: fix autobahn and codeql error

v1.3.12

23 Apr 01:49
22b16c4
Compare
Choose a tag to compare

v1.3.11

12 Apr 06:54
ba8d4c4
Compare
Choose a tag to compare
  1. fix nil pointer assertion when release http request body
  2. simplify mempool implementation
  3. http: support multi listeners
  4. taskpool: check nil func
  5. tidy, update doc

v1.3.10

02 Feb 15:25
45fe2ec
Compare
Choose a tag to compare

#265 fix udp server socket fd closing leak on uni*

v1.3.9

15 Jan 08:46
21bd6b3
Compare
Choose a tag to compare

fix shutdown panic

v1.3.8

09 Dec 09:48
4303fd8
Compare
Choose a tag to compare

fix http body type assertion, opt log

v1.3.7

17 Nov 15:32
4c66d85
Compare
Choose a tag to compare
  1. assign port automatically
  2. make Listen/ListenUDP configurable
  3. give up avoiding race warnings
  4. add ConnTypeUnix

v1.3.6

03 Nov 16:11
76daa64
Compare
Choose a tag to compare

bug fix: #238

v1.3.5

30 Oct 14:39
49d4fd2
Compare
Choose a tag to compare

Support different IO Mod for http and websocket

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 to handle writting with one more goroutine and then avoid Head-of-line blocking on broadcast 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.

The websocket now also support std http server, and I got a better performance and lower mem/cpu cost than std in a simple load test. The example of using with std http server would be like this:

package main

import (
	"fmt"
	"log"
	"net/http"

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

func echo(w http.ResponseWriter, r *http.Request) {
	u := websocket.NewUpgrader()
	u.OnMessage(func(c *websocket.Conn, mt websocket.MessageType, data []byte) {
		c.WriteMessage(mt, data)
	})
	_, err := u.Upgrade(w, r, nil)
	if err != nil {
		log.Print("upgrade:", err)
		return
	}
}

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

v1.3.4

14 Oct 09:03
5c8940c
Compare
Choose a tag to compare
  1. fix websocket.Dialer concurrent issue: #225
  2. support unix addr config