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的相关方法