Hi,everyone
  I have enjoyed Scrubyt for days and it worked greatly in most case.However,problems came out when scraped urls from Google and Yahoo at the same time.Here is my code:

require 'rubygems'
require 'scrubyt'

Scrubyt.logger = Scrubyt::Logger.new
query = 'ruby'
google_data = Scrubyt::Extractor.define do
      fetch 'http://www.google.com/ncr'
      fill_textfield 'q', query
      submit
      
      #retrieve by xpath
      title "/html/body/div/div/div/a" do
        url "href", :type => :attribute
      end
    end #end of extrator
 google_file = File.open("google.xml", "w")
 google_data.to_xml.write(google_file, 1)
 google_file.close
 
 yahoo_data = Scrubyt::Extractor.define do
      fetch 'http://search.yahoo.com'
      fill_textfield 'p', query
      submit
      
       #retrieve by xpath
      title "/html/body/div/div/div/div/div/div/div/ol/li/div/h3/a" do
        url "href", :type => :attribute
      end
 end #end of extrator
   
 yahoo_file = File.open("yahoo.xml", "w")
 yahoo_data.to_xml.write(yahoo_file, 1)
 yahoo_file.close

Running Environment: Ubuntu 7.04 + Netbeans 6.0 + Scrubyt

google.xml

<root>
    <title>
      <url>http://www.ruby-lang.org/</url>
    </title>
    <title>
      <url>http://www.ruby-lang.org/en/20020101.html</url>
    </title>
    ...
<root>

yahoo.xml

<root>
    <title>
      <url>http://rds.yahoo.com/_ylt=A0oGklhqbodHe08AchtXNyoA;_ylu=X3oDMTE5MXY5dDllBHNlYwNzcgRwb3MDMQRjb2xvA3NrMQR2dGlkA1lTMTk4XzgyBGwDV1Mx/SIG=11ff2e34s/EXP=1200144362/**http%3a//www.ruby-lang.org/en</url>
    </title>
    <title>
      <url>http://rds.yahoo.com/_ylt=A0oGklhqbodHe08AdBtXNyoA;_ylu=X3oDMTE5cHJpN25qBHNlYwNzcgRwb3MDMgRjb2xvA3NrMQR2dGlkA1lTMTk4XzgyBGwDV1Mx/SIG=12aq03736/EXP=1200144362/**http%3a//en.wikipedia.org/wiki/Ruby_programming_language</url>
    </title>
       ...
<root>

If switched the order of two extractors,that's define yahoo extractor fitstly,the result changed:

google.xml

<root/>

yahoo.xml

<root>
    <title>
      <url>http://www.ruby-lang.org/en</url>
    </title>
    <title>
      <url>http://en.wikipedia.org/wiki/Ruby_programming_language</url>
    </title>
    .....
<root> 

It seems the latter extractor will be influenced by the former one. Since xpath  I used for Yahoo is longer than Google, the result form Google is empty when defined Yahoo extractor firstly. 
  Why is that and how can I overcome this problem? Thanks in advance.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

    现在Eclipse的调试功能相当的强大，Breakpoint，Step Over & Step Into相结合就可以很方便地跟踪代码的执行流程，但有时候要跟踪JDK提供的类的时，却会遇到两个问题：
    1、JDK自带的src.zip里源代码并不完整，不能查看相关类的源文件（当然，喜欢的话可以反编译）。譬如，以sun.开头的包就不包含在src.zip这个压缩包中。
    解决办法：下载完整的源文件包，调试时附加给Debugger 即可。

     2、默认的 rt.jar没有行号信息，虽然有源代码，但是不能设置断点。
   解决办法：下载Debug版的JDK，安装以后将其设置为Eclipse的默认JVM即可。

   JDK源文件很多，类之间关系相当复杂，跟踪过程中往往会迷失在源码的汪洋大海中，这时，设计模式的知识会派上用场，另外，跟踪Java执行的五种方式 也是一份很好的参考。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

  见证一个新事物的诞生，与全世界同步高呼“Hello World”，憧憬未来无限的可能性，这确实让人兴奋。开放，开源，Google，带给了我太多的期待。11.12发布后，这个机器人吸引着全世界人的目光。
   1、说起Android，不能不提OHA。由Google牵头，30多家重量级企业投身其中，China Mobile赫然在列，更是凭着首写字母的优势，荣列联名成员列表的第一名：）Android是个开发的平台，使用的是Apache V2的Licence，也就是说联盟成员可以随意修改，让其成为自己特有的版本，而且需要强制公开。如果中国移动能够在08年推出Android版的移动“心”机的话，对于我们而言最具使用价值的无疑就是打着China Mobile牌子的Android，希望这个机器人在中国能够正常运转啦。

   2、Android宣称内置应用程序使用的API与提供给开发者的API是一致的，两者功能一致。这，很爽。

   3、伴随Android的，还有一个开发大赛，花红高达1000万刀，足以让Android社区的开发人员热血沸腾。我猜大赛的初衷可能是鼓励开发人员积极尝试这个全新的平台，踊跃争当Google的“测试人员”，为正式版本提供反馈和意见。但是“利”字当头，会不会成为大家交流的一道无形的屏障，使大家讨论的时候变得“欲言又止”？这其中利弊在group上也有讨论，个人觉得现在大家在论坛上讨论，应用场景很少提及，这其中应该有开发大赛的因素。

   4、Android由身为网络巨头的Google提出，强大的网络功能自然是其特色所在和立命之根本。Demo视频上也演示了如何利用Google提供的，如Gmail，Map等服务Mashup自己的应用，但是不知道这些应用在我国的网络条件下的用户体验如何。此外，中国移动一直不甘心像电信那样仅仅是信息高速公路的修路人，它对内容和服务同样虎视眈眈。在这场不对称的较量中，与移动如何博弈，将是每一个梦想在Android上有所作为的人必须考虑的问题。说起无限网络，就想起3G，在哪？什么时候？

   5、Android使用Java作为开发语言，但是与JavaME无关。Google在Linux2.6的内核上铺上众多开源代码，再架上一个源于Apache Harmony的Delvik VM，这算是Google在开源上投入热情的回报吧。不过Android上的Java除了在语法上保持一致外，连字节码都保存为.dex文件，不知道这还能不能叫做Java呢？
    既然Delvik下面跑的是Linux，native问题自然就沸沸扬扬的，这也是group上的热点之一，一帮高手也马上拿出了在Android的模拟器上跑C代码的方案。

  6、JavaME虽然被踢出局，但本是同根生，不至于水火不容，有人提出了在Android上跑JavaME的方案。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Delegating Authority - Cocoa Delegation and Notification

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

The C10K problem

原文链接：http://www.kegel.com/c10k.html

It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now.

And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so. Let's see - at 20000 clients, that's 50KHz, 100Kbytes, and 50Kbits/sec per client. It shouldn't take any more horsepower than that to take four kilobytes from the disk and send them to the network once a second for each of twenty thousand clients. (That works out to $0.08 per client, by the way. Those $100/client licensing fees some operating systems charge are starting to look a little heavy!) So hardware is no longer the bottleneck.

In 1999 one of the busiest ftp sites, cdrom.com, actually handled 10000 clients simultaneously through a Gigabit Ethernet pipe. As of 2001, that same speed is now being offered by several ISPs, who expect it to become increasingly popular with large business customers.

And the thin client model of computing appears to be coming back in style -- this time with the server out on the Internet, serving thousands of clients.

With that in mind, here are a few notes on how to configure operating systems and write code to support thousands of clients. The discussion centers around Unix-like operating systems, as that's my personal area of interest, but Windows is also covered a bit.

Contents

• The C10K problem
• Related Sites
• Book to Read First
• I/O frameworks
• I/O Strategies
  1. Serve many clients with each thread, and use nonblocking I/O and level-triggered readiness notification
     • The traditional select()
     • The traditional poll()
     • /dev/poll (Solaris 2.7+)
     • kqueue (FreeBSD, NetBSD)
  2. Serve many clients with each thread, and use nonblocking I/O and readiness change notification
     • epoll (Linux 2.6+)
     • Polyakov's kevent (Linux 2.6+)
     • Drepper's New Network Interface (proposal for Linux 2.6+)
     • Realtime Signals (Linux 2.4+)
     • Signal-per-fd
     • kqueue (FreeBSD, NetBSD)
  3. Serve many clients with each thread, and use asynchronous I/O and completion notification
  4. Serve one client with each server thread
     • LinuxThreads (Linux 2.0+)
     • NGPT (Linux 2.4+)
     • NPTL (Linux 2.6, Red Hat 9)
     • FreeBSD threading support
     • NetBSD threading support
     • Solaris threading support
     • Java threading support in JDK 1.3.x and earlier
     • Note: 1:1 threading vs. M:N threading
  5. Build the server code into the kernel
• Comments
• Limits on open filehandles
• Limits on threads
• Java issues [Updated 27 May 2001]
• Other tips
  • Zero-Copy
  • The sendfile() system call can implement zero-copy networking.
  • Avoid small frames by using writev (or TCP_CORK)
  • Some programs can benefit from using non-Posix threads.
  • Caching your own data can sometimes be a win.
• Other limits
• Kernel Issues
• Measuring Server Performance
• Examples
  • Interesting select()-based servers
  • Interesting /dev/poll-based servers
  • Interesting kqueue()-based servers
  • Interesting realtime signal-based servers
  • Interesting thread-based servers
  • Interesting in-kernel servers
• Other interesting links

Related Sites

Book to Read First

If you haven't read it already, go out and get a copy of Unix Network Programming : Networking Apis: Sockets and Xti (Volume 1) by the late W. Richard Stevens. It describes many of the I/O strategies and pitfalls related to writing high-performance servers. It even talks about the 'thundering herd' problem. And while you're at it, go read Jeff Darcy's notes on high-performance server design.

(Another book which might be more helpful for those who are *using* rather than *writing* a web server is Building Scalable Web Sites by Cal Henderson.)

I/O frameworks

Prepackaged libraries are available that abstract some of the techniques presented below, insulating your code from the operating system and making it more portable.

• ACE, a heavyweight C++ I/O framework, contains object-oriented implementations of some of these I/O strategies and many other useful things. In particular, his Reactor is an OO way of doing nonblocking I/O, and Proactor is an OO way of doing asynchronous I/O.
• ASIO is an C++ I/O framework which is becoming part of the Boost library. It's like ACE updated for the STL era.
• libevent is a lightweight C I/O framework by Niels Provos. It supports kqueue and select, and soon will support poll and epoll. It's level-triggered only, I think, which has both good and bad sides. Niels has a nice graph of time to handle one event as a function of the number of connections. It shows kqueue and sys_epoll as clear winners.
• My own attempts at lightweight frameworks (sadly, not kept up to date):
  • Poller is a lightweight C++ I/O framework that implements a level-triggered readiness API using whatever underlying readiness API you want (poll, select, /dev/poll, kqueue, or sigio). It's useful for benchmarks that compare the performance of the various APIs. This document links to Poller subclasses below to illustrate how each of the readiness APIs can be used.
  • rn is a lightweight C I/O framework that was my second try after Poller. It's lgpl (so it's easier to use in commercial apps) and C (so it's easier to use in non-C++ apps). It was used in some commercial products.
• Matt Welsh wrote a paper in April 2000 about how to balance the use of worker thread and event-driven techniques when building scalable servers. The paper describes part of his Sandstorm I/O framework.
• Cory Nelson's Scale! library - an async socket, file, and pipe I/O library for Windows

I/O Strategies

• Whether and how to issue multiple I/O calls from a single thread
  • Don't; use blocking/synchronous calls throughout, and possibly use multiple threads or processes to achieve concurrency
  • Use nonblocking calls (e.g. write() on a socket set to O_NONBLOCK) to start I/O, and readiness notification (e.g. poll() or /dev/poll) to know when it's OK to start the next I/O on that channel. Generally only usable with network I/O, not disk I/O.
  • Use asynchronous calls (e.g. aio_write()) to start I/O, and completion notification (e.g. signals or completion ports) to know when the I/O finishes. Good for both network and disk I/O.
• How to control the code servicing each client
  • one process for each client (classic Unix approach, used since 1980 or so)
  • one OS-level thread handles many clients; each client is controlled by:
    • a user-level thread (e.g. GNU state threads, classic Java with green threads)
    • a state machine (a bit esoteric, but popular in some circles; my favorite)
    • a continuation (a bit esoteric, but popular in some circles)
  • one OS-level thread for each client (e.g. classic Java with native threads)
  • one OS-level thread for each active client (e.g. Tomcat with apache front end; NT completion ports; thread pools)
• Whether to use standard O/S services, or put some code into the kernel (e.g. in a custom driver, kernel module, or VxD)

The following five combinations seem to be popular:

1. Serve many clients with each thread, and use nonblocking I/O and level-triggered readiness notification
2. Serve many clients with each thread, and use nonblocking I/O and readiness change notification
3. Serve many clients with each server thread, and use asynchronous I/O
4. serve one client with each server thread, and use blocking I/O
5. Build the server code into the kernel

1. Serve many clients with each thread, and use nonblocking I/O and level-triggered readiness notification

... set nonblocking mode on all network handles, and use select() or poll() to tell which network handle has data waiting. This is the traditional favorite. With this scheme, the kernel tells you whether a file descriptor is ready, whether or not you've done anything with that file descriptor since the last time the kernel told you about it. (The name 'level triggered' comes from computer hardware design; it's the opposite of 'edge triggered'. Jonathon Lemon introduced the terms in his BSDCON 2000 paper on kqueue().)

Note: it's particularly important to remember that readiness notification from the kernel is only a hint; the file descriptor might not be ready anymore when you try to read from it. That's why it's important to use nonblocking mode when using readiness notification.

An important bottleneck in this method is that read() or sendfile() from disk blocks if the page is not in core at the moment; setting nonblocking mode on a disk file handle has no effect. Same thing goes for memory-mapped disk files. The first time a server needs disk I/O, its process blocks, all clients must wait, and that raw nonthreaded performance goes to waste.
This is what asynchronous I/O is for, but on systems that lack AIO, worker threads or processes that do the disk I/O can also get around this bottleneck. One approach is to use memory-mapped files, and if mincore() indicates I/O is needed, ask a worker to do the I/O, and continue handling network traffic. Jef Poskanzer mentions that Pai, Druschel, and Zwaenepoel's 1999 Flash web server uses this trick; they gave a talk at Usenix '99 on it. It looks like mincore() is available in BSD-derived Unixes like FreeBSD and Solaris, but is not part of the Single Unix Specification. It's available as part of Linux as of kernel 2.3.51, thanks to Chuck Lever.

But in November 2003 on the freebsd-hackers list, Vivek Pei et al reported very good results using system-wide profiling of their Flash web server to attack bottlenecks. One bottleneck they found was mincore (guess that wasn't such a good idea after all) Another was the fact that sendfile blocks on disk access; they improved performance by introducing a modified sendfile() that return something like EWOULDBLOCK when the disk page it's fetching is not yet in core. (Not sure how you tell the user the page is now resident... seems to me what's really needed here is aio_sendfile().) The end result of their optimizations is a SpecWeb99 score of about 800 on a 1GHZ/1GB FreeBSD box, which is better than anything on file at spec.org.

There are several ways for a single thread to tell which of a set of nonblocking sockets are ready for I/O:

• The traditional select()
  Unfortunately, select() is limited to FD_SETSIZE handles. This limit is compiled in to the standard library and user programs. (Some versions of the C library let you raise this limit at user app compile time.)

  See Poller_select (cc, h) for an example of how to use select() interchangeably with other readiness notification schemes.

   

• The traditional poll()
  There is no hardcoded limit to the number of file descriptors poll() can handle, but it does get slow about a few thousand, since most of the file descriptors are idle at any one time, and scanning through thousands of file descriptors takes time.

  Some OS's (e.g. Solaris 8) speed up poll() et al by use of techniques like poll hinting, which was implemented and benchmarked by Niels Provos for Linux in 1999.

  See Poller_poll (cc, h, benchmarks) for an example of how to use poll() interchangeably with other readiness notification schemes.

   

• /dev/poll
  This is the recommended poll replacement for Solaris.

  The idea behind /dev/poll is to take advantage of the fact that often poll() is called many times with the same arguments. With /dev/poll, you get an open handle to /dev/poll, and tell the OS just once what files you're interested in by writing to that handle; from then on, you just read the set of currently ready file descriptors from that handle.

  It appeared quietly in Solaris 7 (see patchid 106541) but its first public appearance was in Solaris 8; according to Sun, at 750 clients, this has 10% of the overhead of poll().

  Various implementations of /dev/poll were tried on Linux, but none of them perform as well as epoll, and were never really completed. /dev/poll use on Linux is not recommended.

  See Poller_devpoll (cc, h benchmarks ) for an example of how to use /dev/poll interchangeably with many other readiness notification schemes. (Caution - the example is for Linux /dev/poll, might not work right on Solaris.)

   

• kqueue()
  This is the recommended poll replacement for FreeBSD (and, soon, NetBSD).

  See below. kqueue() can specify either edge triggering or level triggering.

2. Serve many clients with each thread, and use nonblocking I/O and readiness change notification

When you use readiness change notification, you must be prepared for spurious events, since one common implementation is to signal readiness whenever any packets are received, regardless of whether the file descriptor was already ready.

This is the opposite of "level-triggered" readiness notification. It's a bit less forgiving of programming mistakes, since if you miss just one event, the connection that event was for gets stuck forever. Nevertheless, I have found that edge-triggered readiness notification made programming nonblocking clients with OpenSSL easier, so it's worth trying.

[Banga, Mogul, Drusha '99] described this kind of scheme in 1999.

There are several APIs which let the application retrieve 'file descriptor became ready' notifications:

• kqueue() This is the recommended edge-triggered poll replacement for FreeBSD (and, soon, NetBSD).

  FreeBSD 4.3 and later, and NetBSD-current as of Oct 2002, support a generalized alternative to poll() called kqueue()/kevent(); it supports both edge-triggering and level-triggering. (See also Jonathan Lemon's page and his BSDCon 2000 paper on kqueue().)

  Like /dev/poll, you allocate a listening object, but rather than opening the file /dev/poll, you call kqueue() to allocate one. To change the events you are listening for, or to get the list of current events, you call kevent() on the descriptor returned by kqueue(). It can listen not just for socket readiness, but also for plain file readiness, signals, and even for I/O completion.

  Note: as of October 2000, the threading library on FreeBSD does not interact well with kqueue(); evidently, when kqueue() blocks, the entire process blocks, not just the calling thread.

  See Poller_kqueue (cc, h, benchmarks) for an example of how to use kqueue() interchangeably with many other readiness notification schemes.

  Examples and libraries using kqueue():

  • PyKQueue -- a Python binding for kqueue()
  • Ronald F. Guilmette's example echo server; see also his 28 Sept 2000 post on freebsd.questions.

   

• epoll
  This is the recommended edge-triggered poll replacement for the 2.6 Linux kernel.

  On 11 July 2001, Davide Libenzi proposed an alternative to realtime signals; his patch provides what he now calls /dev/epoll www.xmailserver.org/linux-patches/nio-improve.html. This is just like the realtime signal readiness notification, but it coalesces redundant events, and has a more efficient scheme for bulk event retrieval.

  Epoll was merged into the 2.5 kernel tree as of 2.5.46 after its interface was changed from a special file in /dev to a system call, sys_epoll. A patch for the older version of epoll is available for the 2.4 kernel.

  There was a lengthy debate about unifying epoll, aio, and other event sources on the linux-kernel mailing list around Halloween 2002. It may yet happen, but Davide is concentrating on firming up epoll in general first.

   

• Polyakov's kevent (Linux 2.6+) News flash: On 9 Feb 2006, and again on 9 July 2006, Evgeniy Polyakov posted patches which seem to unify epoll and aio; his goal is to support network AIO. See:
  • the LWN article about kevent
  • his July announcement
  • his kevent page
  • his naio page
  • some recent discussion

   

• Drepper's New Network Interface (proposal for Linux 2.6+)
  At OLS 2006, Ulrich Drepper proposed a new high-speed asynchronous networking API. See:
  • his paper, "The Need for Asynchronous, Zero-Copy Network I/O"
  • his slides
  • LWN article from July 22

   

• Realtime Signals
  This is the recommended edge-triggered poll replacement for the 2.4 Linux kernel.

  The 2.4 linux kernel can deliver socket readiness events via a particular realtime signal. Here's how to turn this behavior on:

  	/* Mask off SIGIO and the signal you want to use. */
  	sigemptyset(&sigset);
  	sigaddset(&sigset, signum);
  	sigaddset(&sigset, SIGIO);
  	sigprocmask(SIG_BLOCK, &m_sigset, NULL);
  	/* For each file descriptor, invoke F_SETOWN, F_SETSIG, and set O_ASYNC. */
  	fcntl(fd, F_SETOWN, (int) getpid());
  	fcntl(fd, F_SETSIG, signum);
  	flags = fcntl(fd, F_GETFL);
  	flags |= O_NONBLOCK|O_ASYNC;
  	fcntl(fd, F_SETFL, flags);
  	

  This sends that signal when a normal I/O function like read() or write() completes. To use this, write a normal poll() outer loop, and inside it, after you've handled all the fd's noticed by poll(), you loop calling sigwaitinfo().
  If sigwaitinfo or sigtimedwait returns your realtime signal, siginfo.si_fd and siginfo.si_band give almost the same information as pollfd.fd and pollfd.revents would after a call to poll(), so you handle the i/o, and continue calling sigwaitinfo().
  If sigwaitinfo returns a traditional SIGIO, the signal queue overflowed, so you flush the signal queue by temporarily changing the signal handler to SIG_DFL, and break back to the outer poll() loop.
  

  See Poller_sigio (cc, h) for an example of how to use rtsignals interchangeably with many other readiness notification schemes.

  See Zach Brown's phhttpd for example code that uses this feature directly. (Or don't; phhttpd is a bit hard to figure out...)

  [Provos, Lever, and Tweedie 2000] describes a recent benchmark of phhttpd using a variant of sigtimedwait(), sigtimedwait4(), that lets you retrieve multiple signals with one call. Interestingly, the chief benefit of sigtimedwait4() for them seemed to be it allowed the app to gauge system overload (so it could behave appropriately). (Note that poll() provides the same measure of system overload.)

   

• Signal-per-fd
  Chandra and Mosberger proposed a modification to the realtime signal approach called "signal-per-fd" which reduces or eliminates realtime signal queue overflow by coalescing redundant events. It doesn't outperform epoll, though. Their paper ( www.hpl.hp.com/techreports/2000/HPL-2000-174.html) compares performance of this scheme with select() and /dev/poll.
  

  Vitaly Luban announced a patch implementing this scheme on 18 May 2001; his patch lives at www.luban.org/GPL/gpl.html. (Note: as of Sept 2001, there may still be stability problems with this patch under heavy load. dkftpbench at about 4500 users may be able to trigger an oops.)

  See Poller_sigfd (cc, h) for an example of how to use signal-per-fd interchangeably with many other readiness notification schemes.

3. Serve many clients with each server thread, and use asynchronous I/O

This has not yet become popular in Unix, probably because few operating systems support asynchronous I/O, also possibly because it (like nonblocking I/O) requires rethinking your application. Under standard Unix, asynchronous I/O is provided by the aio_ interface (scroll down from that link to "Asynchronous input and output"), which associates a signal and value with each I/O operation. Signals and their values are queued and delivered efficiently to the user process. This is from the POSIX 1003.1b realtime extensions, and is also in the Single Unix Specification, version 2.

AIO is normally used with edge-triggered completion notification, i.e. a signal is queued when the operation is complete. (It can also be used with level triggered completion notification by calling aio_suspend(), though I suspect few people do this.)

glibc 2.1 and later provide a generic implementation written for standards compliance rather than performance.

Ben LaHaise's implementation for Linux AIO was merged into the main Linux kernel as of 2.5.32. It doesn't use kernel threads, and has a very efficient underlying api, but (as of 2.6.0-test2) doesn't yet support sockets. (There is also an AIO patch for the 2.4 kernels, but the 2.5/2.6 implementation is somewhat different.) More info:

• The page "Kernel Asynchronous I/O (AIO) Support for Linux" which tries to tie together all info about the 2.6 kernel's implementation of AIO (posted 16 Sept 2003)
• Round 3: aio vs /dev/epoll by Benjamin C.R. LaHaise (presented at 2002 OLS)
• Asynchronous I/O Suport in Linux 2.5, by Bhattacharya, Pratt, Pulaverty, and Morgan, IBM; presented at OLS '2003
• Design Notes on Asynchronous I/O (aio) for Linux by Suparna Bhattacharya -- compares Ben's AIO with SGI's KAIO and a few other AIO projects
• Linux AIO home page - Ben's preliminary patches, mailing list, etc.
• linux-aio mailing list archives
• libaio-oracle - library implementing standard Posix AIO on top of libaio. First mentioned by Joel Becker on 18 Apr 2003.

Red Hat AS and Suse SLES both provide a high-performance implementation on the 2.4 kernel; it is related to, but not completely identical to, the 2.6 kernel implementation.

In February 2006, a new attempt is being made to provide network AIO; see the note above about Evgeniy Polyakov's kevent-based AIO.

In 1999, SGI implemented high-speed AIO for Linux. As of version 1.1, it's said to work well with both disk I/O and sockets. It seems to use kernel threads. It is still useful for people who can't wait for Ben's AIO to support sockets.

The O'Reilly book POSIX.4: Programming for the Real World is said to include a good introduction to aio.

A tutorial for the earlier, nonstandard, aio implementation on Solaris is online at Sunsite. It's probably worth a look, but keep in mind you'll need to mentally convert "aioread" to "aio_read", etc.

Note that AIO doesn't provide a way to open files without blocking for disk I/O; if you care about the sleep caused by opening a disk file, Linus suggests you should simply do the open() in a different thread rather than wishing for an aio_open() system call.

Under Windows, asynchronous I/O is associated with the terms "Overlapped I/O" and IOCP or "I/O Completion Port". Microsoft's IOCP combines techniques from the prior art like asynchronous I/O (like aio_write) and queued completion notification (like when using the aio_sigevent field with aio_write) with a new idea of holding back some requests to try to keep the number of running threads associated with a single IOCP constant. For more information, see Inside I/O Completion Ports by Mark Russinovich at sysinternals.com, Jeffrey Richter's book "Programming Server-Side Applications for Microsoft Windows 2000" (Amazon, MSPress), U.S. patent #06223207, or MSDN.

4. Serve one client with each server thread

... and let read() and write() block. Has the disadvantage of using a whole stack frame for each client, which costs memory. Many OS's also have trouble handling more than a few hundred threads. If each thread gets a 2MB stack (not an uncommon default value), you run out of *virtual memory* at (2^30 / 2^21) = 512 threads on a 32 bit machine with 1GB user-accessible VM (like, say, Linux as normally shipped on x86). You can work around this by giving each thread a smaller stack, but since most thread libraries don't allow growing thread stacks once created, doing this means designing your program to minimize stack use. You can also work around this by moving to a 64 bit processor.

The thread support in Linux, FreeBSD, and Solaris is improving, and 64 bit processors are just around the corner even for mainstream users. Perhaps in the not-too-distant future, those who prefer using one thread per client will be able to use that paradigm even for 10000 clients. Nevertheless, at the current time, if you actually want to support that many clients, you're probably better off using some other paradigm.

For an unabashedly pro-thread viewpoint, see Why Events Are A Bad Idea (for High-concurrency Servers) by von Behren, Condit, and Brewer, UCB, presented at HotOS IX. Anyone from the anti-thread camp care to point out a paper that rebuts this one? :-)

LinuxThreads

NGPT: Next Generation Posix Threads for Linux

NPTL: Native Posix Thread Library for Linux

As of 5 October 2003, NPTL is now merged into the glibc cvs tree as an add-on directory (just like linuxthreads), so it will almost certainly be released along with the next release of glibc.

The first major distribution to include an early snapshot of NPTL was Red Hat 9. (This was a bit inconvenient for some users, but somebody had to break the ice...)

NPTL links:

• Mailing list for NPTL discussion
• NPTL source code
• Initial announcement for NPTL
• Original whitepaper describing the goals for NPTL
• Revised whitepaper describing the final design of NPTL
• Ingo Molnar's first benchmark showing it could handle 10^6 threads
• Ulrich's benchmark comparing performance of LinuxThreads, NPTL, and IBM's NGPT. It seems to show NPTL is much faster than NGPT.

In March 2002, Bill Abt of the NGPT team, the glibc maintainer Ulrich Drepper, and others met to figure out what to do about LinuxThreads. One idea that came out of the meeting was to improve mutex performance; Rusty Russell et al subsequently implemented fast userspace mutexes (futexes)), which are now used by both NGPT and NPTL. Most of the attendees figured NGPT should be merged into glibc.

Ulrich Drepper, though, didn't like NGPT, and figured he could do better. (For those who have ever tried to contribute a patch to glibc, this may not come as a big surprise :-) Over the next few months, Ulrich Drepper, Ingo Molnar, and others contributed glibc and kernel changes that make up something called the Native Posix Threads Library (NPTL). NPTL uses all the kernel enhancements designed for NGPT, and takes advantage of a few new ones. Ingo Molnar described the kernel enhancements as follows:

While NPTL uses the three kernel features introduced by NGPT: getpid() returns PID, CLONE_THREAD and futexes; NPTL also uses (and relies on) a much wider set of new kernel features, developed as part of this project.

Some of the items NGPT introduced into the kernel around 2.5.8 got modified, cleaned up and extended, such as thread group handling (CLONE_THREAD). [the CLONE_THREAD changes which impacted NGPT's compatibility got synced with the NGPT folks, to make sure NGPT does not break in any unacceptable way.]

The kernel features developed for and used by NPTL are described in the design whitepaper, http://people.redhat.com/drepper/nptl-design.pdf ...

A short list: TLS support, various clone extensions (CLONE_SETTLS, CLONE_SETTID, CLONE_CLEARTID), POSIX thread-signal handling, sys_exit() extension (release TID futex upon VM-release), the sys_exit_group() system-call, sys_execve() enhancements and support for detached threads.

There was also work put into extending the PID space - eg. procfs crashed due to 64K PID assumptions, max_pid, and pid allocation scalability work. Plus a number of performance-only improvements were done as well.

In essence the new features are a no-compromises approach to 1:1 threading - the kernel now helps in everything where it can improve threading, and we precisely do the minimally necessary set of context switches and kernel calls for every basic threading primitive.

FreeBSD threading support

On 25 Mar 2003, Jeff Roberson posted on freebsd-arch:

... Thanks to the foundation provided by Julian, David Xu, Mini, Dan Eischen, and everyone else who has participated with KSE and libpthread development Mini and I have developed a 1:1 threading implementation. This code works in parallel with KSE and does not break it in any way. It actually helps bring M:N threading closer by testing out shared bits. ...

I know this has been discussed in the past, but I figured with 7.x trundling forward, it was time to think about it again. In benchmarks for many common applications and scenarios, libthr demonstrates significantly better performance over libpthread... libthr is also implemented across a larger number of our platforms, and is already libpthread on several. The first recommendation we make to MySQL and other heavy thread users is "Switch to libthr", which is suggestive, also! ... So the strawman proposal is: make libthr the default threading library on 7.x.

NetBSD threading support

Kernel supported M:N thread library based on the Scheduler Activations model is merged into NetBSD-current on Jan 18 2003.

Solaris threading support

Java threading support in JDK 1.3.x and earlier

Note: 1:1 threading vs. M:N threading

• Why Ingo Molnar prefers 1:1 over M:N
• Sun is moving to 1:1 threads
• NGPT is an M:N threading library for Linux.
• Although Ulrich Drepper planned to use M:N threads in the new glibc threading library, he has since switched to the 1:1 threading model.
• MacOSX appears to use 1:1 threading.
• FreeBSD and NetBSD appear to still believe in M:N threading... The lone holdouts? Looks like freebsd 7.0 might switch to 1:1 threading (see above), so perhaps M:N threading's believers have finally been proven wrong everywhere.

5. Build the server code into the kernel

Novell and Microsoft are both said to have done this at various times, at least one NFS implementation does this, khttpd does this for Linux and static web pages, and "TUX" (Threaded linUX webserver) is a blindingly fast and flexible kernel-space HTTP server by Ingo Molnar for Linux. Ingo's September 1, 2000 announcement says an alpha version of TUX can be downloaded from ftp://ftp.redhat.com/pub/redhat/tux, and explains how to join a mailing list for more info.
The linux-kernel list has been discussing the pros and cons of this approach, and the consensus seems to be instead of moving web servers into the kernel, the kernel should have the smallest possible hooks added to improve web server performance. That way, other kinds of servers can benefit. See e.g. Zach Brown's remarks about userland vs. kernel http servers. It appears that the 2.4 linux kernel provides sufficient power to user programs, as the X15 server runs about as fast as Tux, but doesn't use any kernel modifications.

Comments

Richard Gooch has written a paper discussing I/O options.

In 2001, Tim Brecht and MMichal Ostrowski measured various strategies for simple select-based servers. Their data is worth a look.

In 2003, Tim Brecht posted source code for userver, a small web server put together from several servers written by Abhishek Chandra, David Mosberger, David Pariag, and Michal Ostrowski. It can use select(), poll(), epoll(), or sigio.

Back in March 1999, Dean Gaudet posted:

I keep getting asked "why don't you guys use a select/event based model like Zeus? It's clearly the fastest." ...

Mark Russinovich wrote an editorial and an article discussing I/O strategy issues in the 2.2 Linux kernel. Worth reading, even he seems misinformed on some points. In particular, he seems to think that Linux 2.2's asynchronous I/O (see F_SETSIG above) doesn't notify the user process when data is ready, only when new connections arrive. This seems like a bizarre misunderstanding. See also comments on an earlier draft, Ingo Molnar's rebuttal of 30 April 1999, Russinovich's comments of 2 May 1999, a rebuttal from Alan Cox, and various posts to linux-kernel. I suspect he was trying to say that Linux doesn't support asynchronous disk I/O, which used to be true, but now that SGI has implemented KAIO, it's not so true anymore.

See these pages at sysinternals.com and MSDN for information on "completion ports", which he said were unique to NT; in a nutshell, win32's "overlapped I/O" turned out to be too low level to be convenient, and a "completion port" is a wrapper that provides a queue of completion events, plus scheduling magic that tries to keep the number of running threads constant by allowing more threads to pick up completion events if other threads that had picked up completion events from this port are sleeping (perhaps doing blocking I/O).

See also OS/400's support for I/O completion ports.

There was an interesting discussion on linux-kernel in September 1999 titled "> 15,000 Simultaneous Connections" (and the second week of the thread). Highlights:

• Ed Hall posted a few notes on his experiences; he's achieved >1000 connects/second on a UP P2/333 running Solaris. His code used a small pool of threads (1 or 2 per CPU) each managing a large number of clients using "an event-based model".
• Mike Jagdis posted an analysis of poll/select overhead, and said "The current select/poll implementation can be improved significantly, especially in the blocking case, but the overhead will still increase with the number of descriptors because select/poll does not, and cannot, remember what descriptors are interesting. This would be easy to fix with a new API. Suggestions are welcome..."
• Mike posted about his work on improving select() and poll().
• Mike posted a bit about a possible API to replace poll()/select(): "How about a 'device like' API where you write 'pollfd like' structs, the 'device' listens for events and delivers 'pollfd like' structs representing them when you read it? ... "
• Rogier Wolff suggested using "the API that the digital guys suggested", http://www.cs.rice.edu/~gaurav/papers/usenix99.ps
• Joerg Pommnitz pointed out that any new API along these lines should be able to wait for not just file descriptor events, but also signals and maybe SYSV-IPC. Our synchronization primitives should certainly be able to do what Win32's WaitForMultipleObjects can, at least.
• Stephen Tweedie asserted that the combination of F_SETSIG, queued realtime signals, and sigwaitinfo() was a superset of the API proposed in http://www.cs.rice.edu/~gaurav/papers/usenix99.ps. He also mentions that you keep the signal blocked at all times if you're interested in performance; instead of the signal being delivered asynchronously, the process grabs the next one from the queue with sigwaitinfo().
• Jayson Nordwick compared completion ports with the F_SETSIG synchronous event model, and concluded they're pretty similar.
• Alan Cox noted that an older rev of SCT's SIGIO patch is included in 2.3.18ac.
• Jordan Mendelson posted some example code showing how to use F_SETSIG.
• Stephen C. Tweedie continued the comparison of completion ports and F_SETSIG, and noted: "With a signal dequeuing mechanism, your application is going to get signals destined for various library components if libraries are using the same mechanism," but the library can set up its own signal handler, so this shouldn't affect the program (much).
• Doug Royer noted that he'd gotten 100,000 connections on Solaris 2.6 while he was working on the Sun calendar server. Others chimed in with estimates of how much RAM that would require on Linux, and what bottlenecks would be hit.

Interesting reading!

Limits on open filehandles

• Any Unix: the limits set by ulimit or setrlimit.
• Solaris: see the Solaris FAQ, question 3.46 (or thereabouts; they renumber the questions periodically).
• FreeBSD:
  
  Edit /boot/loader.conf, add the line

  	set kern.maxfiles=XXXX
  	

  where XXXX is the desired system limit on file descriptors, and reboot. Thanks to an anonymous reader, who wrote in to say he'd achieved far more than 10000 connections on FreeBSD 4.3, and says

  "FWIW: You can't actually tune the maximum number of connections in FreeBSD trivially, via sysctl.... You have to do it in the /boot/loader.conf file.
  The reason for this is that the zalloci() calls for initializing the sockets and tcpcb structures zones occurs very early in system startup, in order that the zone be both type stable and that it be swappable.
  You will also need to set the number of mbufs much higher, since you will (on an unmodified kernel) chew up one mbuf per connection for tcptempl structures, which are used to implement keepalive."

  Another reader says

  "As of FreeBSD 4.4, the tcptempl structure is no longer allocated; you no longer have to worry about one mbuf being chewed up per connection."

  See also:
  • the FreeBSD handbook
  • SYSCTL TUNING, LOADER TUNABLES, and KERNEL CONFIG TUNING in 'man tuning'
  • The Effects of Tuning a FreeBSD 4.3 Box for High Performance, Daemon News, Aug 2001
  • postfix.org tuning notes, covering FreeBSD 4.2 and 4.4
  • the Measurement Factory's notes, circa FreeBSD 4.3
• OpenBSD: A reader says

  "In OpenBSD, an additional tweak is required to increase the number of open filehandles available per process: the openfiles-cur parameter in /etc/login.conf needs to be increased. You can change kern.maxfiles either with sysctl -w or in sysctl.conf but it has no effect. This matters because as shipped, the login.conf limits are a quite low 64 for nonprivileged processes, 128 for privileged."

• Linux: See Bodo Bauer's /proc documentation. On 2.4 kernels:

  	echo 32768 > /proc/sys/fs/file-max
  	

  increases the system limit on open files, and

  	ulimit -n 32768
  	

  increases the current process' limit.

  On 2.2.x kernels,

  	echo 32768 > /proc/sys/fs/file-max
  	echo 65536 > /proc/sys/fs/inode-max
  	

  increases the system limit on open files, and

  	ulimit -n 32768
  	

  increases the current process' limit.

  I verified that a process on Red Hat 6.0 (2.2.5 or so plus patches) can open at least 31000 file descriptors this way. Another fellow has verified that a process on 2.2.12 can open at least 90000 file descriptors this way (with appropriate limits). The upper bound seems to be available memory.
  Stephen C. Tweedie posted about how to set ulimit limits globally or per-user at boot time using initscript and pam_limit.
  In older 2.2 kernels, though, the number of open files per process is still limited to 1024, even with the above changes.
  See also Oskar's 1998 post, which talks about the per-process and system-wide limits on file descriptors in the 2.0.36 kernel.

Limits on threads

On any architecture, you may need to reduce the amount of stack space allocated for each thread to avoid running out of virtual memory. You can set this at runtime with pthread_attr_init() if you're using pthreads.

• Solaris: it supports as many threads as will fit in memory, I hear.
• Linux 2.6 kernels with NPTL: /proc/sys/vm/max_map_count may need to be increased to go above 32000 or so threads. (You'll need to use very small stack threads to get anywhere near that number of threads, though, unless you're on a 64 bit processor.) See the NPTL mailing list, e.g. the thread with subject "Cannot create more than 32K threads?", for more info.
• Linux 2.4: /proc/sys/kernel/threads-max is the max number of threads; it defaults to 2047 on my Red Hat 8 system. You can set increase this as usual by echoing new values into that file, e.g. "echo 4000 > /proc/sys/kernel/threads-max"
• Linux 2.2: Even the 2.2.13 kernel limits the number of threads, at least on Intel. I don't know what the limits are on other architec

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

  SaaS( Software as a Service)模式现在是越来越普遍了。对于软件供应商来说，软件可以集中管理，升级维护方便，省心省力，而且以互联网为分发渠道，采取 muti-tenant能很好地发掘潜在客户（各个中小客户），发挥长尾效应的威力，赢取最大的经济效益；对于客户而言，省去了维护专有系统的的人力和经济花销，而且SaaS采用的 pay as you go模式能极大减少中小客户的资金压力，相当有说服力。
   说起SaaS，大家都会不约而同地提到ASP(Application Service Provider,这里不是MS的Active Server Page:) )。对我而言，ASP完全是一个陌生人，查了一下资料才知道这哥们是上世纪90年代的红人，可惜现在风光不再，相关新闻都是跟到SaaS后面当反面例子，而且用得最多的形容词也是惨不忍睹的totally completely failed。。ASP看上去跟SaaS很像，两者都是通过Browser 进行操作，通过网络隔离用用户和软件供应商；同样是把应用软件交给第三方进行托管等。自然，人们也就担心SaaS是否会重覆ASP的倒辙，落下个一地鸡毛的下场。
  但是，SaaS在这几年迅速上位，自然有其过人之处。可以先看看SaaS跟ASP之间的区别【form wiki】：
     1. ASP applications are traditional single-tenant applications but hosted by a third party. They are client-server applications with HTML front ends added to allow remote access to the application.
    2. The applications are hosted by third-parties who ordinarily do not have specific application expertise.
    3. The applications are not written as net-native applications. As a result, the performance may be poor and application updates are no better than self-managed premise-base applications.
   
   此外，随着网络带宽的增加，网络技术的发展（如Ajax），用户的使用体验必定大为增强，这也是SaaS可以繁盛起来的重要原因。

有兴趣的可以看看下面两篇文章：
1、 SOFTWARE AS A SERVICE A Comprehensive Look at the Total Cost of Ownership of Software Applications
2、Architecture Strategies for Catching the Long Tail
      SAAS的三个关键属性：可伸缩性（scalabe），可配置性（configurable）以及面向多用户特性（multi-tenant-efficient），根据这三个特性可以把SAAS的成熟度划分为四种，而ASP可以划分到成熟度1这个层次。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

   Hype Cycle是对技术的成熟度，大众接受度和商业应用程度的一个图形化表示。Gartner.com从95年开始每年对相关技术发表相应的Hype Cycle，对当年的各种技术进行评估。通过Hype Cycle，我们可以估计某个技术什么时候会走出所谓“盲目的狂热期”，最终走向成熟，为大众所接受。横坐标表示技术的成熟度，纵轴表示技术受关注的程度.影响最大的Hype Cycle无疑是99年由Alex Drobik 提出的E-Business-Hype Cycle ，因为它准确地预测到了2000年春天dot-com 泡沫的破灭。

 1. "Technology Trigger"
The first phase of a Hype Cycle is the "technology trigger" or breakthrough, product launch or other event that generates significant press and interest.

2. "Peak of Inflated Expectations"
In the next phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.

3. "Trough of Disillusionment"
Technologies enter the "trough of disillusionment" because they fail to meet expectations and quickly become unfashionable. Consequently, the press usually abandons the topic and the technology.

4. "Slope of Enlightenment"
Although the press may have stopped covering the technology, some businesses continue through the "slope of enlightenment" and experiment to understand the benefits and practical application of the technology.

5. "Plateau of Productivity"
A technology reaches the "plateau of productivity" as the benefits of it become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations. The final height of the plateau varies according to whether the technology is broadly applicable or benefits only a niche market. 

可以看看2005年Gartner发布的Hype Cycle。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

How to Ride the Fifth Wave

    (Business 2.0) – Rick Rashid makes his living staring off into the distance. He's head of Microsoft Research, the software giant's R&D arm, and it's his job to peer far over the horizon to divine where technology is headed. He ponders out-there issues like what each of us could do if there was enough computer storage to save every conversation we have from birth to death, or what happens when giant LCD panels become as cheap as today's whiteboards. Which makes it slightly incongruous that, at the moment, he's sitting in a Victorian-era hotel talking about steam engines. The setting is San Diego's Hotel del Coronado, built in 1888, and Rashid is explaining how a blast from the past has given him a new notion of the future. On a recent vacation to London, Rashid visited Britain's Science Museum. He lingered before an exhibit of one of James Watt's earliest steam engines and others that followed in various sizes and configurations. It occurred to Rashid that in the 19th century, the answer for every engineering problem was a steam engine. If it was a big problem, it was solved with a big steam engine. Small problem? A small steam engine sufficed. Steam engines were everywhere. The technological muscle they provided sent Britain and ultimately the rest of the world chuffing into the industrial age.

Then it hit him: "I realized that we are coming into a stage now where our version of the steam engine is the microprocessor and software," Rashid says. "We are getting to a point where it is truly cheap and easy enough to put a combination of processors and software into anything, for any reason."

Rashid is on to something. We are now in the initial stages of a technological shift that may someday merit its own proud place in the museum. Roughly speaking, the history of computing has unrolled in four major waves. The first came in the 1960s, as mainframe computers advanced into the corporate world and became essential business tools. The 1970s saw the wide adoption of the minicomputer. Then came the personal computer in the '80s, followed in the '90s by networking and the Internet, and the spread of distributed computing. Each successive wave of technology brought with it giant leaps in productivity and huge increases in spending. Each transition lifted some companies (think IBM, Microsoft, Yahoo, Google) and swamped those that couldn't adapt (think Wang and Digital Equipment).

Now comes computing's fifth wave. It's different from the sea changes that came before it. For the first time, the shift isn't driven primarily by a single piece of hardware or by how corporations deploy it. Instead, it results from the unprecedented coalescence of three powerful technological forces: cheap and ubiquitous computing devices, from PCs to cell phones to tiny but potent systems that are beginning to show up in everything from bedroom lamps to key chains; low-cost and omnipresent bandwidth; and open standards—not just Linux source code but the opening of other software as well as corporate databases. The fifth wave puts computing everywhere. It offers access to limitless amounts of information, services, and entertainment. All the time. Everywhere.

Best of all, the fifth wave serves as a framework to understand where most of the juiciest opportunities in business are emerging today. It will coincide with, and in some ways fuel, a surprising increase in corporate IT spending. And as the new wave sweeps in, it will create fertile conditions for starting new companies—even new industries—and remaking old ones. It won't always be smooth sailing. "It's not going to be this linear progress that we've seen so far," says Dick Lampman, head of Hewlett-Packard's research labs. "It's this perfect storm of technology rolling in, and it presents thousands of new opportunities to develop devices and services." For anyone who has ever dreamed of building a game-changing, money-gushing new enterprise, the message is unmistakable: Surf's up. And if you catch it right, the fifth wave could be a mind-blowing ride.

All big technological leaps build on the advances that came before them. Watt's steam engine, for instance, was based on a coal-mining pump designed by the now largely forgotten 18th-century inventor Thomas Newcomen; ultimately it was the combination of the steam engine and that classic of early invention, the wheel, that revolutionized transportation and brought us the industrial age. In the case of the fifth wave, the springboards are a set of familiar but, historically speaking, relatively new technologies that now have matured enough and found a large enough audience to create a wholly new tech terrain.

The Web, of course, is fundamental. In addition, relentless com-modification has driven the cost of computer hardware, and storage in particular, to relative peanuts. Cheap mobile phones and other handhelds now pack as much computing power as workstations did five years ago. More important for the fifth wave, broadband is practically everywhere, and it's blindingly fast. Today's local area networks move data at a gigabit per second. That's a full-length DVD-quality movie every 38 seconds. Wireless technologies, chiefly 3G (third-generation) and Wi-Fi, are expanding rapidly, making the Internet ubiquitous.

A less understood but equally critical development is the spread of technological openness. The open-source movement has created a global tinkerer's workshop, where thousands of creative minds are constantly cobbling together code that entrepreneurs and even established businesses can cannibalize, free of charge, for parts to build new software systems. But fifth-wave pioneers grasp another dimension of technological openness: Many have begun to open up their own databases and software protocols, allowing the tinkerers to create related applications or sell symbiotic products and services. Amazon has taken this approach further than anyone, and Google isn't far behind. (See "The Great Giveaway," April.) "Open-source changes the rules of the game," says Tim O'Reilly, founder of tech publishing powerhouse O'Reilly Media. "Anyone can add and innovate, bring new pieces to the party."

Together these forces have created the technological infrastructure from which the fifth wave is rising. In essence, we are now surrounded by a kind of ecosystem of connectivity, unseen but everywhere, constantly growing, seemingly by itself. One of the distinguishing characteristics of the current shift compared with past ones is how much it is expanding from the grass roots up. Corporations supply some of the momentum, to be sure. But to an unusual degree, consumers are powering the fifth wave, as armies of mobile users discover new ways to exploit the connectivity that surrounds them—and businesses pop up to cater to them. Downloadable ringtones constitute an industry worth $2 billion a year. Sales of downloadable screensavers for cell phones have gone from basically nonexistent in 2001 to an expected $275 million this year.

There's another singular aspect of what's happening now, one that by itself creates enormous opportunities. A hallmark of the previous four waves was the almost direct correlation between hardware and software. If Intel made a new chip, Microsoft came up with a new operating system that could make use of the extra oomph. The platform and how it could be used basically moved in predictable lockstep. This time, however, the platform—broadband networks and the Internet—is already in place, waiting for applications to catch up.

Dozens of fifth-wave companies have been born into that breach. Salesforce.com drew snickers a few years ago when it came up with its model of allowing customers to essentially rent the company's enterprise software over the Web. Among other things, some observers predicted that Salesforce's programs for managing basic business functions like sales and customer service would jam up customers' networks. But because of the growth in bandwidth and cheap storage, that never emerged as a serious issue. Delivery over the Web reduces Salesforce's distribution costs to next to nothing. And the company is sizzling: Its first-quarter profits rose 10-fold year over year to $4.4 million, its revenue jumped 84 percent to $64.2 million, and its stock is up 24 percent this year to about $21 a share. Salesforce is still relatively small, but its impact could be huge: Other software makers, from Siebel to Oracle, have begun to sell programs the same way. "Customers are in open rebellion over the high cost of enterprise software," says Salesforce CEO Marc Benioff.

Skype, another fifth-wave pathfinder, may similarly transform the phone business by wielding the weapons of cheap computing and bandwidth. Niklas Zennström and Janus Friis, the brains behind music file-sharing service Kazaa, created Skype in 2003 to provide phone calls over the Web. They spent almost nothing on marketing; the company is basically a roomful of off-the-shelf servers and a tiny peer-to-peer program, downloadable for free from the Web. Skype users can essentially call anywhere in the world to PCs, cell phones, or old-fashioned wired handsets. A half-hour call from, say, San Francisco to London over a Cingular cellular network costs $5.70 or more. On Skype it costs 69 cents—which is why Skype now has 41 million registered users and is in the process of pulverizing traditional long-distance carriers.

Salesforce and Skype make a lot of noise because of the disruption they're causing to long-standing business models. But there are many other companies flourishing beneath the radar that have even more fully embraced the technological convergence driving the fifth wave. Ambient Devices was founded in 2001 by a group of MIT Media Lab refugees specifically to exploit the fact that it's now cheap and easy to put computing anywhere. And they meant anywhere. Ambient has, for instance, put a computer in a lamp that changes color every time the Nasdaq rises or falls, or when a sunny day turns to rain.

The Cambridge, Mass., startup's combination of software and chipsets allows a wide range of devices to wirelessly pull data from the Internet about weather, traffic, the stock market, and other subjects, and display it as changing colors in a glowing orb or simple movements of a needle against a graphic. In the space of six months before the 2003 Christmas buying season, 10 people at Ambient set up a wireless network that covers 90 percent of the United States, developed a content platform, and manufactured the company's first product, the Orb, to be sold by Neiman Marcus and Brookstone. The clever color-changing object flew off the shelves, and now Ambient products are sold by more than 50 retailers. Ambient won't disclose specific financial figures, but its COO, Nabeel Hyatt, says sales doubled last year and the company is already profitable.

Ambient is a poster-child fifth-wave startup: It used chunks of open-source code as the core of its software. Rather than build its own wireless network, which would have cost hundreds of millions of dollars, Ambient cut a deal with telecom company USA Mobility that let Ambient use existing infrastructure. Data from the Internet was already available, and setting up a Web-based interface for people to program their Ambient toys was a breeze for the MIT brain trust. And since the company is piggybacking on the Internet and an existing wireless network, it can easily scale to millions of customers. "Ultimately we will embed the technology inside all kinds of devices that display information from the Internet for all sorts of manufacturers," Hyatt says. "It's an incredibly broad opportunity."

As Ambient illustrates, the ability of a company to easily scale services from a single customer to millions is a defining feature of the fifth wave. Gordon Ritter, a VC at Emergence Capital Partners in San Mateo, Calif., says the secret to doing that is the "Amazon-ification" of software. People tend to think of Amazon as an online store, but it can also be viewed simply as a software platform for delivering a service over the Web. Its interface is customizable down to the individual user, it learns about customers' preferences, and it scales from one person to millions almost effortlessly. Ritter believes all software will soon function that way.

One of Ritter's recent investments is SuccessFactors, which sells subscription-based human resources software heavily underpinned by free open-source code. Success-Factors offers a highly customizable set of HR applications that are accessible using any Web-enabled device. The big shift, Ritter says, has been to design SuccessFactors for millions of individuals rather than taking the traditional approach of tailoring it for specific companies. "It does away with the old schism between the enterprise and consumers," Ritter says. "It brings service at companies down to the level of individuals in the same way that Amazon does with its customers." SuccessFactors CEO Lars Dalgaard says he's considering mimicking Amazon further by opening up his company's protocols to anyone who wants to create related services. SuccessFactors's revenue is expected to double this year to $50 million.

By its very nature, the always-connected era creates massive flows of data, and a race is on to develop software systems that help companies deal with it. El Segundo, Calif., startup Siderean Software has created a powerful application designed for needle-in-the-haystack searches of all the data within a corporation, from customer information to radio-frequency tag readouts to e-mail. The software, which contains kernels of open standards, is industrial-strength, but nothing that today's powerhouse corporate servers can't handle. Founder and CTO Bradley Allen says Siderean's software sorts and displays search results in more intuitive and contextual ways than, say, Google. "It's like finding an ethnic restaurant by pinpointing 'restaurant,' 'ethnic,' 'Moroccan,' and 'Fifth Avenue' in a 15-second look at the Manhattan Yellow Pages," Allen explains, "vs. searching page by page through the White Pages for a week."

Some of the richest opportunities churned up by the fifth wave are in the tricky but vital need to better merge the computer and the telephone. There remain significant technical hurdles to seamless interaction between the two technologies—as witnessed by anybody who has had to repeatedly punch in a credit card number to buy something over the phone. In 2000, startup Audium used an open standard called VoiceXML to cook up software that essentially translates voice or data input by punching phone buttons into a digital form readily understood by a corporation's database and other computing systems. Audium is already profitable. Another startup, Transera, has developed software based on free Linux code and other open standards that allows call centers to micromanage incoming calls—routing particular problems to operators with specific expertise, for instance, and allowing manufacturers to track customer interactions with their offshore support staff in minute detail. "We are marrying the computer to the phone," says founder and CEO Prem Uppaluru. "A few years ago, this was not even technologically possible."

Startups aren't the only ones eyeing the onrushing fifth wave. Much of tech's old guard is frantically trying to figure out ways not to get swept away by it—and some very entrenched companies seem surprisingly well positioned to drop into it and ride. IBM, for instance, has been retooling itself for several years with an eye toward the coming change. Big Blue prefers to call it "on-demand" computing, but however it is described, it's influencing everything CEO Sam Palmisano is doing. The recent sale of IBM's PC division to China-based Lenovo was a highly symbolic clearing of the decks in preparation for focusing intently on the fifth wave. Palmisano also has embraced the open-source movement and poured money into developing Web-enabled services and software. "If you look at all the hot computing trends of the future, IBM suddenly has a very strong foothold in all of them," says Arnie Berman, senior analyst at CreditSights and an early proponent of the fifth wave.

IBM's approach to the shifting landscape is to retreat from the PC hardware business. But that doesn't mean there's no opportunity for hardware makers. Chipmakers like Intel and AMD essentially see their future not on the desktop but in mobile devices that plug into the new era's all-enveloping connectivity. On a recent afternoon, Fred Weber, AMD's chief technologist, holds up an Audiovox cell phone that sports a mobile Windows operating system and declares, "The action is all here." AMD still makes the lion's share of its money on processors for PCs, but it has started to roll out chips for smaller, always-on gadgets. "It's mobile, connected devices—that's where the future lies," Weber says. Similarly, Cisco, a big fifth-wave adherent, is adjusting to cash in on the trend—and in many ways already has. As devices proliferate and networks expand, demand for the Cisco switches and routers that connect them and direct Web traffic could explode. And Cisco is expected to rack up $1 billion in sales of Internet phones this year. Says Cisco CTO Charlie Giancarlo, "This shift is going to be monstrous."

And scary, for those who don't get it. There are already some big tech names that show every sign of wiping out on the fifth wave. America Online (owned by Time Warner, the parent of this magazine) continues to flail, in large part because it has never understood the value of opening up its business the way Amazon and Google have. It remains trapped in its "walled garden"—and continues to bleed customers. AOL is about to unveil a new public portal that offers more free content, but many experts believe the wave will wash over AOL in the end. Even eBay, an Internet paragon in many ways, has been tentative in opening up its own databases and protocols, a stance that some analysts believe could throttle down its spectacular growth as the technology era shifts. Apple Computer is flying high right now, but given Steve Jobs's legendary resistance to opening up his technology, including the iPod, even Apple could get swamped by the fifth wave.

Over the long haul, one of the most important implications of the fifth wave is that it could create a more level playing field than the tech industry has seen in many years. The old titans may still do well. But many experts believe that the sheer number of opportunities, the cheapness of basic technological components, and the ever lower barriers to entry for many new niches could ring in a golden era for entrepreneurs and upstarts.

iRobot CEO Colin Angle, a man who dreams of putting a robot or three in every home, is one such enthusiast. He has reason to be hopeful these days: iRobot's annual sales are nearing $100 million and jumped 73 percent in 2004. He sees the fifth wave as a mighty equalizer. "If we are willing to envision a ubiquitous network, with ubiquitous storage and computing, that is a world where the Microsoft and Intel platform is not the king anymore," Angle says. "Innovative entrepreneurs get to play again under this scenario. Stupid, crazy stuff that no legitimate risk-averse company would try gets tried now."

James Watt could relate. When he first unveiled his steam engine, some of the few people who even knew about it thought he was a fool. That was in 1765. Watt himself had doubts, and took to referring to his soot-belching contraption as "Beelzebub." But then people began to realize what his technology could enable. Within two decades, Watt's engines were running England's cotton mills. In just a few more came the first steam locomotives, and soon thereafter the world was utterly transformed. The big waves are like that. They can start small, almost unnoticed, but they change the look of everything by the time they break on the beach.

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

   Java里面使用常量十分方便，将成员变量定义为final就行了，但在C++中，类的成员变量是不能赋初值的，因此往往将常量声明为全部数据，并用const来修饰。效果类似，但全局数据往往造成程序间不必要的耦合，是error prone，应该能免则免的。有一个变通的办法就是使用枚举：