gnet: a high-performance, lightweight, nonblocking, event-loop networking library written in pure Go

[panj...@gmail.com]

Github Page:

https://github.com/panjf2000/gnet

gnet is an Event-Loop networking framework that is fast and small. It makes direct epoll and kqueue syscalls rather than using the standard Go net package, and works in a similar manner as libuv and libevent.

gnet sells itself as a high-performance, lightweight, nonblocking network library written in pure Go which works on transport layer with TCP/UDP/Unix-Socket protocols, so it allows developers to implement their own protocols of application layer upon gnet for building diversified network applications, for instance, you get a HTTP Server or Web Framework if you implement HTTP protocol upon gnet while you have a Redis Server done with the implementation of Redis protocol upon gnet and so on.

gnet derives from project evio while having higher performance.

[Seth Bunce]

Really interesting work.

(observation)

The goroutine approach uses coroutines and abstracts i/o muxing in the language. The downside is having a bunch of coroutines (stacks sitting in memory) waiting for i/o completion. Directly dealing with the i/o muxing system calls requires communicating between an i/o thread and a worker thread (the reactor pattern). Bolting a thread pool to that for i/o completions (the proactor pattern, which is what I believe this package implements) implies that workers processing i/o completions must avoid blocking, which implies complexity. The go approach seems to be a memory for complexity tradeoff. I suspect that it's not worth bypassing the goroutine abstraction for "almost" all applications.

(opinion)

The gnet package seems less appealing in the context of go because the goroutine abstraction scales quite high and abstracts away complexity. I think that there are levels of performance that go cannot achieve without direct use of i/o muxer system calls. I think that achieving these levels of performance requires removing the abstraction between i/o muxing an application logic which is a very heavy cost. If the gnet package is successful it'll be because it's a dependency of a project that cannot achieve competitive performance without it. I suspect those use cases exist.

Seth

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4c09ec23-0c1f-4224-99c0-d69baa9cf145%40googlegroups.com.