五．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
