C#-C#如何开发网络客户端？基于异步好还是多线程好？

Question

现在在开发一个应用，类似实时聊天的。
打算用c#开发客户端，但不知网络通信这块如何处理比较好。
如果基于异步，可以用较少的线程，但似乎代码会很繁琐。
如果使用多线程，基本一个操作就会产生一个线程。比如我发出一句话，就需要产生一个线程去提交这个请求，并跟踪请求是否被正确处理，同样的，点刷新列表也要产生一个线程...这样是否合适？而且我看线程池的介绍，似乎不适合用在这里。

还有API接口这块应该如何做？所有的API请求与回复都使用一个TCP链接，依靠ID号对应的，如何正确地将API返回送到对应的线程？

---

刚发现和微博客户端差不多，不过不是建立在HTTP协议之上的，需要自己做协议。

Answer 1

C# 本身就有很多类似这样的应用,你可以到codeproject上找找,能找出不少.

另外,说说多线程和异步处理的区别吧,多线程,你必须要自己控制线程,自己去写线程池,如果是新手就不推荐了. .net的异步机制相对会简单些,当然你必须要对异步模型有个了解.MSDN上有这些资料,都是比较容易获取的.

Asynchronous Server Socket Example
http://msdn.microsoft.com/en-us/library/fx6588te.aspx

最后说个题外话,如果条件允许你可以看下websocket

Answer 2

这是我的个人BLOG http://blog.csdn.net/luyikk/ 上面有你想要的答案

Answer 3

其实吧，C#里面的异步操作，就是基于多线程……而且就是用的线程池
所以不太明白你说的线程池不适合这里用是啥意思
线程池很适合啊，非常适合啊，大家都喜欢用啊……

然后API是啥……现在的主流是所有网络功能都用WebService实现，所以只要用HTTP部分的接口就行了。如果是即时通信的话Tcp当然绕不开。
为啥需要把返回结果送到对应的线程呢……谁规定了一个请求必须要始终在一个线程里处理的？大家都是在一个线程里发送，再另一个线程里接收处理的嘛……只要数据在各个线程之间共享就行了（要加锁）

WCF的确很时髦，有工夫的话要学一下的。Remoting可以扔掉了。WCF的好处是可以把网络通信做的与协议无关，用TCP也可以通信，用HTTP也可以通信，用Pipe也可以，就不用关心下层到底是啥了。

Answer 4

C# 的Remoting技术,它包装的远程代理对象可以完成你的应用。现在的WCF技术也能满足你的要求。