Java作业 - 聊天室系统

介绍

这学期Java的一个大作业室使用socket 实现一个聊天室系统，要求能够做到：

•  实现多客户端之间的交流
•  实现无限制的对方自由发送信息
•  实现文件传输 
•  另外，可以引入UI框架 

  我的代码可以分为两个相对独立的部分：UI框架实现 和  核心功能实现。虽然说本次任务的主要部分不是UI的实现，但从这次UI设计编写中我学到很多东西，对java中AWT和Swing的了解有很大的进步，所以把它分为一个独立的部分（专题），我觉得是很值得的。

这是粗略的效果图：

UI框架的实现

(ps: 在着手这个作业之前，我对Java AWT、Swing的了解，除了好奇就什么也没了. )

UI的细节实现就不需要多解释了。 编写UI的关键点，应该在布局的使用和掌控上面。

鉴于对JavaScri(Andriod端)的一点了解，感觉线性布局和绝对布局这两种，才是最好用的 。AWT里面的主要布局有：

• BorderLayout();
• FlowLayout();
• GridLayout();
• BoxLaYout();
• GridBagLayout();
• CardLayout();  

乍眼一看它根本没有什么线性布局和绝对布局.... 事实上SetLayout(null) 就是绝对布局。至于线性布局，BoxLayout() 和它有点相似，必要的时候可以将就着用吧。

绝对布局的缺点是使用起来繁琐，要求自己设置各种参数。另外，在使用绝对布局时控件不会自适应窗口。要解决这个问题，要么固定窗口大小..， 要么添加监听器：ComponentListener 和 WindowStateListener ，前者是监听窗口的拖动引起的大小改变，后者是监听窗口最大最小化。

将控件添加过程和控件布局分开来实现是很有必要的。这样做不仅讲代码分块，可读性高， 而且也方便了当使用绝对布局时的窗口自适应操作。

核心功能的实现

多用户信息交流

主要思想是使服务器端成为一个中转站，在接收和发送用户信息时，应该给数据添加一个存储额外信息的标签。当服务器端收到标签和数据时，按照标签里的数据进行相应的操作。

对于服务器端，接收信息和发送信息当然也得各自独立工作。由于是多客户之间的随意交流，所以在服务器接收到客户端发来的信息时，将标签信息和要传递的数据存起来，然后服务器的信息发送模块不断进行扫描，检出是否有待处理的存放的信息，根据标签的信息内容就可以转发到正确的客户端。

两用户无限制收发信息

这个的主要方法是使用多线程，使接收信息和发送信息成为两个并行的、独立的线程，这样就不会出现任何限制和冲突了。

多线程的在代码里的作用非常大：

服务器端：

对于服务器accept()接收到的每一个客户端，主程序必须新建一个线程来完成对该客户端发送过来的信息的接收功能。此外，还得有一个线程来实现总体的信息发送模块，即上面提到的信息扫描处理模块。

客户端：

对于每一个客户端，都必须添加一个信息发送线程和信息接收线程。一个客户端可以响应多个其它的客户端，但它的信息发送线程和信息接收线程都只有一个，而信息的定位由标签来完成。

不过在借助了UI的实现方式里，只需要显式的实现信息接收线程就可以了。信息的发送由按钮监听事件自带的多线程来完成 (即点击按钮，信息传递系统便开始工作，而不需要额外的线程来等待系统输入)。

文件传输

这个和信息发送没有太大的不同。主要还是在传递信息时，进行标签处理。

但在这个的具体实现上面，其实有很多的细节要注意。

首先，使用socket信息交流时，信息类型可以大致分为3种：系统信号、文本信息、文件信息。所有种类的信息的传输都应该由一个结构来完成，否则就会出现很多的问题，解决起来就相对较为麻烦.... 特别是文件传输和文本消息发送，这两者本质上是使用的同一个信息交流接口，如果不统一处理，就会出现频繁切换接口的情况，这种结构不稳定，也不符合面向对象编程的基本思想，不推荐采用。所以，最好的办法是将所有的信息接收功能包装成一个模块，并且模块与客户端一一对应。

这样的话，传输文件时，只需要根据标签里的信息进行判定，然后再执行不同的函数就可以了。

这个问题，一开始我并没有意识到，后来发现的时候，已经不好更改主体结构了。所以，程序的框架结构真的很重要！

其次，文件从一个客户端传输到另一个客户端，本质是先将数据发送到服务器端，服务器端接收数据后存放在内存中，然后直接进行转发到对应目标即可。但这样其实是存在问题的，用这种方式传输小文件是可以的，但传输比较的的文件的话，就不适合了 。不过，大文件的传输涉及到的东西已经比较偏离socket网络编程的重心，所以这个不重要了。 

 

补充

聊天室系统的广域网实现

我试过什么端口转发，局域网映射广域网，都没成功。猜测主要原因还是没有公网IP。最后的解决方案是，把服务器程序挂在云服务器上运行，就OK了。

文件传输的不稳定问题

对于文件传输时遇到的不稳定问题，一直没能找到原因和节解决方案。猜测可能是由于目前的实现方案里，文件传输和文本传输x相对比较混杂，结构不是那么的调理，所以不稳定...?。这样的话，要解决这个问题，就要重构代码...  （这也在此体现了代码结构的重要性）。