前言
warden是cloud foundry最核心的部分，它是云平台中app的运行场所，同时它又是cloud foundry中最独立的一个组件 ，它不在nats上订阅和发布消息就等于与其他组件几乎没有通信。在v1版本中cf的app就运行在dea中，到v2版本把 app的运行和控制场所实现了分离，warden管运行，而dea则控制app的运行，所以这也就不奇怪warden几乎只用和dea 打交道了。由于warden特殊性，它与操作系统联系是最紧密的，所以在考虑cloud foundry的移植的时候，其他组件 都与平台关系不大，而warden则是最大的障碍。
app在warden为他们分配的容器(container)中运行，每个容器又是相互不干扰的，所以这就要求warden能够在操作 系统中实现资源隔离，它有点类似于LXC这种被广泛使用的容器。warden是个轻量级的资源隔离的容器，即使我们 把它拿出来单独使用也是完全没有问题的，我们先来看看warden的通信。
warden-protocol
warden-protocol可以理解为warden的上层交互协议，它是基于beefcake来设计的，它是由google开发的，要大致理 清楚这部分代码，只需简单了解一下beefcake即可.
github：https://github.com/protobuf-ruby/beefcake
阅读它的Readme文件，它有两个过程(encode与decode)，不难理解就是编码与解码，它其实就是一个序列化与反序 列化的过程，warden-server与client的交互是通过unix_domain_socket来实现的,简单的说就是：client将带有任 务信息的对象encode成string类型，然后存入/tmp/warden.sock中，server将socket中的字符序列取出来进行decode ，然后完成需要做的任务。
warden-client与em-warden-client
刚开始看这两个概念就觉得没谱，怎么会有两个client，cf到底使用哪一个呢？实际上他们并不冲突，em-warden- client是基于EventMachine的编程，它的主要任务是与socket的沟通，是warden通信的主体，其中会调用到warden -client这个gem包，它会将对象封装成request或者response，最后写入socket的字符序列是把request或者response 序列化的结果。这个过程很难得理清楚，但是仔细想一想就明白了：
em-warden-client的任务是通信，warden-client的任务是生成request或者response(即一种封装)，最后warden
-protocol将对象编码，em再将编码写入到socket中。
我们来看两个过程：
dea给warden指派任务是通过task.rb这个类，其中就会引入em-warden-client来进行通信，在em中使用warden -client生成request，这个request被protocol编码后写入到/tmp/warden.sock中，在warden-server端EM读取到这个 request后分析其protocol类型，最后执行相应的动作。
当我们使用客户端直接接入warden的时候，Warden::Repl::Repl这个类来处理你的输入，这个时候就不再需要 em了，它直接与标准输出打交道，但是这个时候你的请求还是走的unix_domain_socket，序列化之后的请求通过warden =client的IO直接写入socket中。
所以上文中发生的事情很疑惑，warden-client实际上具有两面性，在与dea交互时起封装作用，而数据读写任务由 em-warden-client来完成，在控制台直接和warden交互时，socket数据又是通过warden-client的IO来读写的，但是 warden-server永远是EM来读写socket的。
warden-server
大致搞清楚了warden的上层通信，那么warden文件下就是实现的核心代码了，这块代码包含两部分
- warden的外围控制，包括server.rb和pool里面的.rb文件
- 容器的内部控制 即container与linux脚本。
warden的外层控制很简单，server.rb掌管着交互，接收来自外部的命令，并指挥执行，pool里面的掌管IP，PORT 的分配及USER权限问题。
container操控着容器内部的动作，也是与操作系统最为紧密的部分，将会在(二)中分解。