UDP 并发服务器，大家帮忙看一看！该如何解决

UDP2000个客户端左右 并发

单个数据包最大512字节

Internet 10MB带宽

要求效率（尽可能快，尽可能少丢包），这种情况下用哪种通讯模型比较有优势！

想用IOCP，因为和select模型相比，这个稍微熟悉一点，也在项目中用过，不过是TCP的。

有两个问题，大家懂得的帮忙给指导一下：

是否可以理解为UDP模式下，一次recvfrom 只对应一次sendto。

2.能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。

------解决方案--------------------------------------------------------

-------------------------------------

等不到，包被截断了。

2.能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。

--------------------------

其实，我个人认为对udp而言，不用iocp也可以满足。 首先sendto都是立即完成的，无需异步操作。而recvfrom可以只需阻塞一个线程就够了，不需要重叠操作。

------解决方案--------------------------------------------------------

用UDX协议最可靠，效率高，开发简单，非开源。

UDT开源，对于你这种2000客户，够用，开源。

------解决方案--------------------------------------------------------

1.sendto 10k,接受部分要么收到10k,要么全部丢失，不会出现部分收到的情况。

------解决方案--------------------------------------------------------

-------------------------------------

在局域网可以，公网，一般1K也收不到。

2.能否对服务端的套接字同时投递多个WsaRecvFrom,能否在多个线程中同时投递WsaSendTo和WsaRecvFrom。

--------------------------完全可以

------解决方案--------------------------------------------------------

1.如果UDP数据在传输过程中被分包，则你需要对数据包进行标识，已确保获取的包完整。一次recvfrom并不对应一次sendto，考虑UDP不可靠传输的因素。

2.不可以，因为sendto和recvfrom都是对同一个资源Socket进行操作。如果在多个线程中对同一个资源进行操作，如果不加锁的情况下，会非常可怕的。而且，如果你加锁了，其实还不如单线程操作。

按照你的需求最好还是采用UDP，不过可以考虑组播。

2.API调用完全没有问题。但是接到的数据可能和发送的数据次序不一样，这本身是UDP乱序特性决定了的。而且你发送方可能是多线程，从API层面来说，这些调用都是可以的，完全没有问题。但是给你接收方处理带来一系列问题。

主从Reactor多线程Nio结构，主从Reactor线程模型的特点是：服务端用于接收客户端连接的不再是个1个单独的NIO线程，而是一个独立的NIO线程池。Acceptor接收到客户端TCP连接请求处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到IO线程池（sub reactor线程池）的某个IO线程上，由它负责SocketChannel的读写和编解码工作。Acceptor线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作。

利用主从NIO线程模型，可以解决1个服务端监听线程无法有效处理所有客户端连接的性能不足问题。

它的工作流程总结如下：

从主线程池中随机选择一个Reactor线程作为Acceptor线程，用于绑定监听端口，接收客户端连接；

Acceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到主线程池的其它Reactor线程上，由其负责接入认证、IP黑白名单过滤、握手等操作；

步骤2完成之后，业务层的链路正式建立，将SocketChannel从主线程池的Reactor线程的多路复用器上摘除，重新注册到Sub线程池的线程上，用于处理I/O的读写操作。

　服务程序最为关键的设计是并发服务模型，当前有以下几种典型的模型：

- 单进程服务，使用非阻塞IO

使用一个进程服务多个客户，通常与客户通信的套接字设置为非阻塞的，阻塞只发生在select()、poll()、epoll_wait()等系统调用上面。这是一种行之有效的单进程状态机式服务方式，已被广泛采用。

缺点是它无法利用SMP(对称多处理器)的优势，除非启动多个进程。此外，它尝试就绪的IO文件描述符后，立即从系统调用返回，这会导致大量的系统调用发生，尤其是在较慢的字节传输时。

select()本身的实现也是有局限的：能打开的文件描述符最多不能超过FD_SETSIZE，很容易耗尽；每次从select()返回的描述符组中扫描就绪的描述符需要时间，如果就绪的描述符在末尾时更是如此（epoll特别彻底修复了这个问题）。

- 多进程服务，使用阻塞IO

也称作 accept/fork 模型，每当有客户连线时产生一个新的进程为之服务。这种方式有时是必要的，比如可以通过操作系统获得良好的内存保护，可以以不同的用户身份运行程序，可以让服务运行在不同的目录下面。但是它的缺点也很明显：进程比较占资源，进程切换开销太大，共享某些信息比较麻烦。Apache 1.3就使用了这种模型，MaxClients数很容易就可以达到。

---