C# Socket服务器和客户端通信问题！！！

Question

服务器socket通信tcpc#

Answer 1

如果服务器要给客户端返回任何结果，它可以从（你所谓的）Socket列表中取出这个客户端的 Socket 对象，然后执行 Send 就行了。这跟线程没有关系。就算是服务器端是单线程处理1万在线客户端请求的，它也照样可以对此 Socket 对象执行 Send 语句。因此主要是你的服务器端程序有 bug 造成的。

Answer 2

先不要去纠结线程问题，先搞清楚你自己的服务器端如何对所谓“客户端Socket”执行 Send 的操作流程。你得操作流程上一定是有 bug 的。具体的bug还是得你自己去找出来。

Answer 3

服务器：客户端建立连接后使用clientSocket.poll(-1,SelectMode.SelectRead)进行监听，同时将上线信息通过遍历客户端列表给所有在线用户（clientSocket.Send），当receive到消息后处理消息，在把处理结果send给客户端。客户端:用户执行操作-->暂停本地监听-->socket.send--->socket.receive-->启动本地监听
客户端的本地监听负责接收其他客户端的上线信息这个操作流程会出现客户端send后receive到的是上线信息，而不是服务器端的处理结果！不知道大牛们都是怎么处理的！！！！

Answer 4

消息应该是有信令规范的。比如说消息的头部应该有一个“消息编号”，表示是哪一个消息，同时也有一个标志表示是“发出请求”还是“返回结果”。那么你的客户端收到的消息时，应该判断受到的消息是服务器端推送来的，还是返回的。当客户端向服务器发送消息时，例如是这样的语法public void SendMessage(MyMessageType mesage, Action<MyMessageType> callback){ ... }应该注册有回调委托方法。在本地保存有一个“等待返回消息”对象集合，其中包括“要等待的消息编号、回调函数、超时时间”等。当你的客户端向服务器发送了消息1、2、3、4、5，然后服务器可能以顺序1、2、4、5、3顺序返回，你收到这些消息时应该从集合中取出（移出）相应的对象，并回调对应的 callback。而收到的服务器端“主动请求”的消息，则直接查找客户端本地的执行程序去执行，而不需要查找回调方法。客户端要高效率地访问服务器，应该支持并发多任务地访问服务器，异步回调方法。设计上就算是 jQuery 程序员都会使用异步回调进行程序，一个 .net 程序员怎么能不会设计异步回调程序呢？

Answer 5

2个字  异步 .....无非就是ABCDE已经连接 这个时候F登陆 socket收到 那么循环ABCDE 分别beginsend而已...

Answer 6

异步的意思是“打乱处理次序、隐藏内部调用机制”。比如说你以 1、2、3、4、5 顺序发送消息，你不能假设对方一定是以 1、2、3、4、5 的顺序来返回结果，所以才使用异步。异步跟多线程没有直接关系，但是异步很灵活，所以可以让多线程程序变得非常简单。你的客户端可以并发地处理各种业务，例如加载一幅GIS地图时往往会并发几个线程去处理各个子图层，并且挥着图形集合中往往也还需要另外再与服务器交互，因此绘制一幅地图（的底图上面的那些“活的”图形也）往往要与服务器交互几十次。例如需要立刻发出30个命令来访问服务器，如果这些顺序（等待）处理那么客户端就会显得好像“卡”了20秒钟才开始渲染，而如果并发处理则可能显得好像只要等 2 秒钟就已经绘制出主要图形了。这时候，你在多线程中向访问服务器发送出去命令之后，不能“阻塞”在那里占用线程，而是直接就结束了。等服务器返回相应的结果，才在回调方法中继续处理。设计大量这样的程序，你应该首先把流程图、时序图画出来。如果你画出来的是传统的“顺序”流程图，那么应该从头开始考虑一下自己的设计技术。与服务器交互的高性能的客户端程序的流程，根本不可能是顺序执行的！

Answer 7

短连接不能处理服务器“推”消息问题，每一次握手的时间消耗巨大。与其短连接，不如改为 http 方式。反之，如果你有些东西必须用比较高级的通讯控制模式，那么必须花点精力设计一个新的通用模块。

Answer 8

异步处理，只会花费你“抽半包烟的时间”。你应该把它封装起来，那么调用者使用它没有什么技术难度。我上面已经写了一个 SendMessage 的接口原型。