WebSocket服务器的几次改进

1、最开始做单链接服务器:

用ServerSocket类打开监听以后,若收到链接,则开启一个客户端实行交流。

服务器端的监听过程停止。

若客户端结束任务,则程序结束。

 

2、循环监听的链接:

用while(true)无限监听,当收到客户端链接后,则开始客户端操作。

若客户端结束操作,则继续while循环

直到出错为止结束。

 

3、接着2的实验后,开始疯狂修理bug。

监听过程中各种客户端、服务器exception,都得写代码处理。

尤其链接WiFi网路,网络突然中断的时候,各种reline方法读到null,要判断NullPointerException

 

4、开始实验多线程编程

把服务器和客户端handle 各单独编为一个类。

服务器端有个ArrayList,里面为了存放无数个客户端handle而准备

服务器段打开后,依然像2那样,开始循环监听。

但是客户端开启后,给每个客户端新建一个Thread(线程),单独处理客户端任务。

这样,没收到一个客户端链接后,就让Thread单独处理客户端会话。而Server可以继续重复while(true)循环监听。

(一些缺点):

编好的Thread智能化不足,每个处理绘话模版一样

 

5、双ServerSocket模式

一个拿来监听SmartPhone端发来的客户端请求

一个拿来监听WebSocket端发来的客户端请求

两个Server监听的端口不一样。

(缺点)

相互交流困难。

(临时解决办法)

 在main函数里包含一个线程,在开启两个Server服务器后

此线程(暂称为check线程),用while(true)循环监察2个Server的客户端List里面的消息,然后相互转发,调用各个List里面客户端的send方法来发送消息

(临时方法缺点,消耗资源略大)

 

6、理想方法设想:

只有一个Server,单独监听一个端口,根据client成功建立链接后发来的不同消息,分配给不同的client handle(SmartPhone或者WebSocket或者Arduino Yun客户端)

每个客户端单独有个存放其他客户端实例的list,当需要发送消息给其他客户端的时候,此客户端直接从list里面调用方法。

(缺点,容易造成存储混乱,逻辑关系需要理清)

一个客户端坏死以后,要从所有“拥有此坏死客户端”的客户端里面删除此客户端实例

 

服务器设计思路过程:

  一开始基本上都是单线程思维,链接完,用完,然后关闭程序。作为客户端可以,但是作为服务器就有很大问题,无法做到“无人值守”。紧接着,用while(true)循环可以让服务器做到一定程度的“无人值守”,即实现部分自动化。这样一来,服务器就真正可以“提供服务”了。

 “无人值守”是自动化过程的第一步,第二步就是能够做到稳定的无人值守。这时候就需要考虑到各种纠错过程。Java里的Exception判断还是比较强大的。由于网络链接极有可能在任何时候断开,所以每个从远程链接来的Socket读取信息的过程(nextLine或者read方法),都要检测是否有IOException, SocketException或者NoSuchElementException之类的异常。

  其中NoSuchElementException发生频率较多,集中在客户端断开链接之后,服务器通过原有的Socket类生成的Scanner试图读取传输来的信息,结果发现为空。

  SocketException发生频率次之,在网络 异常(延迟等)的情况下,可能会发生。

  IOException发生频率较少。

  较为懒的异常处理方法是直接断开链接。那么客户端想继续获得服务,就得重新链接服务器。为了让客户端更智能,在懒得进行详细处理的情况下,只能修改客户端代码,让客户端在发觉链接被断开后,继续重连了。

 

JAVA异常信息Exception e,e的相关方法

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值