初识通信

通信这部分的学习有一段时间了，感觉难度比较大。觉得跟之前的学习有很大的不同，复杂多了，而且这里更容易出错，而且很多时候都是些自己觉得莫名奇妙的错误，又不好调试。有时候自己的服务器和客户端测试成功了，但和搭档通信测试时，说不定又要很纠结。因为这里最重要的就是协议了，所以双方在通信之前一定要定好协议。这里没做好后面基本上就是瘫痪了。我之前过了一段抄代码的日子，这里就先不说了。感觉通信就是数据的传送，一端发送了一种代表所谓的我们称之为某种意义的数据，也可以说是消息。另一方接收，根据定好的协议将其解析为具有那种意义的消息。最开始接触通信时，我们只是单纯的字节，字符串的传送，双方什么界面都可以不要，客户端使用的是系统提供的telnet工具程序。协议是只要遇到换行，服务器就认为是一条消息。再到后面的多人聊天室也是在这个基础上的加强。不过还是有很大的局限性。

 

到现在的XMPP，其实也就是换了一种协议罢了，双方不再以换行为消息的结束符了，而是拥有了一种固定的消息格式。一条消息会有不同的标签组成，规定了不同的标签代表不同的意义。这样貌似多人聊天室的功能可以扩展一点点了。

  

   说了这么多，但还是要强调下协议的重要性啊。现在就主要讲我在做这个项目时遇到的几个大问题。问题实在太多了，就不一一列出了。

   1.不得不说，协议定好了，就一定要按规矩来。我们那组事先也是把协议定好了。但是我在做群聊的时候，我就忘了协议，根本就没想到协议里的群聊。而是自己在客户端处理的，并没有通过服务器，没用上协议。然后和搭档测试的时候，结果就不用多说了啊。。。

2.当我们测试成功关闭客户端时，服务器那边就挂了，java.net.SocketException: Connection reset 死循环。上网搜了一下，说法不一，我大概也就记得好像是说，一种是这种异常客户端和服务器都可能出现，当一端主动断开时，另一端如果还在发送数据，这时候就会出现这种异常了。另一种是说当一端退出时未关闭该连接，而另一端如果还在从连接中读数据，也会抛出该异常。所以后来就给窗体添加窗体事件监听器。当聊天用户点击窗体关闭按钮时，先发送一条消息给服务器，告诉服务器现在可以关闭该客户的处理对象了。于是服务器将该用户的处理对象移除掉，并断开和它的连接，关闭当前处理线程对象。这样当客户关闭聊天窗体时，服务器不会出现死循环了。

 

3.还有一个就是服务器的界面上显示着当前在线的用户遇到的问题。这个表格在上一次的学习中就遇到了，只是当时保存用户用的是List队列，我们都知道它是有序的，可以根据下标找到用户。抄了书上的代码，查了一下API的TabelModel的方法，测试了几次，就出来了。

但是这次真的搞的很纠结。因为在这里保存用户的信息使用的是HashMap。这两个还是有很大的区别的。所以，TabelModel的public Object getValueAt(int rowIndex, int columnIndex) {}这个方法，我一直不知道怎么下手。两个参数不知道要怎么用。好像跟HashMap没什么关系啊？？到后来就问了胡老师，哎，纠结的是胡老师的教学模式是 授人以鱼，不如授人以渔。可是我还是不知道，第二天，我就问了晓盼，他说，HashMap不行，就转换成List。其实我当时是不赞同这个方法的，因为我觉得如果是HashMap<String ,Thread>并不能得到用户的密码。然后我就差不多要放弃了，不过还是想不通，为什么就出不来呢。后来才想到，那个方法是可行的，因为我忽略了用户注册登录时还用了一个HashMap。这样就可以得到我想要的了。

  

  结果是出来了，但发现自己好像成了一个机器人，完全不会思考了。所以以后这方面一定要多注意，做之前一定要多思考，思考有什么思路，有什么方法，而不是注重那个结果。因为我们都知道那个结果对我们都没有任何真实的意义！