20210304思考下设计一个数据结构为map[string]net.Conn的Sender作为数据流动框架末端的可行性 - ziyouzy/2021blog GitHub Wiki

之前就发现当listen到一个net.Conn后是否应该先放入一个mgr，然后再把同一个net.Conn装配至usr-io808结构类
这里探讨的Sender或许和这个mgr是同一个东西，因为如果直接把net.Conn装配给内层某个riverconn,后立刻开启下次循环，外层就在也拿不到这个net.Conn了，这确实在逻辑上是行不通的 在或者说，装配的最正确逻辑应该如下:

go func(){
    for {
    /*在这里就会阻塞，或者说目前这里智能监听到一种类型的连接，也就是tcp*/
    con, err := listener.Accept()
    if err != nil { fmt.Println("tcp第三次握手错误:",err.Error());    continue }
    fmt.Println("tcp第三次握手成功高，开始收容")

        Clients[con.RemoteAddr().String()] =con//先放入字典

    //----uniqueid格式为：192.168.1.10:6668:TCP
    switch con.RemoteAddr().String(){
    case "192.168.1.10:6668":
    UniqueId = fmt.Sprintf("%s:TCP",con.RemoteAddr().String()) 

    testClinet := &Client{
        UniqueId: 			UniqueId,
	Signals: 			Signals,
	Errors: 			Errors,
	Fin_StampsNews: 	        Fin_StampsNews,
    }
    }
}()  

可以这么理解：
当初考虑需要有个net.Conn的MGR的意义，到如今或许变得只有一个了，那就是能让listen()所在的这一层找到各个在线的conn 初期这样设计就好，随着设计的深入，如果需要在给这个MGR添加更复杂的功能，那也就等遇到了再说吧