使用C# socket tcplistener类编写这个聊天程序的时候,
如果希望服务端和客户端之间能够互发消息,就像QQ那样,
当客户端编辑消息内容然后点击发送,服务端会收到消息,然后服务端再编辑内容,点击发送,客户端就收到消息
这种情况下,服务端和客户端是否需要同时都具有两者的角色,服务端也是客户端,客户端也是服务端?
------解决思路----------------------
可以这么理解。客户端 各自开一个端口，不停的“监听” 是否有数据发送过来。
------解决思路----------------------
tcp本来就可以长连接双向通讯的。例如我在 http://bbs.csdn.net/topics/390987992 贴的一段例子，用来实现 c-s 两端的长连接的、随时的双向字符串通讯。
如果你需要处理业务上的“一问一答”的形式，就可以在这个随时双向通讯的基础上定义你自己的信令，例如一旦发送命令1、2、3、4、5，而另一端可能是按照1、5、3、2、4的顺序返回结果，那么你的信令应该能够对命令和返回进行“编号”，你的消息处理程序应该能够在收到第n号返回时直接调用之前在发送第n好命令是预先保存的委托回调；而你的服务器端则是在收到一个命令时，在本地的功能字典里找到此命令是配的命令处理过程、调用它，并且把返回值序列化之后再打包传送给对方。这就是在一个简单的长连接双向字符串通讯基础上扩展你的业务网关功能。
因此，当你只是掌握比较底层的概念，就说它们“同时都具有两者的角色,服务端也是客户端,客户端也是服务端”这是不对的。
因为在高层次，它们是有绝对的差别的。服务器通常在局域网之外（相对于n层路由器/交换机内部而言），让不同网段的客户端访问。而服务器根本不可能直接找到客户端。从性能上看，服务器的重点目标是同时高性能地服务10万客户端。而客户端可不是这样。服务器端通常是掌握核心的业务逻辑的，而客户端只是简单使用实体数据处理用户交互界面（重点在于交互体验）。因此有着截然不同的设计。
对等网络，通常是一个比较底层的协议。例如一些p2p协议。不要把这个概念胡乱用在你的应用程序设计上。
------解决思路----------------------
在一些应用程序中，所谓“同时具有两者的角色”，是说它把两套系统给编译在同一个程序里边了（当然自然也就可以方便地共享内存等资源）。但是在功能上，你只有看出来分属于服务器和客户端的职责，才能了解其机制。所以没有必要在仅仅了解很底层、内涵很少而外延貌似很大的“收发消息”的概念时就去说“服务端也是客户端,客户端也是服务端”。这样说其实没有多大意义，在你设计，在你设计高级的应用程序时，也会阻碍你进行网络程序设计。
------解决思路----------------------
顶
------解决思路----------------------
腾讯的QQ不是用的UDP的通讯机制么？
------解决思路----------------------
这个你可以到CNBLOG搜一下，有很多这种开源的项目
------解决思路----------------------
可以看一下我的这个Demo http://www.cnblogs.com/networkcomms/p/4263663.html