浅谈Socket长连+多线程

缘由


 

     不知各位同仁有没有发现,用简单,无外乎就是都是一个流程

     1)监听链接

  2)校验链接是否是正常链接

  3)保存链接至全局静态字典

  4)开启新线程监听监听到的线程报文

  5)执行对应命令或者发送对应命令

  然后内部各种心跳,各种断线重连后释放缘由链接对象,重新保存对象;

  其实使用过程当中,貌似也就这些来着,不管再大的系统,也都是这个主流程,但是一些细节处理如何把握;

  下面我简单的说说我的处理

  (1)分布式

  (2)线程在无命令状态下自我销毁

  (3)线程状态监听

  

正文

 


  1 分布式

    背景:其实吧,也算是我公司穷,用不起高大上的硬件负载,其次能由于个人学历水平有限,搞不定各种开源导致的以下产物

    1.1 流程图

      

    1.2 流程说明

      分布式服务器中植入程序

        1)负责监听前置机发送当前连接数以及服务资源使用情况

        2)监听客户机连接并返回当前最优前置至客户机

        3)客户机连接前置

  2 前置机处理

     当客户机连接至前置机时,前置机实时监听后,开始监听到底是哪一台客户机连接上来,在用Dictionary<key,Socket>存储连接Socket,开启新线程监听客户机心跳等

             

    关键:连接初始化指令时,带入客户机唯一标识,这时字典中存储的key为唯一标识,value为Socket

    2.1 前置与分布式服务器

        1:根据字典中保存的Socket,监听Socket最后链接时间,以及判断Socket链接状态,统计连接成功数据,释放连接中断Socket,发送连接数至分布式服务器

        2:发送当前前置程序内存、CPU占用百分比等相关服务器硬件使用情况信息至分布式服务器

     2.2 前置与客户机

      因为连接上了,不止只收取命令,还需要发送对应命令至客户机,顾沿用字典中存储的长连接Socket对象,发送命令至客户机

      因为是命令,遵循应答原则,必须命令到达后,返回明确指令收到,在发送下一条命令,这里我使用了线程阻塞(当然,如果是IM发送聊天记录就没关系了,集体丢到客户机就可以了,返回成功后在更新发送时间以及发送状态就好)

   3 编码

      流程大家应该其实都懂,然后就是代码,因为马上年终尾牙,要去粗饭了,代码贴上来,各自领悟领悟哈

 

      为什么要重写堆栈,以为我的是设备,设备命令必须保证命令一定送达,而且有顺序的执行,则重新写了个规则

      

 DevQueue 栈堆

 

       线程管控,为什么要重写,因为发现了在多线程过程中,使用线程状态来判断线程是否在执行还是死睡状态不准导致,具体原因没有刨根。

      

 SocketTools

 

     线程阻塞

 WaitResponseMessage

 

    发送时处理

    

 SendWait

 

结尾


 

就这样了哈,过个好年,我们公司是小公司,现在目前也没有说几十万几百万台设备在对外使用,所以也没测试贫瘠来着,希望那天我能面对几十万台,几百万台设备同时上来让我耍耍,那时候工资花啦啦的,哈哈哈

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值