静态库和动态库的区别

1. 静态函数库

    这类库的名字一般是libxxx.a；利用静态函数库编译成的文件比较大，因为整个 函数库的所有数据都会被整合进目标代码中，他的优点就显而易见了，即编译后的执行程序不需要外部的函数库支持，因为所有使用的函数都已经被编译进去了。当然这也会成为他的缺点，因为如果静态函数库改变了，那么你的程序必须重新编译。

2. 动态函数库

    这类库的名字一般是libxxx.so;相对于静态函数库，动态函数库在编译的时候 并没有被编译进目标代码中，你的程序执行到相关函数时才调用该函数库里的相应函数，因此动态函数库所产生的可执行文件比较小。由于函数库没有被整合进你的程序，而是程序运行时动态的申请并调用，所以程序的运行环境中必须提供相应的库。动态函数库的改变并不影响你的程序，所以动态函数库的升级比较方便。 
linux系统有几个重要的目录存放相应的函数库，如/lib /usr/lib。

静态库的使用

静态库的操作工具：gcc和ar 命令。 

编写及使用静态库 

(1)设计库源码 pr1.c 和 pr2.c 

[root@billstone make_lib]# cat pr1.c 

void print1() 

{ 

                printf("This is the first lib src!\n"); 

} 

[root@billstone make_lib]# cat pr2.c 

void print2() 

{ 

                printf("This is the second src lib!\n"); 

} 

       (2)  编译.c 文件 

[bill@billstone make_lib]$ cc -O -c pr1.c pr2.c 

[bill@billstone make_lib]$ ls -l pr*.o 

-rw-rw-r--        1 bill          bill                    804    4 月  15 11:11 pr1.o 

-rw-rw-r--        1 bill          bill                    804    4 月  15 11:11 pr2.o 

(3)  链接静态库 

    为了在编译程序中正确找到库文件,静态库必须按照 lib[name].a 的规则命名,如下例中[name]=pr. 

[bill@billstone make_lib]$ ar -rsv libpr.a pr1.o pr2.o 

a - pr1.o 

a - pr2.o 

[bill@billstone make_lib]$ ls -l *.a 

-rw-rw-r--        1 bill          bill                  1822    4 月  15 11:12 libpr.a 

[bill@billstone make_lib]$ ar -t libpr.a 

pr1.o 

pr2.o 

(4)  调用库函数代码 main.c 

[bill@billstone make_lib]$ cat main.c 

int main() 

{ 

                print1(); 

                print2(); 

                return 0; 

} 

(5)  编译链接选项 

    -L 及-l 参数放在后面.其中,-L 加载库文件路径,-l 指明库文件名字. 

[bill@billstone make_lib]$ gcc -o main main.c -L./ -lpr 

[bill@billstone make_lib]$ ls -l main* 

-rwxrwxr-x        1 bill          bill                11805    4 月  15 11:17 main 

-rw-rw-r--        1 bill          bill                      50    4 月  15 11:15 main.c 

(6)执行目标程序 

[bill@billstone make_lib]$ ./main 

This is the first lib src! 

This is the second src lib! 

[bill@billstone make_lib]$ 

动态库的使用

编写动态库 

(1)设计库代码 

[bill@billstone make_lib]$ cat pr1.c 

int p = 2; 

void print(){ 

                printf("This is the first dll src!\n"); 

} 

[bill@billstone make_lib]$   

(2)生成动态库 

[bill@billstone make_lib]$ gcc -O -fpic -shared -o dl.so pr1.c 

[bill@billstone make_lib]$ ls -l *.so 

-rwxrwxr-x        1 bill          bill                  6592    4 月  15 15:19 dl.so 

[bill@billstone make_lib]$ 

动态库的隐式调用 

  在编译调用库函数代码时指明动态库的位置及名字,  看下面实例 

[bill@billstone make_lib]$ cat main.c 

int main() 

{ 

                print(); 

                return 0; 

} 

[bill@billstone make_lib]$ gcc -o tdl main.c ./dl.so 

[bill@billstone make_lib]$ ./tdl 

This is the first dll src! 

[bill@billstone make_lib]$ 

当动态库的位置活名字发生改变时,  程序将无法正常运行;  而动态库取代静态库的好处之一则是通过更新动态库而随时升级库的内容. 

动态库的显式调用 

  显式调用动态库需要四个函数的支持,  函数 dlopen 打开动态库,  函数 dlsym 获取动态库中对象基址,  函数 dlerror 获取显式动态库操作中的错误信息,  函数 doclose 关闭动态库.

[bill@billstone make_lib]$ cat main.c 

#include <dlfcn.h> 

int main() 

{ 

                void *pHandle; 

                void (*pFunc)();                                                    //  指向函数的指针 

                int *p; 

                pHandle = dlopen("./d1.so", RTLD_NOW);                  //  打开动态库 

                if(!pHandle){ 

                                printf("Can't find d1.so \n"); 

                                exit(1); 

                } 

                pFunc = (void (*)())dlsym(pHandle, "print");                //  获取库函数 print 的地址 

                if(pFunc) 

                                pFunc(); 

                else 

                                printf("Can't find function print\n"); 

                p = (int *)dlsym(pHandle, "p");                                      //  获取库变量 p 的地址 

                if(p) 

                                printf("p = %d\n", *p); 

                else 

                                printf("Can't find int p\n"); 

                dlclose(pHandle);                                                                //  关闭动态库 

                return 0; 

} 

[bill@billstone make_lib]$ gcc -o tds main.c –ld1 –L.

此时还不能立即./tds，因为在动态函数库使用时，会查找/usr/lib、/lib目录下的动态函数库，而此时我们生成的库不在里边。 这个时候有好几种方法可以让他成功运行： 最直接最简单的方法就是把libstr_out.so拉到/usr/lib或/lib中去。 还有一种方法 export LD_LIBRARY_PATH=$(pwd) 另外还可以在/etc/ld.so.conf文件里加入我们生成的库的目录，然后/sbin/ldconfig。 /etc/ld.so.conf是非常重要的一个目录，里面存放的是链接器和加载器搜索共享库时要检查的目录，默认是从/usr/lib /lib中读取的，所以想要顺利运行，我们也可以把我们库的目录加入到这个文件中并执行/sbin/ldconfig 。另外还有个文件需要了解/etc/ld.so.cache,里面保存了常用的动态函数库，且会先把他们加载到内存中，因为内存的访问速度远远大于硬盘的访问速度，这样可以提高软件加载动态函数库的速度了。

库依赖的查看

使用ldd命令来查看执行文件依赖于哪些库。

该命令用于判断某个可执行的 binary 档案含有什么动态函式库。
[root@test root]# ldd [-vdr] [filename]
参数说明：
--version　　打印ldd的版本号
-v --verbose　　打印所有信息，例如包括符号的版本信息
-d --data-relocs　　执行符号重部署，并报告缺少的目标对象（只对ELF格式适用）
-r --function-relocs　　对目标对象和函数执行重新部署，并报告缺少的目标对象和函数（只对ELF格式适用）
--help 用法信息。

如果命令行中给定的库名字包含'/'，这个程序的libc5版本将使用它作为库名字；否则它将在标准位置搜索库。运行一个当前目录下的共享库，加前缀"./"。

WINDOWS完成端口编程
        摘要：开发网络程序从来都不是一件容易的事情，尽管只需要遵守很少的一些规则;创建socket,发起连接，接受连接，发送和接受数据。真正的困难在于：让你的程序可以适应从单单一个连接到几千个连接乃至于上万个连接。利用Windows平台完成端口进行重叠I/O的技术和Linux在2.6版本的内核中引入的EPOll技术，可以很方便在在在Windows和Linux平台上开发出支持大量连接的网络服务程序。本文介绍在Windows和Linux平台上使用的完成端口和EPoll模型开发的基本原理，同时给出实际的例子。本文主要关注C/S结构的服务器端程序，因为一般来说，开发一个大容量，具可扩展性的winsock程序一般就是指服务程序。

1、基本概念
    设备---windows操作系统上允许通信的任何东西，比如文件、目录、串行口、并行口、邮件槽、命名管道、无名管道、套接字、控制台、逻辑磁盘、物理磁盘等。绝大多数与设备打交道的函数都是CreateFile/ReadFile/WriteFile等。所以我们不能看到**File函数就只想到文件设备。与设备通信有两种方式，同步方式和异步方式。同步方式下，当调用ReadFile函数时，函数会等待系统执行完所要求的工作，然后才返回；异步方式下，ReadFile这类函数会直接返回，系统自己去完成对设备的操作，然后以某种方式通知完成操作。
重叠I/O----顾名思义，当你调用了某个函数（比如ReadFile）就立刻返回做自己的其他动作的时候，同时系统也在对I/0设备进行你要求的操作，在这段时间内你的程序和系统的内部动作是重叠的，因此有更好的性能。所以，重叠I/O是用于异步方式下使用I/O设备的。 重叠I/O需要使用的一个非常重要的数据结构OVERLAPPED。

2、WINDOWS完成端口的特点
   Win32重叠I/O(Overlapped I/O)机制允许发起一个操作，然后在操作完成之后接受到信息。对于那种需要很长时间才能完成的操作来说，重叠IO机制尤其有用，因为发起重叠操作的线程在重叠请求发出后就可以自由的做别的事情了。在WinNT和Win2000上，提供的真正的可扩展的I/O模型就是使用完成端口（Completion Port）的重叠I/O.完成端口---是一种WINDOWS内核对象。完成端口用于异步方式的重叠I/0情况下，当然重叠I/O不一定非使用完成端口不可，还有设备内核对象、事件对象、告警I/0等。但是完成端口内部提供了线程池的管理，可以避免反复创建线程的开销，同时可以根据CPU的个数灵活的决定线程个数，而且可以让减少线程调度的次数从而提高性能其实类似于WSAAsyncSelect和select函数的机制更容易兼容Unix，但是难以实现我们想要的“扩展性”。而且windows的完成端口机制在操作系统内部已经作了优化，提供了更高的效率。所以，我们选择完成端口开始我们的服务器程序的开发。
1、发起操作不一定完成，系统会在完成的时候通知你，通过用户在完成端口上的等待，处理操作的结果。所以要有检查完成端口，取操作结果的线程。在完成端口上守候的线程系统有优化，除非在执行的线程阻塞，不会有新的线程被激活，以此来减少线程切换造成的性能代价。所以如果程序中没有太多的阻塞操作，没有必要启动太多的线程，CPU数量的两倍，一般这样来启动线程。
2、操作与相关数据的绑定方式：在提交数据的时候用户对数据打相应的标记，记录操作的类型，在用户处理操作结果的时候，通过检查自己打的标记和系统的操作结果进行相应的处理。 
3、操作返回的方式:一般操作完成后要通知程序进行后续处理。但写操作可以不通知用户，此时如果用户写操作不能马上完成，写操作的相关数据会被暂存到到非交换缓冲区中，在操作完成的时候，系统会自动释放缓冲区。此时发起完写操作，使用的内存就可以释放了。此时如果占用非交换缓冲太多会使系统停止响应。

3、完成端口（Completion Ports ）相关数据结构和创建
    其实可以把完成端口看成系统维护的一个队列，操作系统把重叠IO操作完成的事件通知放到该队列里，由于是暴露 “操作完成”的事件通知，所以命名为“完成端口”（COmpletion Ports）。一个socket被创建后，可以在任何时刻和一个完成端口联系起来。
完成端口相关最重要的是OVERLAPPED数据结构
typedef struct _OVERLAPPED { 
    ULONG_PTR Internal;//被系统内部赋值，用来表示系统状态 
    ULONG_PTR InternalHigh;// 被系统内部赋值，传输的字节数 
    union { 
        struct { 
            DWORD Offset;//和OffsetHigh合成一个64位的整数，用来表示从文件头部的多少字节开始 
            DWORD OffsetHigh;//操作，如果不是对文件I/O来操作，则必须设定为0 
        }; 
        PVOID Pointer; 
    }; 
    HANDLE hEvent;//如果不使用，就务必设为0,否则请赋一个有效的Event句柄 
} OVERLAPPED, *LPOVERLAPPED; 

下面是异步方式使用ReadFile的一个例子 
OVERLAPPED Overlapped; 
Overlapped.Offset=345; 
Overlapped.OffsetHigh=0; 
Overlapped.hEvent=0; 
//假定其他参数都已经被初始化 
ReadFile(hFile,buffer,sizeof(buffer),&dwNumBytesRead,&Overlapped); 
这样就完成了异步方式读文件的操作，然后ReadFile函数返回，由操作系统做自己的事情，下面介绍几个与OVERLAPPED结构相关的函数 
等待重叠I/0操作完成的函数 
BOOL GetOverlappedResult (
HANDLE hFile,
LPOVERLAPPED lpOverlapped,//接受返回的重叠I/0结构
LPDWORD lpcbTransfer,//成功传输了多少字节数
BOOL fWait //TRUE只有当操作完成才返回，FALSE直接返回，如果操作没有完成，通过调//用GetLastError ( )函数会返回ERROR_IO_INCOMPLETE 
);
宏HasOverlappedIoCompleted可以帮助我们测试重叠I/0操作是否完成，该宏对OVERLAPPED结构的Internal成员进行了测试，查看是否等于STATUS_PENDING值。

        一般来说，一个应用程序可以创建多个工作线程来处理完成端口上的通知事件。工作线程的数量依赖于程序的具体需要。但是在理想的情况下，应该对应一个CPU创建一个线程。因为在完成端口理想模型中，每个线程都可以从系统获得一个“原子”性的时间片，轮番运行并检查完成端口，线程的切换是额外的开销。在实际开发的时候，还要考虑这些线程是否牵涉到其他堵塞操作的情况。如果某线程进行堵塞操作，系统则将其挂起，让别的线程获得运行时间。因此，如果有这样的情况，可以多创建几个线程来尽量利用时间。
应用完成端口：
    创建完成端口：完成端口是一个内核对象，使用时他总是要和至少一个有效的设备句柄进行关联，完成端口是一个复杂的内核对象，创建它的函数是：
HANDLE CreateIoCompletionPort( 
    IN HANDLE FileHandle, 
    IN HANDLE ExistingCompletionPort, 
    IN ULONG_PTR CompletionKey, 
    IN DWORD NumberOfConcurrentThreads 
    ); 

通常创建工作分两步：
第一步，创建一个新的完成端口内核对象，可以使用下面的函数：
       HANDLE CreateNewCompletionPort(DWORD dwNumberOfThreads) 
{ 
          return CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL,NULL,dwNumberOfThreads); 
};
       
第二步，将刚创建的完成端口和一个有效的设备句柄关联起来，可以使用下面的函数：
       bool AssicoateDeviceWithCompletionPort(HANDLE hCompPort,HANDLE hDevice,DWORD dwCompKey) 
{ 
          HANDLE h=CreateIoCompletionPort(hDevice,hCompPort,dwCompKey,0); 
          return h==hCompPort; 
}; 
说明 
1） CreateIoCompletionPort函数也可以一次性的既创建完成端口对象，又关联到一个有效的设备句柄 
2） CompletionKey是一个可以自己定义的参数，我们可以把一个结构的地址赋给它，然后在合适的时候取出来使用，最好要保证结构里面的内存不是分配在栈上，除非你有十分的把握内存会保留到你要使用的那一刻。
3） NumberOfConcurrentThreads通常用来指定要允许同时运行的的线程的最大个数。通常我们指定为0，这样系统会根据CPU的个数来自动确定。创建和关联的动作完成后，系统会将完成端口关联的设备句柄、完成键作为一条纪录加入到这个完成端口的设备列表中。如果你有多个完成端口，就会有多个对应的设备列表。如果设备句柄被关闭，则表中自动删除该纪录。

4、完成端口线程的工作原理
完成端口可以帮助我们管理线程池，但是线程池中的线程需要我们使用_beginthreadex来创建，凭什么通知完成端口管理我们的新线程呢？答案在函数GetQueuedCompletionStatus。该函数原型： 
BOOL GetQueuedCompletionStatus( 
    IN HANDLE CompletionPort, 
    OUT LPDWORD lpNumberOfBytesTransferred, 
    OUT PULONG_PTR lpCompletionKey, 
    OUT LPOVERLAPPED *lpOverlapped, 
    IN DWORD dwMilliseconds 
); 
这个函数试图从指定的完成端口的I/0完成队列中抽取纪录。只有当重叠I/O动作完成的时候，完成队列中才有纪录。凡是调用这个函数的线程将被放入到完成端口的等待线程队列中，因此完成端口就可以在自己的线程池中帮助我们维护这个线程。完成端口的I/0完成队列中存放了当重叠I/0完成的结果---- 一条纪录，该纪录拥有四个字段，前三项就对应GetQueuedCompletionStatus函数的2、3、4参数，最后一个字段是错误信息dwError。我们也可以通过调用PostQueudCompletionStatus模拟完成了一个重叠I/0操作。 
当I/0完成队列中出现了纪录，完成端口将会检查等待线程队列，该队列中的线程都是通过调用GetQueuedCompletionStatus函数使自己加入队列的。等待线程队列很简单，只是保存了这些线程的ID。完成端口会按照后进先出的原则将一个线程队列的ID放入到释放线程列表中，同时该线程将从等待GetQueuedCompletionStatus函数返回的睡眠状态中变为可调度状态等待CPU的调度。所以我们的线程要想成为完成端口管理的线程，就必须要调用GetQueuedCompletionStatus函数。出于性能的优化，实际上完成端口还维护了一个暂停线程列表，具体细节可以参考《Windows高级编程指南》，我们现在知道的知识，已经足够了。 完成端口线程间数据传递线程间传递数据最常用的办法是在_beginthreadex函数中将参数传递给线程函数，或者使用全局变量。但是完成端口还有自己的传递数据的方法，答案就在于CompletionKey和OVERLAPPED参数。
CompletionKey被保存在完成端口的设备表中，是和设备句柄一一对应的，我们可以将与设备句柄相关的数据保存到CompletionKey中，或者将CompletionKey表示为结构指针，这样就可以传递更加丰富的内容。这些内容只能在一开始关联完成端口和设备句柄的时候做，因此不能在以后动态改变。
OVERLAPPED参数是在每次调用ReadFile这样的支持重叠I/0的函数时传递给完成端口的。我们可以看到，如果我们不是对文件设备做操作，该结构的成员变量就对我们几乎毫无作用。我们需要附加信息，可以创建自己的结构，然后将OVERLAPPED结构变量作为我们结构变量的第一个成员，然后传递第一个成员变量的地址给ReadFile函数。因为类型匹配，当然可以通过编译。当GetQueuedCompletionStatus函数返回时，我们可以获取到第一个成员变量的地址，然后一个简单的强制转换，我们就可以把它当作完整的自定义结构的指针使用，这样就可以传递很多附加的数据了。太好了！只有一点要注意，如果跨线程传递，请注意将数据分配到堆上，并且接收端应该将数据用完后释放。我们通常需要将ReadFile这样的异步函数的所需要的缓冲区放到我们自定义的结构中，这样当GetQueuedCompletionStatus被返回时，我们的自定义结构的缓冲区变量中就存放了I/0操作的数据。CompletionKey和OVERLAPPED参数，都可以通过GetQueuedCompletionStatus函数获得。
线程的安全退出
       很多线程为了不止一次的执行异步数据处理，需要使用如下语句
while (true)
{
       ......
       GetQueuedCompletionStatus(...); 
        ......
}
那么如何退出呢，答案就在于上面曾提到的PostQueudCompletionStatus函数，我们可以用它发送一个自定义的包含了OVERLAPPED成员变量的结构地址，里面包含一个状态变量，当状态变量为退出标志时，线程就执行清除动作然后退出。

5、Windows完成端口的实例代码：
DWORD WINAPI WorkerThread(LPVOID lpParam)
{ 
ULONG_PTR *PerHandleKey;
OVERLAPPED *Overlap;
OVERLAPPEDPLUS *OverlapPlus,
*newolp;
DWORD dwBytesXfered;
while (1)
{
ret = GetQueuedCompletionStatus(
hIocp,
&dwBytesXfered,
(PULONG_PTR)&PerHandleKey,
&Overlap,
INFINITE);
if (ret == 0)
{
// Operation failed
continue;
}
OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol);
switch (OverlapPlus->OpCode)
{
case OP_ACCEPT:
// Client socket is contained in OverlapPlus.sclient
// Add client to completion port
CreateIoCompletionPort(
(HANDLE)OverlapPlus->sclient,
hIocp,
(ULONG_PTR)0,
0);
// Need a new OVERLAPPEDPLUS structure
// for the newly accepted socket. Perhaps
// keep a look aside list of free structures.
newolp = AllocateOverlappedPlus();
if (!newolp)
{
// Error
}
newolp->s = OverlapPlus->sclient;
newolp->OpCode = OP_READ;
// This function divpares the data to be sent
PrepareSendBuffer(&newolp->wbuf);
ret = WSASend(
newolp->s,
&newolp->wbuf,
1,
&newolp->dwBytes,
0,
&newolp.ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
// Put structure in look aside list for later use
FreeOverlappedPlus(OverlapPlus);
// Signal accept thread to issue another AcceptEx
SetEvent(hAcceptThread);
break;
case OP_READ:
// Process the data read 
// Repost the read if necessary, reusing the same
// receive buffer as before
memset(&OverlapPlus->ol, 0, sizeof(OVERLAPPED));
ret = WSARecv(
OverlapPlus->s,
&OverlapPlus->wbuf,
1,
&OverlapPlus->dwBytes,
&OverlapPlus->dwFlags,
&OverlapPlus->ol,
NULL);
if (ret == SOCKET_ERROR)
{
if (WSAGetLastError() != WSA_IO_PENDING)
{
// Error
}
}
break;
case OP_WRITE:
// Process the data sent, etc.
break;
} // switch
} // while
} // WorkerThread

查看以上代码，注意如果Overlapped操作立刻失败（比如，返回SOCKET_ERROR或其他非WSA_IO_PENDING的错误），则没有任何完成通知时间会被放到完成端口队列里。反之，则一定有相应的通知时间被放到完成端口队列。更完善的关于Winsock的完成端口机制，可以参考MSDN的Microsoft PlatFormSDK，那里有完成端口的例子。访问http://msdn.microsoft.com/library/techart/msdn_servrapp.htm可以获得更多信息。

Linux的EPoll模型
Linux 2.6内核中提高网络I/O性能的新方法-epoll I/O多路复用技术在比较多的TCP网络服务器中有使用，即比较多的用到select函数。

1、为什么select落后
首先，在Linux内核中，select所用到的FD_SET是有限的，即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个数，在我用的2.6.15-25-386内核中，该值是1024，搜索内核源代码得到：
include/linux/posix_types.h:#define __FD_SETSIZE         1024
也就是说，如果想要同时检测1025个句柄的可读状态是不可能用select实现的。或者同时检测1025个句柄的可写状态也是不可能的。其次，内核中实现select是用轮询方法，即每次检测都会遍历所有FD_SET中的句柄，显然，select函数执行时间与FD_SET中的句柄个数有一个比例关系，即select要检测的句柄数越多就会越费时。当然，在前文中我并没有提及poll方法，事实上用select的朋友一定也试过poll，我个人觉得select和poll大同小异，个人偏好于用select而已。

2、内核中提高I/O性能的新方法epoll
epoll是什么？按照man手册的说法：是为处理大批量句柄而作了改进的poll。要使用epoll只需要这三个系统调用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。
当然，这不是2.6内核才有的，它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44)

Linux2.6内核epoll介绍
先介绍2本书《The Linux Networking Architecture--Design and Implementation of Network Protocols in the Linux Kernel》，以2.4内核讲解Linux TCP/IP实现，相当不错.作为一个现实世界中的实现，很多时候你必须作很多权衡，这时候参考一个久经考验的系统更有实际意义。举个例子,linux内核中sk_buff结构为了追求速度和安全，牺牲了部分内存，所以在发送TCP包的时候，无论应用层数据多大,sk_buff最小也有272的字节.其实对于socket应用层程序来说，另外一本书《UNIX Network Programming Volume 1》意义更大一点.2003年的时候，这本书出了最新的第3版本，不过主要还是修订第2版本。其中第6章《I/O Multiplexing》是最重要的。Stevens给出了网络IO的基本模型。在这里最重要的莫过于select模型和Asynchronous I/O模型.从理论上说，AIO似乎是最高效的，你的IO操作可以立即返回，然后等待os告诉你IO操作完成。但是一直以来，如何实现就没有一个完美的方案。最著名的windows完成端口实现的AIO,实际上也是内部用线程池实现的罢了，最后的结果是IO有个线程池，你应用也需要一个线程池...... 很多文档其实已经指出了这带来的线程context-switch带来的代价。在linux 平台上，关于网络AIO一直是改动最多的地方，2.4的年代就有很多AIO内核patch,最著名的应该算是SGI那个。但是一直到2.6内核发布，网络模块的AIO一直没有进入稳定内核版本(大部分都是使用用户线程模拟方法，在使用了NPTL的linux上面其实和windows的完成端口基本上差不多了)。2.6内核所支持的AIO特指磁盘的AIO---支持io_submit(),io_getevents()以及对Direct IO的支持(就是绕过VFS系统buffer直接写硬盘，对于流服务器在内存平稳性上有相当帮助)。
所以，剩下的select模型基本上就是我们在linux上面的唯一选择，其实，如果加上no-block socket的配置，可以完成一个"伪"AIO的实现，只不过推动力在于你而不是os而已。不过传统的select/poll函数有着一些无法忍受的缺点，所以改进一直是2.4-2.5开发版本内核的任务，包括/dev/poll，realtime signal等等。最终，Davide Libenzi开发的epoll进入2.6内核成为正式的解决方案

3、epoll的优点
<1>支持一个进程打开大数目的socket描述符(FD)
select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完美的方案。不过 epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
<2>IO效率不随FD数目增加而线性下降
传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是"活跃"的，但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对"活跃"的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有"活跃"的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个"伪"AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的---比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。
<3>使用mmap加速内核与用户空间的消息传递。
这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话，一定不会忘记手工 mmap这一步的。
<4>内核微调
这一点其实不算epoll的优点了，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。比如，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小--- 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手的数据包队列长度)，也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。
4、epoll的工作模式
令人高兴的是，2.6内核的epoll比其2.5开发版本的/dev/epoll简洁了许多，所以，大部分情况下，强大的东西往往是简单的。唯一有点麻烦是epoll有2种工作方式:LT和ET。
LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。
epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用，具体用法请参考http://www.xmailserver.org/linux-patches/nio-improve.html ，在http://www.kegel.com/rn/也有一个完整的例子，大家一看就知道如何使用了
Leader/follower模式线程pool实现，以及和epoll的配合。

5、 epoll的使用方法
    首先通过create_epoll(int maxfds)来创建一个epoll的句柄，其中maxfds为你epoll所支持的最大句柄数。这个函数会返回一个新的epoll句柄，之后的所有操作将通过这个句柄来进行操作。在用完之后，记得用close()来关闭这个创建出来的epoll句柄。 之后在你的网络主循环里面，每一帧的调用epoll_wait(int epfd, epoll_event events, int max events, int timeout)来查询所有的网络接口，看哪一个可以读，哪一个可以写了。基本的语法为： 
nfds = epoll_wait(kdpfd, events, maxevents, -1); 
其中kdpfd为用epoll_create创建之后的句柄，events是一个epoll_event*的指针，当epoll_wait这个函数操作成功之后，epoll_events里面将储存所有的读写事件。max_events是当前需要监听的所有socket句柄数。最后一个timeout是epoll_wait的超时，为0的时候表示马上返回，为-1的时候表示一直等下去，直到有事件范围，为任意正整数的时候表示等这么长的时间，如果一直没有事件，则范围。一般如果网络主循环是单独的线程的话，可以用-1来等，这样可以保证一些效率，如果是和主逻辑在同一个线程的话，则可以用0来保证主循环的效率。

epoll_wait范围之后应该是一个循环，遍利所有的事件： 
for(n = 0; n < nfds; ++n) { 
                if(events[n].data.fd == listener) { //如果是主socket的事件的话，则表示有新连接进入了，进行新连接的处理。 
                    client = accept(listener, (struct sockaddr *) &local, 
                                    &addrlen); 
                    if(client < 0){ 
                        perror("accept"); 
                        continue; 
                    } 
                    setnonblocking(client); // 将新连接置于非阻塞模式 
                    ev.events = EPOLLIN | EPOLLET; // 并且将新连接也加入EPOLL的监听队列。 
注意，这里的参数EPOLLIN | EPOLLET并没有设置对写socket的监听，如果有写操作的话，这个时候epoll是不会返回事件的，如果要对写操作也监听的话，应该是EPOLLIN | EPOLLOUT | EPOLLET 
                    ev.data.fd = client; 
                    if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) { 
// 设置好event之后，将这个新的event通过epoll_ctl加入到epoll的监听队列里面，这里用EPOLL_CTL_ADD来加一个新的epoll事件，通过EPOLL_CTL_DEL来减少一个epoll事件，通过EPOLL_CTL_MOD来改变一个事件的监听方式。 
                        fprintf(stderr, "epoll set insertion error: fd=%d0, 
                                client); 
                        return -1; 
                    } 
                } 
                else // 如果不是主socket的事件的话，则代表是一个用户socket的事件，则来处理这个用户socket的事情，比如说read(fd,xxx)之类的，或者一些其他的处理。 
                    do_use_fd(events[n].data.fd); 
}

对，epoll的操作就这么简单，总共不过4个API：epoll_create, epoll_ctl, epoll_wait和close。 
如果您对epoll的效率还不太了解，请参考我之前关于网络游戏的网络编程等相关的文章。

以前公司的服务器都是使用HTTP连接，但是这样的话，在手机目前的网络情况下不但显得速度较慢，而且不稳定。因此大家一致同意用SOCKET来进行连接。虽然使用SOCKET之后，对于用户的费用可能会增加(由于是用了CMNET而非CMWAP)，但是，秉着用户体验至上的原则，相信大家还是能够接受的(希望那些玩家月末收到帐单不后能够保持克制...)。
这次的服务器设计中，最重要的一个突破，是使用了EPOLL模型，虽然对之也是一知半解，但是既然在各大PC网游中已经经过了如此严酷的考验，相信他不会让我们失望，使用后的结果，确实也是表现相当不错。在这里，我还是主要大致介绍一下这个模型的结构。
6、Linux下EPOll编程实例
EPOLL模型似乎只有一种格式，所以大家只要参考我下面的代码，就能够对EPOLL有所了解了，代码的解释都已经在注释中：

while (TRUE)
{
int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS, EPOLL_TIME_OUT);//等待EPOLL时间的发生，相当于监听，至于相关的端口，需要在初始化EPOLL的时候绑定。
if (nfds <= 0)
continue;
m_bOnTimeChecking = FALSE;
G_CurTime = time(NULL);
for (int i=0; i
{
try
{
if (m_events[i].data.fd == m_listen_http_fd)//如果新监测到一个HTTP用户连接到绑定的HTTP端口，建立新的连接。由于我们新采用了SOCKET连接，所以基本没用。
{
OnAcceptHttpEpoll ();
}
else if (m_events[i].data.fd == m_listen_sock_fd)//如果新监测到一个SOCKET用户连接到了绑定的SOCKET端口，建立新的连接。
{
OnAcceptSockEpoll ();
}
else if (m_events[i].events & EPOLLIN)//如果是已经连接的用户，并且收到数据，那么进行读入。
{
OnReadEpoll (i);
}

OnWriteEpoll (i);//查看当前的活动连接是否有需要写出的数据。
}
catch (int)
{
PRINTF ("CATCH捕获错误\n");
continue;
}
}
m_bOnTimeChecking = TRUE;
OnTimer ();//进行一些定时的操作，主要就是删除一些短线用户等。
}
其实EPOLL的精华，也就是上述的几段短短的代码，看来时代真的不同了，以前如何接受大量用户连接的问题，现在却被如此轻松的搞定，真是让人不得不感叹，对哪。

总结
Windows完成端口与Linux epoll技术方案是这2个平台上实现异步IO和设计开发一个大容量，具可扩展性的winsock程序指服务程序的很好的选择，本文对这2中技术的实现原理和实际的使用方法做了一个详细的介绍。

xmlns:fx=”http://ns.adobe.com/mxml/2009″
xmlns:mx=”library://ns.adobe.com/flex/halo”
xmlns:s=”library://ns.adobe.com/flex/spark”

1、xmlns:fx=”http://ns.adobe.com/mxml/2009″
        fx命名空间下包含ActionScript顶级元素和内建到MXML编译器里的标签。

        前者ActionScript顶级元素就是指 Object、Number、Boolean以及Array对象等等，在《Adobe Flex 4 Beta Language Reference》的顶级包（Top Level）里可以查看完整的顶级元素。后者内建到MXML编译器里的标签包括<fx:Script>、<fx:Declarations>和<fx:Style>等等，在《Adobe Flex 4 Beta Language Reference》附录（Appendixes）里的“MXML Only Tags”可以查看完整的编译器元素。值得注意的是，这个命名空间并不包含 Halo 和 Spark 组件（Halo是以前版本的组件库，而Spark是Flex 4新出的组件库）。在Flash Builder安装目录下可以找到“mxml-2009-manifest.xml”文件（例如我的电脑是C:\Program Files\Adobe\Flash Builder Beta\sdks\4.0.0\frameworks\mxml-2009-manifest.xml），这个xml文件描述了完整的 ActionScript顶级类。不过你可以注意到，它并没有包含MXML编译器标签，那是因为这些标签是内建到MXML编译器。

2、xmlns:mx=”library://ns.adobe.com/flex/halo”
        mx命名空间包含着放在 mx.* 包里那些组件，Flex图表、Flex数据可视化组件等等。对Flex 3很熟悉的话，mx包里的组件你也不陌生了。在Flex 4 SDK的安装目录下可以找到“halo-manifest.xml”文件（例如我的电脑是C:\Program Files\Adobe\Flash Builder Beta\sdks\4.0.0\frameworks\halo-manifest.xml），这个XML文件列出了所有组件了。

3、xmlns:s=”library://ns.adobe.com/flex/spark”
        s命名空间可真是新鲜事了，spark.* 包里的组件都在这个命名空间里，不只spark包，flashx.*包的text framework类也在这个命名空间里。这个命名空间包含不少RPC类，例如 WebService、HTTPService和RemoteObject组件，这些组件同时也在mx命名空间下，也就是说，创建这些组件时，你不但可以使用“S:”前缀，也可以使用“mx:”前缀。其实不只这些RPC组件共用两个命名空间，像graphics、effect和state类也是共用 s 和 mx 命名空间的。在Flex 4 SDK安装目录下打开spark-manifest.xml文件来看看完整的spark组件吧。

用了一年多Flex，感触多多。偶尔有同行的朋友问我啥是Flex，说实话，一时半会儿我还真说不清楚。尤其是对于一个从未接触过Flex的朋友，想要由浅入深地只用嘴巴不用电脑给他讲明白，这确实难为一个整天只跟机器打交道的程序员了。后来我想了一个办法，我说你知道开心农场吧，那就是拿Flex做的。这下子很多人有兴趣了，呵呵，如果你也有兴趣，请继续往下看。失言未察之处，欢迎拍砖。

一般来说，一项技术的产生都是为了解决业界的重大难题而出现的。那么说到Flex我们就不得不先说一下RIA。RIA这个概念其实早就出现了，我最初是07年在《程序员》杂志上关于Ajax技术的介绍时看到的。到了08年，伴随着网络视频的飞速发展，RIA应用已经搞得有声有色热火朝天了，其实翻译过来就是个富客户端（Rich Internet Application），相较于BS的瘦客户端，也可以称之为胖客户端。当然如果你已经被这些名词概念熏得焦头烂额，请连跳四段（小黑好心提示，本部分仅余四段。。。）。

RIA简单的说，就是CS+BS的开发部署模式。CS和BS大家都很熟悉，CS的全拼是Client/Server，它的优点在于借助局域网的信息安全和带宽优势，充分利用客户机器的运算能力从而降低服务器压力，缺点就是安装部署更新麻烦，比如老板让我跑到一千公里外的客户那安装一千台机器的客户端，过几天我回来了，老板说那边有几台机器运行有问题，你去维护一下~！过几个月，老板说你去把那一千台机器全部升级一遍，他们自己不会装。。。呵呵，这些痛苦我当然不曾经历，我杜撰的。

那么在1998年，互联网风起云涌的时候，BS，Browser/Server，逢时而生。BS充分利用互联网的优势，解决了CS安装部署更新的一大难题。通过把业务逻辑处理放在服务器端，然后解析为HTML，利用HTTP协议传输到客户的浏览器上就万事大吉。看起来很美，其实干过就知道也很痛苦。哪儿痛呢，痛的当然是我们这些开发者。安装部署更新倒是省事儿了，装个IE，给个网址就能让客户登录了。但是，基于HTML+JavaScript的技术让人很崩溃。JavaScript我好久不用了，在以前毕业实习的时候，感觉开发和调试都不方便，而且还面临着不同浏览器不兼容的噩梦（据说现在上述问题随着Ajax的风行有所改善，我不太了解）。另外，BS还有一些潜在的缺点。比如，客户端体验简单，不易开发丰富的效果来展示数据（这和当时的网络带宽也有关系）；必须联网才能运行，信息安全无法保障；应用程序需要通过其他技术辅助才能操作客户端资源；服务器负载过高而客户机运算能力未充分使用等。

综合来讲，BS仍然是一个不错的解决方案，它的Web应用程序和CS的桌面应用程序曾一度二分天下，各领风骚数十年。从解耦角度来看，CS以数据库的方式把数据从程序中分离，BS以浏览器页面的方式把界面和逻辑再次分离，然而第二次分离是不彻底的。表面上只是代码结构的分离，从实质上看表现层仍然是逻辑层的附庸，前台UI完全和后台实现技术绑死（把已有项目后台从C#换成JAVA是不可能的。。。）为了解决这个问题，RIA出现了（顺便搞定了一些其他问题，比如页面异步刷新，前台UI不够丰富等等），RIA基本实现了不依赖于特定后台技术，能与多种服务端搭配使用。

在2002年，MacroMedia公司（简称MM，05年被Adobe收购）首先在Flash Player6中引入了RIA概念。2004年，MM正式发布Flex1.0（汗，终于说到Flex了），随着Ajax的火爆，RIA开始受到广泛关注。RIA主要有两个方面的含义，一是用户界面的丰富即富客户端，二是数据模型的智能，服务器已经变成了支持客户端正常运行的数据服务，并提供了异步数据传输和脱机缓存机制等复杂的数据处理能力。前面提到，RIA本质上就是CS+BS，它想集大成，想搞总结，想终结CS和BS二分天下的局面。说浅显点就是，如果以前的CS程序现在能在网络上运行，并且保持了原来的功能和特征，那么这就是一个RIA。关于RIA的详细介绍GOOGLE上一搜一大把，在此就不继续作详细展开。回到当下，RIA各种技术一番拼杀，现在广为人知的只剩下四个NB小伙：Ajax、Flex、SilverLight、JavaFx。在本文第二部分中，我将简要介绍一下Flex（貌似进度有点儿慢，多谢支持。。。）

Flex是咋回事之二 前世今生 

先说一下Flash Player（简称FP）。经常上网的朋友一定遇到过Flash Player版本升级的提示吧，这东西其实就是浏览器插件，据说已经有了98%的安装普及率，没办法，谁让咱们这么爱看视频呢（FP具体介绍请见http://baike.baidu.com/view/1585492.htm）。Flex生成的页面主要是通过Html包装一下生成的swf文件，和Flash生成的swf一样，它也靠FP才能完美运行，这有点类似JVM虚拟机和.NET FRAMEWORK（FP里内嵌了AVM虚拟机）。FP又分调试版和产品版，总体来讲，咱们只管用FP提供的API，以及及时关注最新版本的功能，其余不会过多接触（我对FP10关于3D方面的支持很感兴趣，不过貌似其支持效果不太理想）。

再说一下Flash的历史。在1996年,小软件公司FutureWave Software为了给Netscape开发一个全新的网页浏览插件，创建了名为Future Splash Animator的动态小程序，该产品基于Java，是由一个称为SmartSketch的产品演化而来，这就是Flash的老祖了。具有讽刺意味的是，这家FutureWave的公司本来是打算把这项技术卖给Adobe的，但在那个时候Adobe根本不睬它。而Macromedia（简称MM）却很有兴趣，就这样在1996年11月,MM在拥有了FutureWave这家公司的技术后，把FutureSplash重新命名为Flash Player 1.0。在随后的许多年间，Flash被打包为Studio套件的一部分，并与其他Studio产品（如Dreamweaver和Fireworks）一起发布，世人称网页三剑客。。。三剑客横行无敌，到了05年4月18日这天，ADOBE实在看不下去了，阔绰出手，又以34亿美元天价收购MM。。。ADOBE大叔估计很后悔当年没收购Future Splash，搞到现在，被MM给做大了（Flash具体历史介绍参见http://flash.9ria.com/viewthread.php?tid=13194和http://space.flash8.net/space/?625743/viewspace-350122）

如同今年4月Oracle收购Sun一样，MM嫁入ADOBE豪门，在当时的业界也是一片哗然炸雷。许多MM的忠实粉丝觉得，那三剑客就是被ADOBE大叔招安了啊，依据其收购产品的一贯猥琐恶行，这几位剑侠估计很快就会被不声不响地给整掉了（当时Flex还是襁褓，大家都没注意到。。。）Fireworks是PhotoShop的老对头了，肯定是斩立决；Dreamweaver要不就是改装变身，要不就是各种理由直接缓死；Flash日子会好过些，但其一贯的MM风格是否能延续也很难保证。

然而ADOBE这次出乎意料的善良，三剑客无一遗弃，相反还忍痛把自己推行多年的SVG死缓（个人也很喜欢SVG，无奈和FLASH冲突，出于商业策略，这孩子被牺牲了）。在最新的CS4（Creative Suite 4）产品系列中，三剑客依然活力四射地与其他成员工具们和谐奋进。那么事隔收购事件四年多之后，我们已经渐渐接受了MM产品前面强行加上的ADOBE标签。可以说，ADOBE充分吸纳整合了MM的精神和风格，无论是FP还是三剑客，ADOBE一直都在努力地做得更好更和谐。（本人现在已经是ADOBE FANS了，哈哈，不过还是挺怀念Flash MX2004 和Dreamweaver2004那个时代的，尽管当时也没闪出啥东西来。。。）

说了这么多关于Flash的事情，其实是因为Flash比Flex更出名，ADOBE也察觉到这一点，所以在预备推出FLEX4时，又将其更名为Flash，只是SDK仍然沿用FLEX的名号。FLEX和FLASH并没有本质区别，它们最终都是转为ActionScript源文件，然后被编译为二进制的swf文件（就和JAVA文件被编译成class一样），再交由FP（FP就像JVM虚拟机一样）来执行。不同的是，FLASH更偏向于设计人员，它有时间轴和帧的概念，能更好地实现动画、特效、短片等美工效果。Flex是面向开发者的，隐藏了时间轴的概念（只有两帧），更专注于解决企业应用的表现层方案，提供了大量的通用组件用于构建前端页面、通过数据服务技术能更好的分离界面和逻辑业务层。

从04年3月MM手中的Flex1.0，到05年10月ADOBE手中的Flex2.0，再到07年1月伴随着强大的面向对象语言ActionScript3出现的Flex3.0,再到明年初发布的强力Flex4.0。借着RIA的春风，Flex在不断走向成熟的同时，也被更多的业界开发者和企业用户所关注接受。如果看到这里你很感兴趣，推荐在GOOGLE上搜索一把，现在不是08年了，网上已经涌现出大量的简易教程供我们参考学习。当然如果你有些闲钱，或是想系统地学习一下，也可以买几本书。（有时间我会整理些网站博客和书籍推荐的）

在本文第三部分中，我将结合项目经验谈一下Flex的优缺点和使用心得。没用过Flex的可能无法共鸣吧，那就直接跳过不看了，呵呵

Flex是咋回事之三　谁用谁知道

一项技术，从概念提出到技术研发到商业发布，再到实际应用，最终将产品呈现在用户面前，这是一个漫长而复杂的过程。在这当中，很多有创意有生命力的技术因为各种原因小小遗憾地不幸夭折了。Flex能走到今天确实不易，下面让我们从不同的角度来看一下它是如何过关斩将，赢得众多青睐的。

技术角度：

（１）具备了RIA时代富客户端的优点（C/S+B/S）

（２）支持多种服务器语言（JAVA、.NET、PHP）及主流框架（Spring、Hibernate）

（３）与Java结合后相当强大，能充分利用Java的资源背景

（４）拥有丰富的组件和第三方组件，对企业级的数据汇总和业务流程展现力较强悍

（５）借助开源的力量，拥有众多民间组织和牛人支持

（６）Adobe公司（还有MM多年积累）的强大背景

（７）源于Flash的天生丽质，轻松使用多媒体资源，动态交互性强

（８）借助FlashPlayer的安装普及度，轻松实现跨浏览器跨平台

（９）良好的架构设计和制作精良的文档示例（明年FLEX４同步推出中文版）

（１０）借助于插件丰富的Eclipse开发平台并拥有独立的IDE

（１１）框架设计重用性高，有利于模块化设计

（１２）近几年发展态势良好，获得了广泛认可，产品和技术也越发成熟

开发者角度：

（１）开源，透明（国人没有不喜欢开源的，哈哈）

（２）基于Eclipse开发平台，易上手，且插件丰富（巨人的肩膀啊~）

（３）基于Eclipse平台，开发调试方便(FB4中的条件断点）

（４）ActionScript语言与Java的融合度和相似度较高，易学易用

（５）MXML标签与XML相似，逻辑清晰可读性强

（６）架构设计良好，耦合度低，有利于组件重用

（７）无需针对不同浏览器编写代码，摆脱编写和调试的噩梦（针对JS说的）

（８）类似VB的可视化拖拽组件，快速创建界面

（９）方便定制及使用第三方的皮肤和样式，无需美工也有好效果

（１０）支持多媒体资源，轻易开发动态交互性强的界面

（１１）众多的RPC组件保障对后台数据访问的安全性和效率

（１２）文档示例丰富，通过网络可以获取大量的学习资源

（１３）近两年发展态势良好，前景光明

企业角度：

（１）开源，免费（其实很多时候还是直接用破解的。。。）

（２）具备了RIA时代富客户端的优点（C/S+B/S）（潮流啊~！）

（３）项目和组件的重用性高，易于资源积累和快速构建

（４）Flex提供了与其他语言的结合，能广泛利用已有的资源

（５）界面华丽，客户认可度高

（６）学习曲线一般，培训成本低

用户角度：

（１）部署和更新方便

（２）界面漂亮，交互性强

（３）安全

说了这么多好话，再来综合说一下缺点。鉴于我着迷于Flex的光环效应，没有看到的缺点还请诸位多多提出。

缺点：

（１）不擅长处理复杂的业务流程，主要还是适合展现（Flex不是万能的）

（２）继承了Flash的诸多优点，却唯独丢掉了Flash的小巧轻盈（减肥是永恒的话题）

（３）目前尚没有比较好的减肥策略，带宽较好时这不是问题（不是一般的卡。。。）

（４）对服务器和客户端的硬件设备都有一定要求（CPU和内存占用很生猛。。。）

（５）运行期内存泄露状况严重，尽管可以通过一定手段改善（这个很崩溃）

（６）对一些较专业的领域涉及较少，需要第三方组件支持（比如地质方面的）

（７）Adobe公司对中国分部的支持不够（感觉宣讲和文档都做得不够）

（８）搜索引擎对swf文件的支持不够（Adobe一直在努力）

（９）与以往浏览习惯不同，比如右键被屏蔽，图片无法保存（可以改善）

鉴于Flex生成的swf文件太肥是其主要缺点（加载慢，运行慢，内存占用多），我就主要从减肥和优化的角度来说一下使用心得。

使用心得：

（１）Flex只是前台展现，需要搭配强大的后台（注意前后台的均衡和优化）

（２）考虑异步加载（比如分步加载外部资源）

（３）界面推荐使用相对布局，合理组合，避免多余嵌套

（４）界面加载图片推荐使用外部加载方式，尽可能多使用矢量图形

（５）规范CSS样式表，尤其注意使用的外部字体大小

（６）使用额外的皮肤和特效时需要综合考虑生成的文件大小和执行效率

（７）适当地考虑延时加载策略，主界面只显示必要的内容

（８）规范编码，提高执行效率，避免内存泄露

（９）使用RSL和Module和其他有效方式努力减肥

（１０）尽可能重写一些继承底层类的组件，执行效率更好

（１１）慎重使用重量级组件（比如DataGrid，AdvancedDataGrid）

原文来自：雨枫技术教程网 http://www.fengfly.com

学习Unix常用的命令,ls,ll,cd,su,mkdir,cp,mv,rm -rf,Vim操作，安装CTags，TList插件。

学习MakeFile文件。

特别注意当前程序需要哪些.h文件，哪些lib文件。需要编译成什么文件。注意编译的路径就好了。

Svn操作。上传，下载，更新。

主要是svn co，下载

svn add 添加文件或者文件夹

svn info 查看信息

svn ci 提交修改

svn up 下载信息。

SecureCRT，putty。

lcd 变更本地路径。put 上传，get 下载。

shell脚本，sed，python

目前我公司开发的Nexus Engine的底层对象序列化使用了TinyXML来读写XML文件。TinyXML有两个不爽的地方，一是它的接口使用FILE*，另外一个是它对 wchar_t不能很好的支持。前阵子看Boost库的更新中多了一个PropertyTree，他在处理XML时用到了另外一个小的库 –RapidXML。既然间接的是Boost库的一部分，所以是值得一试的。于是找到其官方网站（http://rapidxml.sourceforge.net/）研究了一番。一看之下，甚是满意，也推荐给大家看看！

首先就是速度，据它自己宣称比TinyXML快30到60倍，比Xerces DOM快50到100倍！详细的测试比较请见其用户手册（http://rapidxml.sourceforge.net/manual.html）的“4. Performance ”一节。

其次它的设计非常的简洁，只依赖于标准库中的几个基本的类。它的输入输出都是字符串，这样很好，一个库就应该关注自己核心的内容，做尽量少的事情。它的API其实和TinyXML倒是有几分相似，用过TinyXML的人应该很容易上手：

TinyXML主要接口类     RapidXML的主要接口类

下面还是看一个具体的例子来体验一下，下面是TinyXML官方教程中创建XML文档的一段代码：

void build_simple_doc( )
{
// Make xml: <?xml ..><Hello>World</Hello>
TiXmlDocument doc;
TiXmlDeclaration * decl = new TiXmlDeclaration( “1.0″, “”, “” );
TiXmlElement * element = new TiXmlElement( “Hello” );
TiXmlText * text = new TiXmlText( “World” );
element->LinkEndChild( text );
doc.LinkEndChild( decl );
doc.LinkEndChild( element );
doc.SaveFile( “madeByHand.xml” );
}

下面是使用RapidXML实现类似功能的代码：

void build_simple_doc_by_rapidxml()
{
xml_document<> doc;
xml_node<>* decl = doc.allocate_node(node_declaration);
xml_attribute<>* decl_ver =
doc.allocate_attribute(“version”, “1.0″);
decl->append_attribute(decl_ver);
doc.append_node(decl);

xml_node<>* node =
doc.allocate_node(node_element,    “Hello”, “World”);
doc.append_node(node);

string text;
rapidxml::print(std::back_inserter(text), doc, 0);

// write text to file by yourself
}

下面是使用RapidXML分析XML的样例代码：

void parse_doc_by_rapidxml(char* xml_doc)
{
xml_document<> doc;        // character type defaults to char
doc.parse<0>(xml_doc);  // 0 means default parse flags

xml_node<> *node = doc.first_node(“Hello”);
string node_val = node->value();
}

前两天有朋友问，我的SlimXml有没有和RapidXml对比过效率？我是第一次听说这个库，更不用说对比效率了，于是上他们网站看了下。

好家伙，居然号称比TinyXml快30～60倍，而且是Boost.PropertyTree的默认xml解析器。

于是有点好奇，因为以前也没有特别关心过SlimXml的效率。

于是分别下载了TinyXml-2.6.1和RapidXml-1.13，迅速用vc8建立了两个测试工程，在系统中搜”*.xml”，找到了一个比较合适的测试文件。它足够大（1.5M），utf-8编码并且包含中/英文，有一定层次深度，大约3.3万行。测试文件可以从这里下载

测试对象是三个库从内存字符串解析xml的函数，这样能排除从硬盘上读文件这种不稳定因素的干扰，而且RapidXml貌似只支持从内存里解析

• slim::XmlDocument::loadFromMemory()
• TiXmlDocument::Parse()
• rapidxml::xml_document<char>::parse<flag>()

要说明的是，RapidXml的这个parse是一个模板函数，必须给一个flag的参数，我测试的时候给的是默认的0

测试结果，解析这个3.3万行，1.5M大小的xml，三个库分别花了

• SlimXml: 22ms
• TinyXml: 54ms
• RapidXml: 4ms!

结论是，RapidXml果然很强悍，居然比我的SlimXml快5倍多。但是并没有如作者所说比TinyXml快30~60倍，只有不到15倍。据说对比用的是一个约50k大小的xml文件，可惜并没有提供下载，不然可以验证一下。

比较欣慰的是，在我并没有很关注效率的情况下，SlimXml仍然比TinyXml快2.5倍。SlimXml走的是简单小巧路线，源代码只有32k，而TinyXml和RapidXml的源码分别是147k和141k，有这样的效率可以满意了。在我有很多空闲以前，估计我也不会再去优化它，因为这个库主要还是针对几十上百行的小文件，解析特别大的xml不在我考虑的范围之内。

以下是RapidXml提供的常见xml库效率对照表，其中还很牛鼻地提供了和strlen()函数的效率对比

我估计RapidXml速度快的主要原因是对memory pool的使用，毕竟在解析过程中需要创建大量的string，可以想象用memory pool和直接走默认的new很容易产生超过一个数量级的效率差异。

首席执行官【CEO】

美国人在20世纪60年代进行公司治理结构改革创新时的产物、它的出现在某种意义上代表着将原来董事会手中一些决策权过渡到经营层手中、CEO概念最早出现在一些网络企业。在那里CEO往往是自封的、也很少有人去研究这一称谓对企业到底意味着什么。但是，当“CEO”在中国叫得越来越响时候、高层人员称谓改变不是一件小事、设立CEO职位不仅仅是对时尚追赶。事实上，CEO做的事情重点在于“执行”。大多数中国公司往往CEO做的事情恰恰不是“执行”，更像是“董事长”。

首席财政官或财务总监【CFO】

现代公司中最重要、最有价值顶尖管理职位之一、掌握着企业神经系统(财务信息)和血液系统(现金资源)灵魂人物。做一名成功CFO需要具备丰富金融理论知识和实务经验。公司理财与金融市场交互、项目估价、风险管理、产品研发、战略规划、企业核心竞争力识别与建立及洞悉信息技术及电子商务对企业冲击等都是CFO职责范围内事。大型公司运作中CFO是穿插在金融市场操作和公司内部财务管理之间角色。担当CFO人才大多是拥有多年在金融市场驰骋经验的人。在美国优秀的CFO常常在华尔街做过成功基金经理人。

首席营运官【COO】

负责公司日常营运、辅助CEO工作。一般来讲COO负责公司职能管理组织体系建设、并代表CEO处理企业日常职能事务。如公司未设有总裁职务则COO还要承担整体业务管理职能、主管企业营销与综合业务拓展、负责建立公司整个销售策略与政策、组织生产经营、协助CEO制定公司业务发展计划、对公司经营绩效进行考核。也有把运营总监称呼为COO的。

首席市场官【CMO】

指市场总监

首席技术官【CTO】

技术总监

销售总监【CSO】

渠道销售总监

公关总监【CPO】

政府事务、媒体、重要公司与人物公共关系，主要是搞定人。

首席信息官【CIO】

大多数公司把这个职位变成了盯人盯票，有点象明朝时候的“东厂”，所以说中国是个很神奇的国家。

开发总监【CDO】

首席发言人【CAO】

专门负责解答媒体、债权人和用户等有关问题询问。

首席商业计划官【CBO】

首席财务官助理之一、专门针对不同投资人制订相应BP。

首席成本控制官【CCO】

凡超过XXXX元以上支出必须由CC0批准。

首席域名官【CDO】

负责公司域名注册、网站清盘时域名拍卖、域名法律纠纷等相关问题。

首席交换官【CEO】

一般由国际CEO自由联盟随时更换、常设短期职能岗位、类似足球教练。

首席方针制订官【CGO】

规划公司宏伟蓝图、一般是5年以后目标。

首席协调官【CHO】

调解投资者和经营者之间的冲突、确保公司内部矛盾不要泄露。

首席检查官【CIO】

检查公司内部工作状况、监督员工工作态度。

首席执法官【CJO】

解决内部劳资纠纷、包括员工对降薪、辞退补偿等所引起问题。

网络连接专员【CKO】

最繁忙的岗位之一、当中国电信网络连接中断时及时向员工通报。

首席律师【CLO】

负责公司被控侵权时应诉以及各种合同文本审核。主要是灭人的打手。

首席媒体官【CMO】

保持和媒体之间友好关[来源：GameRes.com]系为公司随时发布新闻做准备，类似首席代表。

首席新闻官【CNO】

向媒体披露公司被黑、裁员、被收购等重大新闻。一般由公司市场总监担任，类似政府部门新闻发言人，主要由司长级部门领导担任，公司声音的统一出口。

首席隐私官【CPO】

负责公司内部员工Email、ICQ、OICQ等通信内容监控。

数量指标编造专家【CQO】

负责注册用户数量、页面浏览、营业收入等指标编造。

首席裁员官【CRO】

负责与裁员有关事务、直接向股东大会负责、包括董事长在内都不得干预工作。

首席战略官【CSO】

由已经退位公司主要创建人担任，在政府机关一般称为调研员或顾问。

首席联盟官【CUO】

以战略联盟名义专门寻找有收购自己意向的公司。

投资者关系【CVO】

首席财务官另一重要助理。

首席网络写手【CWO】

负责将小事扩大化、通过炒作达到扩大公司名度目的，御用文人，比如给陈天桥，史玉柱编故事，造神。

形象代言人【CXO】

（中国特有）一般由学历不高且没有什么网络知识的年轻人担任。

公司元老【CYO】

荣誉称号授予在公司工作满X年员工（通常空缺）。

【用户数量--注册用户】不同项目注册用户质量完全不同，运营商给出不真实数据，那数据调查报告真实性呢？根本没有明白用户质量的意义。

【在线人数】【最高在线】某个时间能达到的最高在线。

【活跃人数】具有欺骗性的数字，必须是“每日活跃用户”“每周活跃用户”“每月活跃用户”“每季活跃用户”“最近多少天内活跃用户”等。在这段时间内进入游戏的人。

【每个活跃用户平均在线时间】上面说了活跃用户数，如果没有本数据上面那个也没有意义、每个用户都在线2分钟马上就下线，活跃用户价值是多少呢？能和上线就十几个小时在线玩家等值么？

【游戏平均在线人数】
1、24小时内平均在线人数，数据采样时间越密集越精确。

2、不同游戏每个平均在线是由不同数量用户造就的。一个好游戏可以大量粘住玩家长时间舍不得下线。

3、如果活跃用户每次上线平均在线6小时，那么需要4个活跃用户增加1个平均在线，如每次只让用户玩游戏5分钟就走了，哪怕游戏非常好用户每天都上来5分钟，那么必须有60/5*24=288个活跃用户才能达到1个平均在线人数。要根据情况判断推广活跃用户容易，还是增加游戏粘着更容易。

【平均在线、总注册用户、活跃人数及最高在线比例】
曾经有专家说是xxxx是4%，xxxx是8.7%等，他们可能针对某款能接触到的网游数据而来，如果不知道数据是在什么条件下产生的，每款产品都不一样、比例随着不同市场、不同产品、不同渠道、不同服务会导致精确数据和比例完全不一样。哪怕一模一样产品都可能完全不一样数据，别人注册100万用户能有3万在线，不代表你宣传注册100万也有3万。各方面细节太多，资本家很少全面看成功创业者所付出的努力。

【Arpu值定义之争】
1、有人说是每个消费用户的每日花费。
2、有人说是每个活跃用户的每月花费。
3、上市公司财报数据定义：产品毛收益=平APA/arpu，要么增加APA数量，要么增加ARPU。对于运营商要根据多少平均在线确定服务器、带宽、客户服务、需要多少推广成本才能累计平均在线等运营成本。

【收费模式固定值】
很好算：每小时4毛（或点卡定价）*24小时*30天=288元/月，一款百万在线收费网游大致收入是1000000*288，每月2.88亿毛收入（有很多小数字，如免费使用期用户比例导致真实值减少、各种因素导致免费游戏用户比例导致真实收入减少、用户购买点卡很多人没用完导致真实收入增多，渠道压了货最后没有退导致收入增多等）。

【免费制动态arpu值】
1、大多数网游都在学习免费模式，利用收费道具等盈利，arpu值大小关系到生存的重要指标。

2、很多愣头青听见大师宣传免费模式，连免费模式数据都不清楚情况下凭感觉坚定认为免费模式是潮流、趋势。陈天桥不看产品数据，道具收费增加到可替代收费模式，就凭灵光一闪把每季度几亿时间点卡给扔了？看到这两年来盛大从免费模式赚取超过收费模式还是有瑕疵的，至少在线人数没有按盛大想象的大幅度增加。

【收费制】
推广1个收费制游戏在线用户远比推广N个免费游戏在线用户更加困难，免费模式arpu值大于收费模式时，自然免费模式要比收费模式更好。

【推广成本】
1、打算花多少钱宣传推广产品。
2、除了资金还要考虑人力成本和时间成本。
3、仔细计算每个在线用户推广成本，花多少钱才能增加1个平均在线。
4、大部分情况下1个平均在线arpu值低于1个平均在线推广成本。如能找到廉价推广方式增加在线，费用低于用户arpu值，别犹豫赶紧推广吧。

【推广效果】
1、作为市场人员是掌握每种营销方式效果数据。有多少人能看到广告A，有多少目标用户看到广告、引起多少目标用户记住、让多少目标用户感兴趣、多少用户尝试、剩下是产品本身和客户服务的事。对个市场来说撒谎不是缺点、无法让更多用户来尝试产品才是失败。

2、注意以上部分数据，不要轻易相信广告商瞎吹，自己掌握的数据才是最真实不会欺骗你的。

3、精确掌握各种营销方式效果数据，相信你不会随便乱花钱，拍着脑瓜子就上一些性价比不合适的广告。

【市场潜力分级】
不要定义一个遥不可及的市场目标，例如全世界有多少人，每个人都需要住房，而你是个有房地产想法的年轻人，你告诉别人你的市场目标是多少亿亿全球用户的房产。这样目标是没有意义的。可执行的目标是很重要的，只要是可执行哪怕在旁人眼里看起来很狂妄，也没有什么不可以。

【运营网络游戏一定要知道分级】
1. 可以直接推广到的那些人？手把手，或者通过你的个人媒体（言传身教）
2. 能在你所拥有预算内控制哪些媒体，做哪些事情，有多少用户会因为怎样宣传内容而尝试
3. 还有哪些资源，哪些朋友支持，帮助，在你所拥的预算内能帮你打开哪些市场。
4. 人才，能否找到比你更优秀的人才、专家帮助你宣传、推广扩大市场

【用户群分级举例】
1、非常关注你的产品网游用户最可能成为你的用户
2、宣传推广并引起他们注意的网络游戏用户
3、到处寻找新游戏的网络游戏用户
4、同类网络游戏的用户
5、异类网络游戏的用户

【所有人】以上分级不一定准确，不一定适合你，对于你很可能每级需要投入成本不一样，没有史玉柱两个亿就不要开始把目标用户定义为所有人而去打全国广告，否则会发现投入成本一定收不回来。

【目标市场定义】
1、每个人都想产品占领最大最多市场，由各方面条件有限必须按对市场分级，分析目前阶段能覆盖目标市场。

2、近两年很火红海和蓝海概念。

3、准确定位市场、细分市场目的是降低市场推广成本，增加推广有效程度。如果有足够的推广成本，你自然可以多做泛媒体，广大增加知名度，宣传面。

【流失率】很容易被遗忘却异常重要，决定游戏生死重要数据，市场推广好不容易拉的玩家留不留得住。
【初期流失率】尝试用户转变为成熟活跃用户，所需耗费的时间
【自然流失率】成熟活跃用户自然流失率，产品好坏，内涵丰富最大程度决定着自然流失率高低。

1、产品本身有很多问题将会带来非常高自然流失率，产品的画面、操作、各方面细节都是关系到产品品质直接开发因素。

2、很多游戏人都分析《梦幻西游》从技术[来源：GameRes.com]层面完全没有优势产品为何黏着度那么高，流失率那么低。游戏内涵是最重要的因素，这关系到游戏生命周期。如果玩家把所有内容都全部玩到需要5个月，那么5个月就是网络游戏每个用户生命周期，当玩家感觉没有可玩内容时他自然会离开。有的游戏是可以让玩家玩几年还有新内容，有的游戏虽然好但是生命周期短。现在有越来越多游戏学会利用循环任务，或随即生成任务增加生命周期
3、网游开发者不要冲着简单新概念做游戏，不是做噱头，做有内涵的好游戏，充分利用你的技术团队实现效果，而不是盲目专门搞效果搞噱头，让用户乐意留在游戏里面。

【客户服务】很重要作用是减少流失率，没有客户服务游戏将不可避免扩大流失率，流失率大神仙也没得救。盛大第一笔收入用来建立客户服务中心为了什么？商业数据上说就是降低流失率。

【线上活动】通过活动（可能是新任务、策划活动、客服执行活动）临时性增加拉高在线，减缓或阻止短时间内玩家流失。

【用户自然增长率】在推广下增加1个平均在线成本低于【用户arpu值】*【平均每个用户生命周期】。可以不断持续增加用户情况下、新进入玩家大于产品流失率就进入滚雪球效应了。大多数产品一停止大规模推广成本投入流失率都远大于增长率。很多项目在初期炒作后很快用户数量陆续流失，最后不得不倒闭的原因。

【收入潜力值】和arpu值矛盾的值，arpu值越低证明潜力越大，arpu值越高反而说明相同用户数量下收入增长潜力小。有些公司（还没找到盈利模式却有较多用户的网站或游戏）把这个作为他们的未来卖点。

【更多细节数据】做好游戏不仅仅看结果型数据，更多对于开发策划要看过程走向型数据。

【例如】
1、有些数据可以告诉你在推广过程中哪个环节流失用户最多。

2、有些数据可以告诉你、玩家喜欢哪些系统，讨厌什么。无论喜爱还是讨厌都比不过【态度失败】漠不关心、死鸭子嘴硬。玩家对精心策划的内容漠不关心，这是最失败的策划。

3、有些数据可以告诉哪些收费是玩家能够接受的（尽管有些收费内容，玩家可能永远会骂，但每天都有大量用户在付费，有些收费看起来没人骂，实际上根本没有人使用，都要通过运营数据分析）。

4、有些数据可以很清楚告诉你用户在刷钱、在作弊、在利用漏洞、在用外挂、修改封包。如果有自动化数据分析技术几乎可以发现众多玩家作弊。注意只是发现，能否解决还取决于高层重视态度及技术人员能力和速度，要知道而这些问题几乎导致了大量游戏死亡。

5、数据很清楚告诉你游戏经济体制是否稳固，游戏中不断增加的金钱奖励，道具销售是否造成通货膨胀等更多的细节问题。

全部按3DMARK06默认分辨率得分计算.游戏内实际帧数不计算在内(因为NVIDIA和ATI对游戏优化造成得分不公正)排名120后的显卡因时间过长无法测试.只按历年来网上评分排名.(所有排名显卡均为官方公板频率测试).

001 NVIDIA GTX295
002 ATI HD4870X2
003 NVIDIA GTX285
004 ATI HD4850X2
005 NVIDIA GTX280
006 ATI HD4870
007 NVIDIA GTX260
008 ATI HD3870X2
009 ATI HD4850
010 NVIDIA 9800GTX+=NVIDIA GTX250
011 NVIDIA 8800Ultra
012 NVIDIA 8800GTX
013 NVIDIA 9800GTX
014 ATI HD4830
015 NVIDIA 8800GT=NVIDIA 9800GT
016 NVIDIA 8800GTS
017 NVIDIA 8800GS 768M=NVIDIA 9600GSO 768M
018 NVIDIA 9600GT 512
019 NVIDIA 7950GX2
020 ATI HD2900XT
021 ATI HD3870
022 NVIDIA 8800GS 384M=NVIDIA 9600gso 384M
023 ATI X1950XTX
024 NVIDIA 7900GTX
025 ATI HD3850
026 ATI HD4670
027 9600GSO 512M
028 NVIDIA 9600GT 256
029 ATI X1900XTX
030 ATI X1950XT
031 NVIDIA 7950GT    
032 ATI 1900XT
033 ATI HD3690
034 NVIDIA 8600GTS
035 NVIDIA 7900GT
036 ATI X1800XT
037 ATI X1950Pro
038 NVIDIA 7800GTX
039 NVIDIA 7900GS
040 ATI X1950GT
041 ATI X1900GT
042 ATI X1800XL
043 NVIDIA 7800GT
044 ATI X850XT/XTPE
045 ATI HD3670
046 ATI HD4650
047 NVIDIA 9500GT
048 NVIDIA 8600GT
049 ATI HD3650
050 ATI X1800GTO
051 ATI X800XT/XTPE
052 NVIDIA 7600GT    
053 ATI HD2600XT
054 ATI X1650XT
055 NVIDIA 6800Ultra
056 NVIDIA 6800GT
057 NVIDIA 6800GS
058 ATI X800XL
059 ATI X850Pro
060 NVIDIA 6800
061 ATI X1650 Pro
062 ATI X800pro/GTO
063 ATI X1600XT
064 NVIDIA 7600GS
065 ATI X800SE
066 ATI X1300XT
067 NVIDIA 8500GT=NVIDIA 9400GT
068 ATI X1600Pro  
069 NVIDIA 7300GT
070 NVIDIA 6800XT/LE
071 NVIDIA 6600GT
072 ATI X700Pro
073 ATI 9800XT
074 ATI 9800Pro
075 ATI 9700Pro
076 ATI 9800
077 S3 Chrome S27
078 ATI X700
079 NVIDIA 5950Ultra
080 ATI 9700
081 NVIDIA 5900Ultra
082 NVIDIA 5800Ultra
083 NVIDIA 5900
084 NVIDIA 5800
085 ATI X1300Pro
086 NVIDIA 8400GS
087 ATI HD2400Pro
088 NVIDIA 7300GS
089 NVIDIA 6600
090 NVIDIA 5900XT
091 ATI X1300
092 ATI X600XT
093 NVIDIA 7300LE
094 NVIDIA TI4800
095 NVIDIA TI4600
096 ATI 9600XT
097 NVIDIA TI4800SE
098 NVIDIA 5700Ultra
099 ATI 9500 256bit
100 9800SE 128bit
101 ATI X600
102 ATI X550
103 ATI 9600Pro
104 NVIDIA TI4400
105 ATI 9500Pro
106 NVIDIA 6600LE
107 ATI X1300SE
108 NVIDIA 5700
109 ATI 9600
110 NVIDIA 6200
111 NVIDIA TI4200
112 NVIDIA 5600
113 ATI 9550
114 NVIDIA 5600XT
115 ATI 9600SE
116 NVIDIA 5500
117 NVIDIA 7100GS
118 ATI X300
119 ATI 9550SE
120 NVIDIA 6200A
121 ATI 9200Pro
122 ATI 9000Pro
123 ATI 8500Pro
124 NVIDIA GeForce3 TI500
125 ATI 8500
126 ATI 8500LE
127 NVIDIA 5200Ultra
128 ATI 9200
129 ATI 9250
130 NVIDIA GeForce4 MX460
131 NVIDIA 5200
132 ATI 9000
133 ATI 9200SE
134 NVIDIA GeForce3 TI200
135 NVIDIA GeForce3
136 NVIDIA GeForce4 MX 440
137 ATI 7500
138 ATI 7200
139 NVIDIA GeForce2 Ultra
140 ATI 7000
141 NVIDIA GeForce2 GTS
142 NVIDIA GeForce4 MX 420
143 ATI Radeon
144 Voodoo5 5500
145 NVIDIA GeForce2 MX 400
146 NVIDIA GeForce256
147 NVIDIA GeForce2 MX
148 Voodoo4 4500
149 NVIDIA TNT2
150 ATI Rage128 Pro
151 Voodoo3
152 TNT
153 ATI Rage128
154 NVIDIA Riva128
155 ATI Rage3D Pro
156 Voodoo Banshee
157 Voodoo2
158 NVIDIA Riva
159 ATI Rage3D
160 Voodoo