当客户端主动断开连接时，服务器端是会收到的 about msgserver HOT 7 CLOSED

如果可以，我愿意提交 pr

from msgserver.

你说的也很有道理，但是我觉得在GC间隔时间内并不会有太多无效连接占用内存空间，而且接收每个客户端断开信息需要额外的增加线程，各有利弊吧。不过你可以详细说说你的看法，一起研讨下

from msgserver.

不需要增加线程：

在 handler 最后面增加：

	defer conn.Close()
	for {
		var buf = make([]byte, 512)
		_, err := conn.Read(buf)

		if err != nil {
			// 客户端离线
			ch := make(chan string)
			g.Pool.ReadChan(ch)
			ch <- conn.RemoteAddr().String()
			return
		}
	}

这里可以捕获到连接断开，然后就可将这个连接信息“立即”从 map 中删除，而不必要等下一个 GC 后才知道客户端离线了

from msgserver.

这样做还有一个好处就是可以知道在线的客户端，当然，这个在线信息也不是特别准确，对于没有收到客户端主动断开信令的，或者网络突然物理断开的，就只能靠 GC 了

from msgserver.

实际上我的设计是handler执行完这个goroutine就已经结束了，如果按你说的，那么这个goroutine一直是出于阻塞状态的，有多少个tcp连接就会多等量的goroutine

from msgserver.

我没有使用tcp通道来接收客户端消息也是这个原因，推送服务大多是推的动作，其他少量收的动作，使用http api的方式，这样基于事件驱动的设计能更多的减少性能消耗

from msgserver.

是的，是需要等量的 goroutine 在等待，这个代价在量高的情况下应该不小的…… 完成推送才是主要任务
这个讨论就到这里吧，Thanks♪(･ω･)ﾉ

from msgserver.