五．Case MULTI_SEND_MSG: 用户给多个好友发的离线消息
对每个接受方用户ID，执行以下两步操作
判断此用户ID和FriendId是否为合法用户，否就不处理
判断此接受方的用户是否在线（或隐身），是则发送此消息给此用户，否则存入offmsg表中

六．Case TEST_BROADCAST_PWD: 检查发广播的密码
    1.  判断此用户是否为合法用户，否则就不处理
 2.  判断是否是正确的密码，发回一个CMsg3类的一个反馈消息

七．Case SEND_BROADCAST: 发送的广播消息
判断此用户是否为合法用户，否则就不处理
判断密码是否正确，不正确则不进行处理
把这条广播消息插入到broadcast表中
对所有用户，执行以下操作：
如果在线，则发广播消息给用户，否则就存在offbroadcast表中
八．Case FRIEND_DETAIL: 用户请求查看某人详细信息
判断此用户ID和FriendId是否为合法用户，否就不处理
从Users表中查出此FriendId的用户的详细信息
把此详细信息发送给请求用户

九．case ADD_AS_FRIEND: 用户要求把某人加为好友的请求
判断此用户ID和FriendId是否为合法用户，否就不处理
如果FriendId拒绝任何人加它或需要身份验证，则发回RE_ADD_AS_FRIEND响应，结束。
在Friends表中查，看此FriendId用户是否已经是ID用户的好友，是则返回相应错误信息，结束。
把这个好友信息插入Friends表中
发送成功加入消息
看被加入的人是否在线，是，则发送一个通知消息，否则把这条消息插入offmsg表中。
 
十．case  APPLY_SHOW_ONLINE: 查看在线的人的请求
判断此用户是否为合法用户，否则就不处理
按信息中的Value值，进行定位
如果超出范围，则不处理（Value错误）
把在指定位置开始的，在线的人不超过PersonNumEveryTime个人的信息，发送给用户

十一。case  FIND_FRIEND_BY_ID: 用ID号进行查找用户
判断此用户ID和FriendId是否为合法用户，否就不处理
在数据库表Users中查找此用户
如果找不到此用户则返回ID_NOT_FOUND_BY_ID消息，结束
如果找到了，则返回这个用户的详细信息（FOUND_FRIEND_ BY_ID）

十二、case  FIND_FRIEND_BY_NAME: 用姓名查找朋友
判断此用户是否为合法用户，否则就不处理
在m_pUsers数组中查找与此姓名相同的用户
如果没有找到，则返回一个NAME_NOT_FOUND_BY_NAME消息，结束
如果找到了，则把这此人的相关信息存入CshowOnlinePeople的一个实例中，并发送给请求的用户。
十三、case  DELETE_A_FRIEND:  删除一个好友
判断此用户ID和FriendId是否为合法用户，否就不处理
在Friends表中删除Friends.myid=msg.myid and Friends.friendid= msg.friendid的那项记录

十四、case DELETE_SELF_IN_FRIEND: 选择在某人的好友中删除自己
判断此用户ID和FriendId是否为合法用户，否就不处理
在Friends表中删除Friends.myid=msg.friendid and Friends.friendid=msg.myid 的那项记录

十五、case CHANGE_PERSONAL_INFO: 修改个人信息
判断此用户是否为合法用户，否则就不处理
按Mask的值来构造修改的SqL语句
执行修改操作

十六、case CHANGE_PASSWORD: 修改个人的密码
判断此用户是否为合法用户，否则就不处理
从Users中查出此用户的password
检验旧密码是否正确，否，则不处理，结束
正确则修改此用户的密码

十七、.Case  APPLY_ID_LOGIN: 申请一个新帐号
把当前用户的详细信息插入Users表中
更新相应数据结构中的数据（m_nMaxUserId,m_nNumberOnline，m_pUsers）
得到用户的ID号，发送给用户APPLY_ID_OK消息

十八、case HAVE_ID_LOGIN: 使用已有号码进行登陆
判断此用户是否为合法用户，否则就发送帐号不存在的消息，结束
判断用户发出的密码是否正确，否则就发送密码错误的消息。结束
密码正确，发送登陆成功消息

小结：

 以上这些处理过程，主要是一些数据库的访问和协调各客户端进行通讯，算法上面没有什么很难的地方，只是处理时，要仔细，因为很容易遗漏一些步骤，导致得不到正确的结果。
 
 有一点，我在上述的处理过程都没有提到，就是在响应用户请求过程中，如果发送数据失败，如何去处理。因为每个都需要去考虑，说起比较繁琐。我的处理原则是： 如果是发送离线消息之类的存于数据库中的数据，发送成功，才会删除相应项。如果发送不成功，将放弃用户请求，跳出Switch语句，结束线程。
 
 处理查看在线的人的时候，这个如何实现，倒难了我几天时间，假如在服务器端，如果不采用pUsers保存一部分的用户信息，那这一操作，将会较难实现，处理上也要复杂多了，访问数据库也要访问好多次。所以，就是因为要实现这个功能，为了能较快的响应用户的请求，所以我采用了这种数据结构，在启动服务器时，把所有用户的一部分信息读出放在内存里，当然，更新数据库数据时，这些在内存里的数据，也同时被更新了。从内存中取数据，可比访问数据快了好多好多。
 
 在处理查看在线用户的功能时，我看了”武汉硕思软件公司”的硕思即时通的服务器端的数据库，我看到，他把用户Online信息存放在用户详细信息的表里，我想，他这样做，也是为了使查看在线的人的功能容易实现吧。但我个人认为，Online是处理运行时刻的状态，不应该放在用户信息的表里，那样不符合数据库设计的原则。
 
 我在实现查看在线用户的”上页””下页”功能时，是让用户传来一个Value值，根据他传来的value值，我来确定在线的人的分布，比如说，用户刚打开查看在线时，Value值为0，这样，我就从服务器中取出所有在线的，把从开始的共K位用户的信息发回来，用户按了一个下页，这时Value为1,我就从服务器中取出所有在线的，取其第K+1到2K的这些在线的人，发回给用户。当然，前提是还存在这个范围的在线用户。
&nbs

首页 上一页 12 13 14 15 16 17 下一页 尾页 15/17/17

相关论文