本人需要构建一个提供大规模并发访问的服务器，能同时提供处理数十万(最好能上百万级)个Socket连接。
这样一来的服务器怎样构建呢？
我想参考网络游戏服务器的设计方法应该就可以,因为所有的网络游戏都要求提供大规模的并发访问.
但是缺乏这方面的资料。
有没有什么通信模型提供了这样的现成的封装呢?我知道开源的ACE好象可以.
如果完全自己来写怎么办呢？
操作系统平台选择Linux.
这样一来的服务器怎样构建呢？
我想参考网络游戏服务器的设计方法应该就可以,因为所有的网络游戏都要求提供大规模的并发访问.
但是缺乏这方面的资料。
有没有什么通信模型提供了这样的现成的封装呢?我知道开源的ACE好象可以.
如果完全自己来写怎么办呢？
操作系统平台选择Linux.
最后肯定还是调用select，再加上多线程，BUF什么的。
主要是大规模的并发访问下，程序很难调好。
需要对SOCKET与TCPIP有很深的理解。
LINUX下可以考虑用epoll模型。，
从成本考虑排除用大型机，构建Linux Cluster技术也太复杂，处理负载均衡等问题就很麻烦了。
HP在做，国内好象南开大学也在搞，总之，成本和技术复杂性也比较大。
我想尽量考虑低成本的硬件，主要在软件上去实现。 rtdb(东临碣石) 说可以，我想问能不能具体谈谈。 elssann() 考虑了带宽的因素，这个Server是要放到Internet上的，地理位置考虑HongKong shootingstars说可以参考apache或者JAWS这个建议比较好
网游的Server的分布式计算是怎么搞的呢？
一台Internet 上的Linux Server最多能处理多大的Socket并发访问量呢？每路通信数据量在10kbps左右。怎样做可以让他支持的最大并发处理能力更大呢？
my mail: [email protected]
是指自己开发大规模并发访问的服务器是可行的。
至于具体性能指标，比如说最大并发处理能力，
则要受多方面的限制。 大家公认的，一是带宽。
其实还有很多其它的，例如数据库，以及CPU。
以网游为例，一个2G的CPU， 若不是简单的棋牌类游戏，
恐怕很难支持众多在线用户的运算。
QQ的服务器是怎么做的呢？QQ主要用的UDP，辅以TCP，他的Server的并发访问量更为巨大！
特别是现在支持视频聊天后通信的数据量也很大，不知道他们是怎么处理的。
我们的产品下一步就要移植到LINUX下，用EPOLL。QQ服务器每台支持8000用户。
大型数据库的大规模并发访问查询是怎么做的呢？
像ACCESS就只能支持几个用户的并发查询
而ORACLE却能支持很大量的用户的并发查询.
还有一些Web的应用系统，并发访问量也是很大的，都是怎样处理呢？
你没看我的问题吗？
况且，查询数据库做个查询网关做什么？
我倒是做过一个通用的数据库访问中间件，可以连接任何数据库，不受数据库表结构的影响，并用户的查询条件动态生成SQL语句。
谢了先！[email protected]
UDP 线程池 异步事件
对于网络编程，我们也言必称TCP/IP，似乎其它网络协议已经不存在了。对于TCP/IP，我们还知道TCP和UDP，前者可以保证数据的正确和可靠性，后者则允许数据丢失。最后，我们还知道，在建立连接前，必须知道对方的IP地址和端口号。除此，普通的程序员就不会知道太多了，很多时候这些知识已经够用了。最多，写服务程序的时候，会使用多线程来处理并发访问。
我们还知道如下几个事实：1。一个指定的端口号不能被多个程序共用。比如，如果IIS占用了80端口，那么Apache就不能也用80端口了。2。很多防火墙只允许特定目标端口的数据包通过。3。服务程序在listen某个端口并accept某个连接请求后，会生成一个新的socket来对该请求进行处理。
于是，一个困惑了我很久的问题就产生了。如果一个socket创建后并与80端口绑定后，是否就意味着该socket占用了80端口呢？如果是这样的，那么当其accept一个请求后，生成的新的socket到底使用的是什么端口呢（我一直以为系统会默认给其分配一个空闲的端口号）？如果是一个空闲的端口，那一定不是80端口了，于是以后的TCP数据包的目标端口就不是80了--防火墙一定会组织其通过的！实际上，我们可以看到，防火墙并没有阻止这样的连接，而且这是最常见的连接请求和处理方式。我的不解就是，为什么防火墙没有阻止这样的连接？它是如何判定那条连接是因为connet80端口而生成的？是不是TCP数据包里有什么特别的标志？或者防火墙记住了什么东西？
后来，我又仔细研读了TCP/IP的协议栈的原理，对很多概念有了更深刻的认识。比如，在TCP和UDP同属于传输层，共同架设在IP层（网络层）之上。而IP层主要负责的是在节点之间（End to End）的数据包传送，这里的节点是一台网络设备，比如计算机。因为IP层只负责把数据送到节点，而不能区分上面的不同应用，所以TCP和UDP协议在其基础上加入了端口的信息，端口于是标识的是一个节点上的一个应用。除了增加端口信息，UPD协议基本就没有对IP层的数据进行任何的处理了。而TCP协议还加入了更加复杂的传输控制，比如滑动的数据发送窗口（Slice Window），以及接收确认和重发机制，以达到数据的可靠传送。不管应用层看到的是怎样一个稳定的TCP数据流，下面传送的都是一个个的IP数据包，需要由TCP协议来进行数据重组。
所以，我有理由怀疑，防火墙并没有足够的信息判断TCP数据包的更多信息，除了IP地址和端口号。而且，我们也看到，所谓的端口，是为了区分不同的应用的，以在不同的IP包来到的时候能够正确转发。
TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket编程接口--原来是这么回事啊！
在Socket编程接口里，设计者提出了一个很重要的概念，那就是socket。这个socket跟文件句柄很相似，实际上在BSD系统里就是跟文件句柄一样存放在一样的进程句柄表里。这个socket其实是一个序号，表示其在句柄表中的位置。这一点，我们已经见过很多了，比如文件句柄，窗口句柄等等。这些句柄，其实是代表了系统中的某些特定的对象，用于在各种函数中作为参数传入，以对特定的对象进行操作--这其实是C语言的问题，在C++语言里，这个句柄其实就是this指针，实际就是对象指针啦。
现在我们知道，socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create，listen，accept，connect，read和write等等。
现在我们明白，如果一个程序创建了一个socket，并让其监听80端口，其实是向TCP/IP协议栈声明了其对80端口的占有。以后，所有目标是80端口的TCP数据包都会转发给该程序（这里的程序，因为使用的是Socket编程接口，所以首先由Socket层来处理）。所谓accept函数，其实抽象的是TCP的连接建立过程。accept函数返回的新socket其实指代的是本次创建的连接，而一个连接是包括两部分信息的，一个是源IP和源端口，另一个是宿IP和宿端口。所以，accept可以产生多个不同的socket，而这些socket里包含的宿IP和宿端口是不变的，变化的只是源IP和源端口。这样的话，这些socket宿端口就可以都是80，而Socket层还是能根据源/宿对来准确地分辨出IP包和socket的归属关系，从而完成对TCP/IP协议的操作封装！而同时，放火墙的对IP包的处理规则也是清晰明了，不存在前面设想的种种复杂的情形。
明白socket只是对TCP/IP协议栈操作的抽象，而不是简单的映射关系，这很重要！