游戏服务器开发为什么很少使用c#?

对这一行不熟悉不敢乱判断。猜测一下可能的原因：

如果用windows当服务器，IOCP很成熟所以选择C++

C#本身带有内存回收机制，对于某些类型的服务器需要自己管理内存回收

技术上没问题，听说过用C#当网页游戏服务器的成功案例

用C#的成本在这一行不算低（综合服务器，开发效率，招人难度等）

现成有许多成熟的公司框架不需要自己重新写，大家跳跳槽也都有了……

在学习网络的过程中，参考一些资料和自己的想法，

考虑的方案：

客户端打包发送，不使用SO_RCVBUF选项，

启用TCP_NODELAY选项，Nagle算法禁用。

使用Nagle算法，通过TCP发送的数据不会马上被发送，而是等待一段时间，当数据包大小达到缓冲区的大小再一次发送，这样就可能导致粘包现象。

（如果数据包长时间未达到缓冲区大小，是不是应该有个时间限制吧，猜测而已，不了解Nagle算法）此方法一般试用于每次发送数据比较小而且比较频繁的情况，

使用此方案，需要控制发送包的大小，如果用来做服务器，特别是游戏服务器，一般发包也不会太大，而且交互次数较频繁，效率比较低（使用Nagle算法的优势可以看到），但每个包的大小固定，至少发送数据包的时候，不会造成粘包。

而且不使用接收缓冲区，数据包发送后马上接收，也不会有几个包黏在一起，不用考虑粘包的问题。

一般看到的方案是，使用SO_RCVBUF，TCP_NODELAY不使用，发包的时候带个包头，发包进行打包处理，接包的时候根据包长度进行粘包处理。

IOCP发包重构问题

方案1

安排序列号，在每个ClientContext上两个序号，一个是某个套接字发包的序号（序号1），从接收到第一个包开始计数；另一个是套接字上读包的序号（序号2），这个包是计算当前读包的序列，从此套接字的第一个包开始读，依次递增；

同时，每个包也有一个编号（编号3），在投递WSARecv的时候，将编号1的值赋予编号3。

当读包的时候，对某个套接字上的包的序号（编号2）与将要读的包的序号（编号3）进行比较，

如果相等，则此包就是即将被读取的包；否则，包没有按顺序接收，将包放到ClientContext的未正确接收缓冲区包中，并对未正确接收缓冲区包按编号2进行排序，从未正确接收缓冲区包的第一个包开始读。

---