gnet icon indicating copy to clipboard operation
gnet copied to clipboard

🚀 gnet is a high-performance, lightweight, non-blocking, event-driven networking framework written in pure Go./ gnet 是一个高性能、轻量级、非阻塞的事件驱动 Go 网络框架。

Results 62 gnet issues
Sort by recently updated
recently updated
newest added

看到数据结构:connections ,udpSockets 维护链接信息。但是大量连接,例如200w个tcp,这个内存很大,但是GC定时扫描这个大内存,导致cpu间隙很高。(无任何业务请求下) type eventloop struct { ln *listener // listener idx int // loop index in the engine loops list cache bytes.Buffer // temporary buffer for scattered bytes engine...

help wanted
question
needs investigation

恭喜发布 gnet v2 但 v2 中好像还没有实现 SetDeadline,非常期待这个功能。 不知何时能够实现?

enhancement
proposal
waiting for response
pending development

目前的接口都是通过React接收消息 然后返回结果给客户端 如果server想主动发消息给客户端呢 目前我看只有UDP模式下有SendTO方法 一个场景: 1. 客户端询问server执行结果并等待返回, 如果服务端没有处理完, 则需要for sleep操作, 这样就可能有几十微秒(30-50)的延迟 2. 如果server可以主动向客户端发送消息, 则服务端处理完成后直接告诉客户端结果, 客户端就无须主动询问 3. 上述的优化, 可以节省一次网络请求, 以及可能的几十微秒的处理延迟

enhancement
proposal

是否有gnet-http http2 quic http3等子项目?

help wanted
question

如题,gnet支持socks代理建立tcp连接吗

enhancement
proposal

**Please fill out the following system information before opening an issue:** - OS : windows 11 - Go version : 1.18.1 - gnet version : v2.0.3 **What is your question...

help wanted
question

**Please fill out the following system information before opening an issue:** - OS: win11 - Go version: 1.81.1 - gnet version: v2.0.3 **What is your question about gnet?** * gnet的socktoaddr.go文件中,`SockaddrToTCPOrUnixAddr()`函数在处理时,会调用`sockaddrInet4ToIP`或`sockaddrInet6ToIPAndZone`再处理一下IP...

help wanted
question
waiting for response

**Is your feature request related to a problem? Please describe.** 使用byteslice.Get()时得留意是否要自己做置零等初始化操作,不然底层数组可能遗留着上次的数据内容。 像socktoaddr.go的sockaddrInet4ToIP()函数中,就定义了一个合法的默认值pv4InIPv6Prefix,再做copy。 **Describe the solution you'd like** byteslice.Get()时,能否对从池子的取出来的slice做reset,和make得到的slice保持一致的返回情况。 **Describe alternatives you've considered** 没有找到什么比较好的方式可以清空底层数组 **Additional context** 无

enhancement
proposal
waiting for response

最近在为公司写高性能UDP服务,选择了gnet框架,目前发现2个比较明显的问题(都是针对于UDP的,TCP目前没有测过,也可能存在这些问题)。 - 在并发环境下,frame包错乱,需要同步的copy一份,大量的copy操作比较影响吞吐量; - 在并发环境下,且在linux系统(乌班图),连接对象gnet.Conn的RemoteAddr()方法,有一定概率返回nil,在windows下是没有问题的(当时在本地开发完,一发布在测试环境就会因为空指针而挂掉); 截图如下: ![1](https://user-images.githubusercontent.com/46668382/119450886-267dec80-bd67-11eb-8c11-d3778efe8202.png) **复现案例** 问题一在windows上就存在,linux是否有就没多考虑了,而问题二在windows上不存在,目前只在linux系统(乌班图)发现,复现案例的话其实一个简单demo就行了,重点是并发的去处理,而不是同步。

bug