Rainbows! is like unicorn, but Different…

While Rainbows! depends on unicorn for its process/socket management, HTTP parser and configuration language; Rainbows! is more ambitious.

Architectural Diagrams

unicorn uses a 1:1 mapping of processes to clients

unicorn master
\_ unicorn worker[0]
|  \_ client[0]
\_ unicorn worker[1]
|  \_ client[1]
\_ unicorn worker[2]
|  \_ client[2]
...
\_ unicorn worker[M]
   \_ client[M]

Rainbows! uses a M:N mapping of processes to clients

rainbows master
 \_ rainbows worker[0]
 |  \_ client[0,0]
 |  \_ client[0,1]
 |  \_ client[0,2]
 |  ...
 |  \_ client[0,N]
 \_ rainbows worker[1]
 |  \_ client[1,0]
 |  \_ client[1,1]
 |  \_ client[1,2]
 |  \_ client[1,3]
 |  ...
 |  \_ client[1,N]
 \_ rainbows worker[2]
 |  \_ client[2,0]
 |  \_ client[2,1]
 |  \_ client[2,2]
 |  ...
 |  \_ client[2,N]
 ...
 \_ rainbows worker[M]
    \_ client[M,0]
    \_ client[M,1]
    \_ client[M,2]
    ...
    \_ client[M,N]

In both cases, workers share common listen sockets with the master and pull connections off the listen queue only if the worker has resources available.

Differences from unicorn

Similarities with unicorn

While some similarities are obvious (we depend on and subclass off unicorn code), some things are not: