看了说有关于client_id的问答，认为具体化时需要变通一下client_id的机制，下面看看我的做法是否有问题

补充 与workerman连接成功后，在memcache 里，key=session_id 的value数组里增加存储一下client_id

[attach]330[/attach]

不能这样简单的更改client_id的机制，client_id包含了对应连接所在的服务端IP 端口及连接编号信息，client_id属于全局唯一某个进程，client_id类似一个唯一的地址，这个client_id在其它进程中被分配到是无法正常使用的，比如sendToClient($client_id, $msg)，如果client_id根本没在属于它的进程里，那么client_id是无法收到数据的。Gateway是可以多服务器多进程的，连接被分配到哪个进程是无法确定的。

client—id,包括了3个信息ip port 连接编号，刷新页面是，只有连接编号会变化，是这样吗。我具体化时，连接编号改成userid,也就是改变clien_id的产生机制（预设条件是不登陆网站，不能聊天），这样会出现什么问题，或者是workerman如何恢复一个进程（client_id根本没在属于它的进程里，那么client_id是无法收到数据的），workerman的client-id,作用就是标识给谁发消息，想知道和进程是怎么配合的。

刷新页面，ip port(内部通讯端口) 连接编号都可能变化。
client_id可以看做是一个通讯地址，上面包含了ip(省份) port(城市) 和连接编号(街道门牌号)。每个ip:port对应一个全局唯一的进程(可以看做是实际的城市)。
假设原来client_id是ip(A省) port(B城市) C编号(门牌号)，刷新页面后这个client_id下线了。
新的连接被ip(A省) port(C城市) 对应的进程接受处理（被哪个进程处理无法控制）， 被分配了D编号，这时如果还想用原来的client_id（通讯地址），那么当向这个客户端发送数据时，就会发给ip(A省) port(B城市) C编号(门牌号)，而这个A省的B城市进程内根本找不到对应的客户端连接，也就无法发送消息给他。

也就是改变client_id规则后，很多针对该clien_id的接口将无法使用，比如gateway::sendToClient、Gateway::closeClient、Gatway::bindUid等等。

以上的规则是GatewayWorker的规则，和workerman无关，workerman里面没有client_id的概念。

最后除非你非常熟悉GatewayWorer，否则不建议改动GatewayWorker的代码

我尝试改动ConnectionId的测试方法，变成用户登录网站的userid.去掉binduid,send to uid 简化成遍历所有包含某个userid的client_id。改动的目标，能简单最好。改动上面的会遇到什么故障吗?

protected function generateConnectionId()
{
    // if (self::$_connectionIdRecorder >= 4294967295) {
    //self::$_connectionIdRecorder = 1;
    // }
    // $id = self::$_connectionIdRecorder ++;
    $id=$userid;//userid 是通过session——id,在memcahe,查寻到的
    return $id;
}

以上老大的回复，水平极高，到位不含糊，佩服。

刚刚想到一个更简单的方法，把产生cliet_id的机制简化，只包括ip,和port,不再包括ConnectionId，websocket建立连接并且成功后，关联新的client——id和网站的userid,.当业务逻辑需要用到send to uid 可以直接等于send to client——id.中间原来的有些函数可能会废掉吗

以上的想法基于不能让client_id神秘化，不能向左，也不能向右。简单好用。

刚刚测试，两个参数有串线的问题