解决方案 »

  1.   

    多是有多多?是不是使用了同步?是不是没一个连接(或接)都使用了多线程?所以最终还是要看你tcp_listen的代码.. 不如玩玩异步吧比如http://www.cnblogs.com/chenxizhang/archive/2011/09/10/2172994.html
      

  2.   

    你这种“推给别人”的处理方式,遇到你说不清的问题,任何“配置什么,注意什么”都不可能解决你的问题。关键靠你自己。首先,你要保证你有办法随时在测试环境“重现”问题。然后,写日志,或者(如果测试环境中直接运行vs调试器的话)写上断言,让服务程序“连接不上”时看看有什么异常,最后一次开始监听客户端连接是什么时间,最后一次接收到数据是什么时间,等等,记录程序运行过程。最主要地,是在测试环境下运行的程序,(服务程序)尽量只有极个别时才用 try...catch。要让bug今早爆发出来,然后修改抛出异常的“那一条语句”就重新开始测试,而写try...catch会让你丧失debug能力。
      

  3.   

    先把精力放在“测试重现”上。当你可以保证80%以上的概率能够重现问题时,再进行第二步。第二步就是分析日志来设计一个新的、更直接的测试用例,希望让bug在你的 vs 里开发环境立刻出现,方便你将来进行程序调试。
      

  4.   

    telnet出问题就说明你的服务端的accept函数除了问题。 看看侦听socket上accept是不是有个数限制或同步相关的控制语句。
      

  5.   

    正常telnet能连上?
    为什么我不侦听端口23,telnet就连不上
      

  6.   


    即使没有我的程序,只要开通了端口,也是能telnet进去的!
      

  7.   

    服务器端报 错了:二进制流“0”不包含有效的 BinaryHeader。这可能是由于无效流,或由于在序列化和反序列化之间的对象版本更改我开了10个客户端同时去连服务器,每个客户端连接成功后,同时开两个线程去访问服务器,有时就会出现上面的错误!!!!!!
      

  8.   


    即使没有我的程序,只要开通了端口,也是能telnet进去的!
    需要完成accept操作,客户端才能完成telnet的第一步,然后等待发送字符串
      

  9.   


    即使没有我的程序,只要开通了端口,也是能telnet进去的!
    也就是说服务器死机了,这跟你的程序有一毛钱关系?
    我还没听说哪个程序跑着跑着,连接的多了就连ping都ping不通了的
    telnet端口跟你侦听的根本不是同一个端口,telnet进程跟你服务进程也根本不是同一个进程
    这俩进程一起挂掉,除了服务器死机,也就只有小概率事件了
      

  10.   


    即使没有我的程序,只要开通了端口,也是能telnet进去的!
    也就是说服务器死机了,这跟你的程序有一毛钱关系?
    我还没听说哪个程序跑着跑着,连接的多了就连ping都ping不通了的
    telnet端口跟你侦听的根本不是同一个端口,telnet进程跟你服务进程也根本不是同一个进程
    这俩进程一起挂掉,除了服务器死机,也就只有小概率事件了
    telnet 可以改端口的,telnet baidu.com 80,能连接,马上黑屏,跟curl应该差不多的东西,(我没用过curl)
      

  11.   

    会不会是线程多了,或者listen的数量设置有什么约束