聊天服务器端实现细节注意事项

关于如何使用xsocket就不再讲了,主要是讲聊天过程的一些需要注意的东西。

在客户端发送消息过来时服务器端会调用 onData(INonBlockingConnection connection)方法,connection就是保持了服务器端和客户端之间的联系,包括发送和接收的数据都会通过它来进行传送,所以可以把它看为 客户端和服务端的一条通道。

注意1:在客户端发送数据过来时服务端需要解析这些数据,可以使用connection的 readStringByDelimiter或readStringByLength来读取发送的数据,使用readStringByLength会更简 单一点,但是如果当客户端发送数据很快,这时候客户端可能会把两条消息当作一条发送过来(网络原因)这时候服务端这边接受到数据之后就解析不了了,所以推 荐使用readStringByDelimiter方法,如果使用readStringByDelimiter方法那么客户端需要在每条消息后加上一个分 隔符(分隔符尽量避开平常的消息内容,在我们这里使用的是,客户端那边需要对发送内容进行过滤,以免用户也发送 了这样的东西),服务端也需要以将内容分隔开处理。

注意2:因为客户端请求的 类型有多种,比如请求连接,发送数据,接收数据,断开连接,连接超时,空闲超时,开始聊天,结束聊天等,所以就必须对这些类型进行分开处理,否则到最后你 会发现代码如一滩烂泥,我们可以使用标签标识每种类型,服务端和客户端根据标识来处理具体的业务逻辑。

注意3:因为socket有空闲超时,什么 是空闲超时?空闲超时就是客户端和服务端在某个时间段没有进行过交流,这个时候socket就会自认为这个连接已经没有存在的意义了,就会自动断开这个连 接,这时的服务端就好比是现实中情侣中的女方,会因为长时间男方没给女方发信息打电话就提出我要跟你分手这样的没有理由的条件。但是这显然不是我们想要 的,就像一对情侣吵架长时间没说话但不代表他们分手了,所以这个时候你可以通过设置空闲超时的时间你也可以每隔一段时间由客户端向服务端发送心跳检测包, 关于心跳(heart beat)相信很多人都听说过,在linux中似乎出现的很多,它其实是提醒服务端:你别断开啊,我还活着的呢。待服务端这边接受到心跳数据不用做任何处 理,因为这时服务端已经接受到了客户端发送来的数据了,女方也收到了男方发给她的消息了,服务端再也不会无缘无故的断开了。

注意4:每次客户端建 立连接后我们必须在服务端这边保存各个客户端的connection,因为信息是通过服务端转发给好友的,而数据的发送是通过connection的 write方法发送的,所以就必须有好友的connection在你的服务端,否则你如何获取到好友和服务端之间的通道呢。

注意5:在好友不在线 的时候我们需要将消息存到离线消息容器中,待好友一上线就向该好友发送离线消息并将这些离线消息从容器中删除,那么如果判断好友在不在线呢?上面说过每个 客户端建立连接都会将connection存到服务端,所以可以查找该好友的connection是否存在于服务端即可判断好友是否在线。如果在线我们还 需要判断这个还有是否在和别人聊天,想象一下微信,聊天界面永远之后一个即当前我和好友聊天的界面,你退出聊天你就和该好友的聊天结束了,所以当该好友正 在和别人聊天服务端需要将消息发送到好友客户端的后台(即通知栏,这可以通过客户端的推送实现),这样该好友就可以看到发给他的消息了。

注意6:两人的聊天信息最后是必须存到数据库中的,但是你不能没发一条消息过来就往数据库里插一条,这样数据库吃不消的,可以将每次发送过来的消息作为缓存存到服务端这边,在客户端断开连接或双方出现异常的时候一起将数据插入数据库中,这样可以大大减轻数据库的压力。

注 意7:在用户聊天速度超快的情况下,两条消息有可能会一起发给服务端(网络问题),如果不进行相应处理两条消息返回给好友的时候就会乱串,明明晚发的那条 就有可能显示在前面了,这时候发送数据到服务端的时候可以把当前的时间值也一起发送过来,服务端可以根据这个时间值来进行判断消息的先后。

注意8:socket能接受的客户端连接数量是有限的,所以在某个服务端连接数量超过某个值(该值可自己设定)的时候将客户端连接到另外一个服务端,说的好听一点就是集群了,这是我接下来的工作。

关于服务端的一些主要内容就讲到这里,其中还有很多的东西可以讲,但也都是功能性的东西了,会编程的花点时间都能搞定的。



Previous     Next
uohzoaix /
Published under (CC) BY-NC-SA in categories NIO  socket  tagged with