基于对等模式建立讨论组及该讨论组即时通信的方法

摘要

本发明涉及一种基于对等模式建立讨论组的方法，包括：A.创建者客户端获取讨论组的基本信息，该基本信息包括：讨论组唯一标识、讨论组成员列表以及创建者的用户标识；B.将讨论组的基本信息组合到数据包中，该数据包的消息类型为建立讨论组的消息类型；C.遍历讨论组成员列表，逐一获取讨论组成员相应的地址信息，并将其作为参数生成套接字接口，发送所述建立讨论组的数据包；D.当讨论组成员的客户端成功接收到客户端讨论组的数据包时，在讨论组成员的客户端生成并显示讨论组条目，并向创建者客户端反馈发送成功；E.讨论组成员的客户端建立讨论组成功。以解决现有技术中服务器建立、管理以及删除讨论组而造成服务器处理能力加大的问题。

说明书

技术领域

本发明涉及电通信技术领域，特别是涉及一种基于对等模式建立讨论组及该讨论组的即时通信的方法。

背景技术

网络即时通信服务(IM，Instant Messenger)是一种基于互联网的通信服务，即时通信工具在互联网上得到了广泛的应用和认可，将即时通信工具应用到企业内部，形成建立在网络即时通信服务技术上的服务模式，是网络即时通信服务的发展趋势。

随着网网络的发展，网络即时通信工具已经被大多数的网民所接受，进行日常的交流与沟通，但是用户之间的聊天模式发展至今仍然没有太大的变化，用户不再是只需要个人对个人的交流方式，同时也需要能够与多个人对某个话题进行讨论，因此出现了群或者讨论组这类多人对话的形式，群与讨论组这类多人对话形式的出现大大方便了多个用户之间的交流与沟通，使得用户的交流范围也变得更加的广泛，同时可以在日常生活中通过IM软件从多个用户那里获取到有价值的信息，提高自己解决问题的能力。

但是，目前讨论组的建立都是以服务器为控制中心，即在服务器中建立讨论组的数据表结构，在该服务器的数据库中保存每个讨论组的唯一标识ID、讨论组的名称、讨论组成员列表等信息。所述在服务器中建立讨论组的方法的流程图详见图1，其方法包括：

步骤L1：用户在讨论组建立入口处希望建立讨论组以及讨论组成员列表；创建者选择希望加入讨论组的成员添加到讨论组成员列表中；

步骤L2：将创建者的用户标识与成员列表组合到协议数据包中，根据约定的端口生成套接字接口把所述协议数据包发送到服务器中；

步骤L3：所述服务器对接收到的数据包进行解密或解析操作，并根据解析到的协议段、创建者用户标识以及成员数据列表写入数据库，并设置所述讨论组的唯一标识ID；

步骤L4：写入数据库成功后，向创建者发送带有讨论组唯一标识ID的创建成功协议命令；所述创建者将接收到的讨论组唯一标识ID写入本地存储模块中。

当讨论组建立成功后，由服务器负责维护与管理讨论组中的所有基本信息(主要包括创建者用户标识、讨论组的唯一标识ID、讨论组名称、讨论组已加入成员列表)，而且对于讨论组成员之间的消息沟通，实现过程为：首先某个讨论组成员发送某个消息给服务器，所述消息的内容包括：消息发送者的用户标识、消息内容、消息的字体格式、讨论组的唯一标识ID等；当服务器接收所述讨论组的消息时，通过讨论组的唯一标识ID到服务器的数据库中查找该讨论组的成员列表的用户标识，即用户号码；然后遍历所述用户标识的列表，根据该列表将所述消息转发到相应的讨论组成员中；当讨论组成员接收到消息后，对此进行解析并显示。在这个过程中，服务器实际上完成了查找、遍历、转发等多项处理工作，极大的加大了服务器的压力。

因此，随着用户数量以及建立讨论组数量的逐渐增大，将会造成对讨论组服务器的巨大存储压力，在即时通信过程中讨论组服务器必须保证有足够的存储空间来保存与管理每个讨论组的数据表结构；而且在讨论组成员之间的消息传递时，也是由讨论组服务器根据成员列表进行相应的转发，会增大讨论组服务器的并发处理压力，从而增大讨论组服务器开发时的运营成本。

发明内容

本发明解决的技术问题是提供一种基于对等模式建立讨论组及该讨论组即时通信的方法。该方案以解决目前技术中服务器建立、管理以及删除讨论组时而造成服务器储存和并发处理能力的加大问题，同时也减少讨论组服务器开发时的运营成本。

为解决上述问题，本发明提供一种基于对等模式建立讨论组的方法，包括步骤：

A、创建者客户端获取讨论组的基本信息，所述基本信息包括：讨论组唯一标识、讨论组成员列表以及创建者的用户标识；

B、将所述讨论组的基本信息组合到数据包中，所述数据包的消息类型为建立讨论组的消息类型；

C、遍历讨论组成员列表，逐一获取讨论组成员相应的地址信息，并将其作为参数生成套接字接口，发送所述建立讨论组的数据包；

D、当讨论组成员的客户端成功接收到客户端讨论组的数据包时，在讨论组成员的客户端生成并显示讨论组条目，并向创建者客户端反馈发送成功；

E、讨论组成员的客户端建立讨论组成功。

所述步骤A中创建者客户端获取包括::

21)创建者客户端接收用户创建讨论组请求，获取讨论组成员信息；

22)将所述讨论组成员信息加入到讨论组成员列表中；

23)利用应用程序接口的全球唯一标识符生成函数生成所述讨论组唯一标识。

所述步骤A中创建者客户端获取还包括：设置所述讨论组的名称。

所述步骤B中还包括：将所述数据包按照约定的加密方式进行加密。

所述步骤C中遍历包括：遍历所述讨论组成员列表，得到每个讨论成员的用户标识；

所述步骤C中获取包括：根据所述用户标识查询本地存储文件；

所述步骤C中生成包括：利用底层相关套接字接口的应用接口函数，将所述地址信息作为参数。

所述步骤C还包括：利用事件回调机制等待讨论组成员消息的回复。

在步骤C和步骤D之间还包括：通过事件回调机制判断所述发送建立讨论组的数据包是否超时，若超时，通过设置定时器在规定时间内对所述数据包进行重新发送，若在规定的时间内没有发送成功，则放弃。

所述步骤D的具体实现过程为：

D1、当用户在约定的套接字接口异步接收到数据包时，判断所述数据包是否是有效的数据包，若否，则继续异步等待数据包；若是，按照约定的协议格式解析出所述数据包中的消息类型；

D2、若所述消息类型是讨论组建立的消息类型，则通过解析数据包获得建立讨论组的唯一标识以及讨论组成员列表；

D3、根据所述讨论组的唯一标识查询本地存储文件中是否存在该讨论组，若存在，则更新本地存储文件中的原讨论组成员列表；否则，在本地存储文件中建立所述讨论组的唯一标识、讨论组成员列表的数据结构；

D4、生成讨论组条目，并通知创建者客户端讨论组发送成功。

所述步骤D1中通过解密或解析的方式来判断所述数据包是否为有效的数据包，其具体过程为：

客户端对所述数据包进行解密，若能成功解密，则所述数据包为有效数据包；或者

客户端对要解密的数据包按照约定的协议格式进行解析，若能成功解析，则所述数据包为有效数据包。

所述步骤D2中通过解析所述数据包还获得讨论组的名称。

所述方法还包括：利用本地存储文件保存所述建立成功讨论组的数据结构，且所述讨论组的数据结构包括讨论组唯一标识、讨论组名称、创建者的用户标识以及加入讨论组成员的讨论组成员列表。

另外，本发明还提供一种基于对等模式的讨论组的即时通信方法，所述方法包括步骤：

A、会话发起方获取讨论组的唯一标识；

B、根据所述讨论组的唯一标识查询讨论组成员列表；

C、遍历所述讨论组成员列表，获取讨论组成员的用户标识，以及对应该用户标识的地址信息，并生成套接字接口；

D、设置发送数据包的消息类型为讨论组消息，并将其与所述讨论组的唯一标识、成员用户标识、希望发送的消息内容以及发送者的用户标识按照约定的格式进行组包，通过套接字接口发送；

E、对应的成员客户端在约定的套接字接口异步等待接收数据包，并对接收到的数据包按照约定的方式进行解析；

F、判断所述发送者的用户标识是否存在于所述讨论组唯一标识所对应的讨论组中，若是，将该消息显示在讨论组的客户端。

与现有技术相比，本发明具有以下有益效果：本发明将现有技术中由服务器控制讨论组的方式转变为一种由客户端控制讨论组的处理方式，即基于对等模式的讨论组。本发明提出的基于对等模式的讨论组的技术实现方案，在没有影响用户使用讨论组习惯的情况下，大大减少了服务器的存储空间、并发处理以及负载等方面的压力，利用这种对等模式的讨论组，不再需要服务器参与讨论组的建立，管理，消息转发，删除等操作处理，全部由客户端完成整个过程，这样可以节省开发的成本开销，适应用户对讨论组逐渐增加的需求。

附图说明

图1是现有技术在服务器中建立讨论组的方法的流程图；

图2是本发明基于对等模式创建者客户端建立讨论组的方法的流程图；

图3是基于对等模式讨论组成员的客户端处理讨论组的方法的流程图；

图4是本发明基于对等模式的讨论组的即时通信的方法的流程图。

具体实施方式

本发明的核心是当某个讨论组成员(创建者)希望发起会话时，创建者建立讨论组，以及希望加入讨论组成员列表的数据结构，通过建立讨论组的操作界面，可以设置新建讨论组的名称，以及将论组成员加入到讨论组成员列表中，并生成讨论组唯一标识；其次，将所述讨论组唯一标识、讨论组名称、讨论组的成员列表以及创建者的用户标识按照约定的格式进行组包操作，并将所述数据包设置为建立讨论组的数据包；再次，通过遍历所述讨论组成员列表中每一个讨论组成员的用户标识，根据用户标识查询本地存储文件得到所述讨论组成员的地址信息(即动态IP地址和端口)，并利用所述IP地址和端口为参数生成发送消息的套接字接口，来发送所述建立讨论组的数据包；最后，如果建立讨论组数据包发送成功，则查找该讨论组中下一个讨论组成员，执行上述相同的步骤，直至将所有讨论组成员都查找完，面板管理单元则将生成相应的讨论组条目，以便于以后对讨论组的管理和维护，同时通过本地存储文件存储该讨论组的基本信息，以及向所述创建者反馈发送成功的通知。

而当客户端接收到所述建立讨论组的数据包时，先判断所述数据包是否时有效的数据包，若是，则通过约定的协议格式解析出所述数据数据包的消息类型，即若所述数据包的消息类型为建立数据包的消息类型，并解析出所述讨论组唯一标识、讨论组名称及讨论组成员列表，并根据讨论组唯一标识来查询本地存储文件中是否存在该讨论组，若存在，则更新所述讨论组，否则，建立所述讨论组唯一标识、讨论组名称和讨论组成员列表等讨论组的基本信息，并保存。

本发明也就是将现有技术中由服务器来控制建立的讨论组的处理方式转变为一种由客户端自己控制建立的讨论组的处理方式。目前讨论组的技术实现方案是以服务器为控制中心，由服务器负责讨论组的建立、删除、管理以及该组内成员之间的即时通信。但是，随着用户数量以及建立的讨论组的数量的逐渐增大，无论从存储空间、并发处理以及负载方面都造成了对服务器的巨大压力，因此，本发明提出了一种基于对等模式的创建讨论组的技术实现方案，该方案中由各个客户端对等的负责讨论组的建立、控制、管理以及删除讨论组等操作，并且，上述操作都不通过服务器，也即是说这种方案把原来对服务器的各个压力都分散到了客户端，  可以极大满足用户对讨论组的需求增多的要求，而本发明对用户的表现形式与原来的界面操作界面一样，只是内部的处理过程进行相应的优化，从而对于用户来说将不会造成任何的影响，同时又降低了开发成本，极大的适应了用户对讨论组增多的需求。

下面结合附图，对本发明做进一步的说明。

本发明所述基于对等模式的讨论组的技术实现方案，主要包括两部分内容，一部分是基于对等模式建立讨论组的过程，且所述建立讨论组的过程又包括创建者客户端建立讨论组的过程以及讨论组成员客户端的建立讨论组的过程。另一部分是基于对等模式的讨论组的即时通信过程。下面分别对其进行详细的说明。

请参阅图2，为本发明所述基于对等模式创建者建立讨论组的方法的流程图。所述方法包括步骤：

步骤S10：创建者客户端获取讨论组的基本信息，所述基本信息包括：讨论组唯一标识、讨论组成员列表以及创建者的用户标识；

步骤S11：将所述讨论组的基本信息组合到数据包中，所述数据包的消息类型为建立讨论组的消息类型；

步骤S12：遍历讨论组成员列表，逐一获取讨论组成员相应的地址信息，并将其作为参数生成套接字接口，发送所述建立讨论组的数据包；

步骤S13：当讨论组成员的客户端成功接收到客户端讨论组的数据包时，在讨论组成员的客户端生成并显示讨论组条目，并向创建者客户端反馈发送成功；

步骤S14：讨论组成员的客户端建立讨论组成功。

当某个用户希望建立讨论组，能够进行与多人会话时，先通过IM软件的讨论组建立入口调出操作界面，用户通过操作建立讨论组的操作界面，同时建立用户希望加入讨论组的成员列表初始化的数据结构；用户通过操作界面可以将新成员不断添加到讨论组成员列表中，同时也可以设置新建立讨论组的名称。所述设置讨论组的名称只是为了让其他成员更好的来区分本讨论组，如果只为讨论组设置讨论组的唯一标识ID，在某些时候用户并不能很好的区分，因此，设置讨论组的名称并不是必须的，但是，如果设置讨论组的名称，应该优先使用。

用户通过界面操作将希望加入的讨论组成员填充所述建立的讨论组成员列表的数据结构中。并利用Windows底层应用程序接口(API，Application Program Interface)的全球唯一标识符(GUID，Global UniqueIdentifier)生成函数生成讨论组的唯一标识ID。本发明所述的讨论组的唯一标识与现有技术中的讨论组的唯一标识的生成过程不同：所述现有技术的生成过程为：在服务器中由于采用数据库系统，因此讨论组的ID是数据库中数据表的主键，是数据库中自动根据已经有的数据项自动生成的。比如，讨论组数据表中的讨论组唯一标识已经有100行了，现在用户又要申请再创建一个讨论组唯一标识时，则所述数据库系统会在成功写入数据表之后返回讨论组唯一标识ID为101。而本发明所述讨论组唯一标识的生成过程却没有数据库的支持，因此采用Windows的底层应用程序接口API函数CreateGUID生成。所述生成讨论组的唯一标识的目的是方便用户在本地存储中管理讨论组，同时也可以避免出讨论组ID不唯一的情况。

创建者的客户端将讨论组的基本信息，即讨论组的唯一标识ID、讨论组名称、讨论组的成员列表和创建者的用户标识等这些字段按约定的格式组合到协议数据包中，其中，所述约定的协议格式是事先由接收方与发送方共同约定的，也就是说，所述协议格式也就是数据包的组包格式，一般数据包包括包头、包体和包尾。所述包头中包括：一些协议命令号、子命令号等等；所述包体包括：所述数据包的内容，比如，如果本发明所述的数据包中包括了讨论组的唯一标识ID、消息类型、讨论组成员列表等等；所述包尾包括：一些数据包结束符等等。并设置该数据包的消息类型为建立讨论组的消息类型，并利用约定的加密算法对数据包进行加密。其实，本发明所述的加密算法只是对所发送的数据进行保密，主要是考虑所发送的数据包的安全性，在该过程中不对数据包进行加密直接进行发送也是可以的。因此所述的加密算法是普通的加密算法，这对于本领域的普通技术人员来说是公知技术，在这里不再赘述。

遍历填充的讨论组成员列表的数据结构，得到每个讨论组成员的Uin号码，即用户标识，根据所述用户标识查询本地存储文件，获得本地存储文件中对应该讨论组成员的地址信息，所述地址信息包括：动态IP地址以及PORT端口。其中，所述遍历的方式有两种：一种是采用逐一遍历的方式，即先查找一个讨论组成员的用户标识，获得其对应的地址信息后，再查找下一个讨论组成员，获得其对应的地址信息后，继续查找下一个讨论组成员，直至所有的讨论组成员都查找完；另一种是先查找所有讨论组成员的用户标识，再分别根据用户标识得到该讨论组成员的地址信息。但二者的实现原理基本相同，其实现原理对于本领的技术人来来说，都是公知及时，因此在这里不再赘述。而所述本地存储文件包括对应该用户的基本资料信息，比如讨论组成员的呢称、联系方式、年龄等等；动态资料信息，比如状态、IP地址以及PORT端口等等。在该本地存储文件中是以用户标志为关键字进行组织的，因此通过用户标识即可查找到。并将所获得的IP地址与PORT作为参数通过Windows底层相关的套接字API函数CreateSocket生成套接字接口，并发送所述建立讨论组的经过加密的协议数据包，同时利用事件回调机制等待成员的返回消息。所谓事件回调机制指的是发送方对某个接收方发送了某个事件后，发送方不需要同步等待接收方的返回，而是继续进行其他的处理工作，接收方会主动调用发送方的回调接口，向发送方返回消息。利用事件回调机制可以实现事件的异步处理，从而提高处理效率。其中，所述讨论组成员返回消息的内容就是一个已经成功接收到创建者的数据包的通知消息，该消息是在讨论组成员成功解析完数据包之后即可反馈。

此外，通过事件回调机制还可以判断所述发送的建立讨论组的协议数据包是否超时，如果超时，则会启动定时器，在设定的时间(比如设置为4分钟)内对数据包进行重新发送，如过在设定的时间内还没有发送成功，则放弃发送。如果建立讨论组的协议数据包发送成功或在设定的时间内发送成功，则提取出下一个讨论组成员，重复遍历已加入讨论组成员的讨论组成员列表的数据结构，直到该讨论组列表遍历完毕。

当讨论组成员的客户端成功接收到讨论组的数据包时，通过面板管理模块生成对应该讨论组的条目Item，并显示在主机显示器上，同时利用对话框提示该创建者用户，讨论组已经建立成功，并利用本地存储模块保存该讨论组的数据结构到本地中，以便于后续管理与维护。所述本地存储模块可以存储很多种数据结构，比如：讨论组的数据结构、群组的数据结构、好友的数据结构、陌生人的数据结构和消息记录的数据结构等等，该本地存储模块主要负责与本地存储文件的保存，提取以及修改等操作。但是本发明所述数据结构主要就是讨论组的数据结构，包括：讨论组的唯一标识ID、讨论组名称、创建者用户标识、讨论组成员列表等。

还请参考图3，为本发明所述基于对等模式讨论组成员的客户端处理讨论组的方法的流程图，所述方法包括：

步骤N10：当用户在约定的套接字接口异步接收到数据包时，判断所述数据包是否是有效的数据包，若否，则继续异步等待数据包(步骤N11)，结束；若是，按照约定的协议格式解析出所述数据包中的消息类型步骤(N12)；

步骤N13：判断所述消息类型是否是讨论组建立的消息类型，若是，则通过解析数据包获得建立讨论组的唯一标识以及讨论组成员列表(步骤N14)；否则，则按所述消息的类型进行相应的处理，结束(N15)；

步骤N16：根据所述讨论组的唯一标识查询本地存储文件中是否存在该讨论组，若存在，则更新本地存储文件中的原讨论组成员列表(N17)；否则，在本地存储文件中建立所述讨论组的唯一标识、讨论组成员列表的数据结构(N18)；

步骤N19：生成讨论组条目，并通知创建者讨论组发送成功。

用户在约定的接收消息的套接字接口上异步等待数据包的到来。当客户端接收到数据包时，对接收到的数据包按照约定的解密算法进行解密处理以及对数据包的解析操作。然后判断所述数据包是否是有效的数据包，其判断过程为：首先，如果能对所述数据包进行解密，则可以认为所述数据包有效；其次，是对解密的数据包按照约定的协议格式进行解析，如果所述数据包的包头、包体与包尾能够成功解析，则所述所述数据包为有效的数据包，否则，则说明所述数据包是伪造的数据包。对于无效的数据包，直接丢弃，并继续在接收消息的套接字接口中进行异步等待。

其中，对于有效的数据包，则按照约定协议格式解析出该数据包中的消息类型的字段，并判断该消息类型的字段是否是建立讨论组消息类型，如果不是，则按照原来的消息类型的处理函数进行后续的处理操作。比如所述消息的类型为系统消息、群消息、好友消息、通告消息等等；如果是讨论组的建立消息类型，则通过数据包解析出创建讨论组的唯一标识ID、讨论组名称、讨论组成员列表以及讨论组的创建者用户标识。并根据所述数据包解析出来的讨论组唯一标识ID查询本地文件存储模块，判断该讨论组是否已经存在，如果该讨论组存在，则通过本地文件存储模块提取出原来的讨论组所有的相关信息，所述相关信息包括讨论组的名称，讨论组的成员列表以及讨论组的创建者用户标识，利用数据包解析出来的各个字段进行替换更新处理；否则，如果该讨论组不存在，则建立讨论组，其中所述讨论组的内容包括：讨论组唯一标识ID、讨论组名称以及讨论组成员列表、讨论组创建者用户标识等字段的数据结构，并利用解析出的相应的数据字段进行数据结构的填充处理。

最后，利用本地文本存储模块新建的讨论组的数据结构进行保存，以便用户后续对该讨论组的维护与管理等操作，同时利用面板管理模块根据当前的讨论组信息进行更新处理，对于原来已经存在的讨论组，根据需要更新面板与讨论组成员列表；如果原来不存在，则重新生成讨论组对应的面板条目Item，并提示用户新讨论组建立成功。

另外，本发明所述创建者还可以增加或删除讨论组成员，且所述讨论组创建者增加与删除讨论组成员的过程为：创建者把该讨论组成员的用户标识以及讨论组的唯一标识ID组合到增加或者删除讨论组成员的讨论组消息类型的数据包中，根据讨论组成员列表进行消息发送，讨论组其他成员接收到该消息数据包，解析出需要增加或者删除的讨论组成员的用户标识，然后利用本地存储模块更新本地文件存储以及面板。

当讨论组讨论完后，创建者组合讨论组唯一标识ID到数据包中，根据讨论组成员列表，发送带有解散讨论组的讨论组消息类型的数据包，当其他成员收到该数据包时，解析出该数据包中的消息类型，根据讨论组唯一标识ID删除本地文件存储中的数据结构以及通过面板模块删除该讨论组条目ITEM，从而实现讨论组讨论完毕后的解散过程、

当讨论组的创建者以及讨论组的所有成员都在主面板上具有了讨论组的表现形式以及讨论组的本地文件存储后。就可以利用该建立的讨论组进行多人之间的即时通信，其中所述基于对等模式的讨论组的即时通信方法，即的流程图详见图4，所述方法包括：

步骤H10：会话发起方获取讨论组的唯一标识；

步骤H11：根据所述讨论组的唯一标识查询讨论组成员列表；

步骤H12：遍历所述讨论组成员列表，获取讨论组成员的用户标识，以及对应该用户标识的地址信息，并生成套接字接口；

步骤H13：设置发送数据包的消息类型为讨论组消息，并将其与所述讨论组的唯一标识、成员用户标识、希望发送的消息内容以及发送者的用户标识按照约定的格式进行组包，通过套接字接口发送；

步骤H14：对应的成员客户端在约定的套接字接口异步等待接收数据包，并对接收到的数据包按照约定的方式进行解析；

步骤H15：判断所述发送者的用户标识是否存在于所述讨论组唯一标识所对应的讨论组中，若是，将该消息显示在讨论组的客户端(H16)。

当某个讨论组成员希望发起会话，该客户端获取用户希望展开会话的讨论组的唯一标识ID，通过该唯一标识ID利用本地文件存储模块查询获取对应该讨论组所有成员列表，并把所有成员(包括讨论发起会话的成员)加入到建立的讨论组成员列表中。客户端软件遍历加入讨论组成员的讨论组成员列表，提取所述讨论组成员的用户标识UIN，通过该用户标识UIN，查询本地存储模块中对应该用户标识UIN的动态用户IP地址以及PORT端口，并将所述用户IP地址和PORT端口为参数生成UDP发送套接字接口。

创建者设置消息类型字段为建立讨论组的消息类型，把讨论组唯一ID，讨论组成员的用户标识UIN，希望发送的消息内容，以及创建者或发送者的用户标识UIN，消息类型等按照约定的协议格式组包到数据包中，并按照约定的加密算法进行加密处理，并将加密后的数据包通过套接字接口发送出去，对应的讨论组成员客户端在约定的套接字接口异步等待接收数据包，并对接收到的数据包按照约定的算法进行解密，且按照约定的协议格式进行数据包的解析；来判断所述数据包是否是有效的数据包，如果不是，则直接丢弃该数据包；如果是，则按照协议格式提取出该数据包中的消息类型字段，并判断，如果所述消息类型是非讨论组消息，则按照原来的消息类型进行处理，而如果是建立讨论组消息类型，则利用解析出来的创建者或发送者的用户标识UIN以及讨论组唯一标识ID，查询本地文件储存模块，判断所述创建者或发送者的用户标识UIN是否是讨论组成员，如果不是讨论组成员，则直接丢弃该讨论组消息；如果创建者或发送者存在于该用户的讨论组唯一标识ID对应的讨论组中，则调用消息显示模块，并利用讨论组模块调出讨论组显示模块，把该消息显示在讨论组的IM聊天窗口中。然后创建者或发送者重新遍历论组成员列表，并重复执行上述实现过程，直到所有的讨论组成员遍历完毕。

由此可见，采用本发明所述方法，在讨论组成员中进行多人会话时，利用遍历讨论组成员列表，通过发送带有建立讨论组消息类型的数据包，并对该讨论组中的每个成员进行点对点的数据发送，不再通过服务器进行操作处理，即建立、管理、消息转发和删除等操作处理，从而大大节省了开发成本，极大的适应了用户对讨论组逐渐增加的需求。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。