riijj

师傅，你好 ，我遇到的情况和他的还不一样，在c2profile.c里面已经添加了相关的容错代码，实际的c2并未退出。rebind的几个函数里面打印发送的日志，发现teamserver长时间不在线后就不再发包了，也就是不再调用 cc2_rebind_http_get_send函数，怀疑和retryCount可能有关。

另外，前端采用了cf的cdn，架构为cf->nginx->teamserver

师傅你好，请复测，发现存在如下的bug： - 当CS为4.5时，不论使用3.0.2还是3.1.0生成的beacon发送一定数量的包后，就不再发包，teamserver端看到beacon下线，怀疑在cs4.5上存在bug - 当CS为4.4时，使用3.1.0生成的beacon，同时使用了c2profile，在teamserver下线一段时间后，不论是否使用config_demo.ini后，重新启动teamserver均不再上线，kill掉tcp连接后重新上线。 复现的步骤如下： 1.生成两个beacon，均使用c2profile，c2profile.c中编写相关的协议函数，同时在代码中设置了Connection: Close及void cc2_retryConnect(int count) {} void cc2_retryConnect(int count) {}的代码如下： void cc2_retryConnect(int count) { printf("cc2_retryConnect() started , count :%d\n",count); int sleep_time = count + 5;...

> 复现环境： 3. 采用类似相同架构 cf -> proxy -> teamserver ，测试teamserver & proxy & cf 关闭都可以保持正常状态 6. 这里的nginx502是否是nginx的某些配置导致的错误？或者是profile.c中定义的一些特殊HTTP头造成的 7. 这个行为像两种情况造成的 > > ``` > A. 是beacon HTTP请求后，server未响应，导致连接一直处于等待状态中(无主动超时断开的设计，靠操作系统自身超时断开) > B. 是beacon请求后，server响应不正确，例如HTTP响应需接受103字节，实际仅接收到102字节，那么这里会卡在最后一个字节的接收上，直至超时退出进入下一次请求寻队列 >...