文章要解决的问题
Predicting face attributes from web images
方法的主要想法
It cascades two CNNs (LNet and ANet) forface localization and attribute prediction respectively.
贡献（吹牛逼）
(1) It shows how LNet and ANet can be improved by different pre-trainingstrategies.
(2) It reveals that although filters of LNet are fine-tuned by attributelabels, their response maps over the entire image have strong indication offace’s location.
(3)It also demonstrates that the high-level hidden neurons of ANetautomatically discover semantic concepts after pretraining, and such concepts aresignificantly enriched after fine-tuning.
首先推荐几个deep learning工具箱 1. Hinton DBN code 这个不用说了，开山鼻祖Hinton的代码，下载链接：Hinton DBN coce。代码可读性一般，后面我会把我修改后的代码公布出来。
2. Deep learning toolbox Mathworks上的代码，纯正Matlab代码，CNN部分写的不错，下载链接：DL Toolbox matlab。
3. Covolutional DBN Github项目主页：CDBN 科研机构 1. 香港中文大学 http://mmlab.ie.cuhk.edu.hk/ Honglak Lee Ph.D. in Computer Science, Stanford University, 2010 1. Convolutional deep belief networks for scalable unsupervised learning of hierarchical representations. [code]
2. Unsupervised feature learning for audio classification using convolutional deep belief networks. [code]
工具包：
1.Matlab Environment for Deep Architecture Learning (MEDAL) [code]
包含：
前段农闲时间，用R实现了些neural network和deep learning相关的算法，把这些代码做了个package叫deepnet,而且已经上传到CRAN上了。有兴趣的同学可以安装玩玩（R中执行命令:install.packages(“deepnet”)）.package介绍文档：http://cran.r-project.org/web/packages/deepnet/index.html
已经实现的算法包括bp, rbm训练，deep belief net, deep auto-encoder。后续有时间的话打算接着实现cnn和rnn。
本来打算做第一个deep learning的R package, 结果被一个叫Martin Drees的哥们捷足先登了，比我早两天发布了一个叫darch的package.各种不服啊。
Deep Learning源代码收集-持续更新…
[email protected]
http://blog.csdn.net/zouxy09
收集了一些Deep Learning的源代码。主要是Matlab和C++的，当然也有python的。放在这里，后续遇到新的会持续更新。下表没有的也欢迎大家提供，以便大家使用和交流。谢谢。
最近一次更新：2013-9-22
Theano
http://deeplearning.net/software/theano/
code from: http://deeplearning.net/
Deep Learning Tutorial notes and code
https://github.com/lisa-lab/DeepLearningTutorials
code from: lisa-lab
A Matlab toolbox for Deep Learning
https://github.com/rasmusbergpalm/DeepLearnToolbox
code from: RasmusBerg Palm
deepmat
Matlab Code for Restricted/Deep BoltzmannMachines and Autoencoder
https://github.com/kyunghyuncho/deepmat
code from: KyungHyun Cho http://users.ics.aalto.fi/kcho/
Training a deep autoencoder or a classifieron MNIST digits
http://www.cs.toronto.edu/~hinton/MatlabForSciencePaper.html
code from: Ruslan Salakhutdinov and GeoffHinton
CNN – Convolutional neural network class
通过上一节中我们对连接和链路的重新描述，我们可以继续进行源码的分析了。在本节中，我们会开始着重讲述链路的建立，以及链路所基于的OR连接的建立，同时还有部分Libevent调度的再度分析。大家会明白，进行到此处之时，我们已经开始接触Tor系统最底层，最深藏着的连接机制以及调度机制。这个部分，是整个系统的精髓。后期几乎所有的应用请求连接处理等，都是重复地使用该部分的代码。
1. 链路建立以及OR连接的开始，circuit_establish_circuit 我们在此处重新分析下链路建立的函数：
/** Build a new circuit for purpose. If exit * is defined, then use that as your exit router, else choose a suitable * exit node. * * Also launch a connection to the first OR in the chosen path, if * it's not open already. */ origin_circuit_t * circuit_establish_circuit(uint8_t purpose, extend_info_t *exit, int flags) { origin_circuit_t *circ; int err_reason = 0; circ = origin_circuit_init(purpose, flags); //链路初始化； if (onion_pick_cpath_exit(circ, exit) < 0 || //选取链路出口结点； onion_populate_cpath(circ) < 0) { //选取链路入口结点及中间结点； .
源码分析到这个部分，为了让大家明白源码中的编码逻辑，不得不开始从头梳理程序内部的复杂连接和链接组织形式。否则大家后期会更加一头雾水。笔者开始分析源码之时，没有这些宏观的概念，只能死嚼代码，硬猜硬想，再加以检查代码进行验证，才得以明白程序的主要框架逻辑。如果再以猜测验证的模式向大家讲述源码，必定会越来越混乱。所以，在本节之中，我们会将系统中所有的连接类型，链路类型和他们之间的关系和代码之中的关联方式尽量讲明。若大家遇到不明晰的部分，可以参照代码进行查阅。
在我们进行详细分析之前，先再次给出连接和链接的框架位置图。这个简单的层次图帮助我们理解不同连接和链接所处层次的位置关系，其实已经在我们分析OR连接源码之时给出，之时当时没有进行过多的深入介绍。
DIR连接，LISTENER连接 |
－－－－－－－－－－－－－－－－－ |
AP连接，EXIT连接…… Tor协议上层 |
－－－－－－－－－－－－－－－－－－－－－－－－－－－－ | 应用层
Circuit链路…… Tor协议中层 |
－－－－－－－－－－－－－－－－－－－－－－－－－－－－ |
OR连接…… Tor协议下层 |
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
TLS连接 传输层
1. 连接 很明显，系统中的连接类型多种多样，各有各自的不同职能。在此处，我们先罗列出所有系统中存在的连接，其后再对一些我们比较重视的连接类型进行相关说明。
//OR监听连接：本地用于监听远端传来的OR请求，为每个新请求建立一个OR连接；OR监听连接本地全局只有一个； #define CONN_TYPE_OR_LISTENER 3 //OR连接：基于TLS连接的，主要负责Tor系统内主机之间相互通信的连接；OR连接数量表征本地与多少台主机建立了互联关系，因为他们是一一对应的； #define CONN_TYPE_OR 4 //EXIT连接：翻译为出口连接是因为该连接会与远端服务器建立socket连接并传递数据； #define CONN_TYPE_EXIT 5 //AP监听连接：本地用于监听本地应用程序的服务请求而设立的监听连接，为每个服务请求建立一个AP连接；AP监听连接本地全局只有一个； #define CONN_TYPE_AP_LISTENER 6 //AP连接：基于链路的，主要负责为客户端请求寻找合适链路和传递数据；AP连接数量表征本地应用程序发出的连接请求数量，因为他们是一一对应的； #define CONN_TYPE_AP 7 //DIR监听连接：Tor系统目录服务器用于监听Tor系统内主机发出的目录相关请求，也就是说该类型连接只在目录服务器上存在； #define CONN_TYPE_DIR_LISTENER 8 //DIR连接：Tor客户端向Tor目录服务器发送目录请求时需要新建的连接，该连接需要通过AP连接为其转发请求，也就是说类似于普通应用程序的请求连接； #define CONN_TYPE_DIR 9 //CPUWORKER连接：用于在程序开启多进程解密服务的时候提供进程间通信，详细过程可以参看前面分析过的cpuworker部分文章；正常情况下未被使用； #define CONN_TYPE_CPUWORKER 10 //CONTROL监听连接：本地用于监听本地应用程序传递的控制指令或请求；（后期专门讲述，此处暂略） #define CONN_TYPE_CONTROL_LISTENER 11 //CONTROL连接：本地用于控制消息处理的连接；（后期专门讲述，此处暂略） #define CONN_TYPE_CONTROL 12 //以下三种连接由于非常少见，此处我们暂时略去； #define CONN_TYPE_AP_TRANS_LISTENER 13 #define CONN_TYPE_AP_NATD_LISTENER 14 #define CONN_TYPE_AP_DNS_LISTENER 15 很明显地，通过分析上面这些连接类型我们发现，对于客户端而言，最重要的连接类型无非就是DIR,AP,OR三种连接。这些连接之间的相互关联和作用帮助客户端应用程序将应用请求送入Tor系统，并再通过Tor系统的封装等操作将数据成功送出到远端目的地。下面我们来简要描述下整个系统运转的过程。 1.
源码分析到这里，大家应该已经大致了解到Tor系统的前期启动没有做任何的下载操作。前期启动的最关键环节，就是正常开启Libevent的调度机制，从而有条不紊地进行系统内所有子模块的维护等。我们需要再次强调的是，系统的主进程内，是没有做任何直接的获取网络状态，获取路由描述符，获取额外路由信息的操作。系统将这些操作视为需要实时维护的工作，因为所有这些网络信息都有其时限。所以，对这些网络信息的获取，全部置于秒回调函数之后进行。秒回调函数能够控制对这些信息的检测和获取，这些在前一节中已经有部分描述。
我们将在本文中再次重申秒回调函数中最重要的执行线路，以弄清Tor系统是如何获取网络信息，从而开启链路以至于完成整个系统的成功建立。由于本文中所提到的许多函数嵌套层次非常之多，我们只针对最重要的函数加以说明；同时，我们会略去许多不被执行的函数。这些不被执行的函数，大多情况下是因为执行条件不满足而未能够通过函数内部执行前检测，或更甚者未能通过函数外部的判断语句检测。关于这些情况，请大家自行查看函数细节，此处就不再一个一个详细解释。
1. update_networkstatus_downloads 前面介绍的秒回调函数之中最重要的维护函数即为事件调度函数。事件调度函数中，大部分的内容由于与时间相关而不会在短期内执行。具体的执行间隔可以参照之前章节中源码的注释。在简要的对该函数进行分析之后，我们发现，客户端系统刚刚启动之时，最终重点调用的代码如下：
static void run_scheduled_events(time_t now) { ...... /* 2b. Once per minute, regenerate and upload the descriptor if the old * one is inaccurate. */ ...... if (time_to_check_descriptor < now && !options->DisableNetwork) { //每一分钟进行一次网络状态的下载检测 ...... time_to_check_descriptor = now + CHECK_DESCRIPTOR_INTERVAL; ...... /* Also, once per minute, check whether we want to download any * networkstatus documents. */ update_networkstatus_downloads(now); //开启网络状态的下载 } ...... } 以下为网络状态下载函数的函数体：
/** Launch requests for networkstatus documents and authority certificates as * appropriate.
我们知道，对于Tor的服务器来说，有的时候因为其访问量巨大，不得不采取一些相应机制来保证服务的正常提供。在服务器编程里，我们经常可以用到的技术，例如线程池，多路复用等。Tor程序，在大多数情况下，都是单进程运行的，几乎没有哪里用到多线程的操作。正因为如此，Tor的主进程才绝对不允许出现阻塞式的操作。但是，唯独在一处，Tor为了提高自身效率，利用了线程池类似的机制。这个部分就是Cpuworker。本文就主要介绍该模块的作用和实现机制。
简单的说，Cpuworker存在的目的，是为了利用线程池的机制分担Tor主进程的压力，帮助其在接收到CREATE请求时计算对称密钥。下面进行具体的过程描述：
1. 系统启动时根据主机CPU数量，初始化cpuworker线程池；（linux中线程和进程基本无差别）
cpuworkers_rotate()
1.1 根据配置文件配置选项，自适应地检测CPU数量或固定设置CPU数量；
spawn_enough_cpuworkers()
1.2 根据CPU数量，开启cpuworker线程；（最大数目为16，最小数目为1）
spawn_cpuworker()
1.3 开启线程之前，创建sockpair，创建cpuworker连接，关联cpuworker连接与sockpair[0]；
1.4 开启线程之时，设置线程执行函数cpuworker_main，关联线程与sockpair[1]；
1.5 开启线程之后，将cpuworker连接加入系统连接池，同时从此线程与Tor主进程之间的通信方式为sockpair，类似socket的读写操作；
2. 在成功完成以上操作之后，系统达到如下效果：
2.1 当Tor主进程收到某主机发来的CREATE包时，检查连接池内是否有空闲的cpuworker连接；
assign_onionskin_to_cpuworker()
2.2 若有空闲cpuworker连接，则将CREATE包内容写入该连接；
connection_write_to_buf()
2.2.1 写入该连接则会激活该连接，使其将数据进一步写到sockpair[0]内，亦即传递给对应的线程，线程利用sockpair[1]来读取数据；
2.2.2 线程的主函数是阻塞式得等待数据，一旦数据到达，则开始处理，并在处理完毕之后，将结果写回sockpair[1]，亦即传递回主进程cpuworker连接；
cpuworker_main()
2.2.3 主进程处理cpuworker读事件就是根据对应的链路返回对应的CREATED包，其中包括DH密钥交换协议第二部分密钥和生成的对称密钥的摘要等；
2.3 若无空闲cpuworker连接，则将CREATE包挂起，在适当时候再写入空闲连接；
onion_pending_add()
上述整个过程，省略了很多细节部分，大家各自参照原函数进行进一步分析和理解。此处对几点再进行强调：Tor系统的连接多种多样，我们前面提过AP连接等内部连接，实际上Cpuworker连接也是内部连接，虽然他是用sockpair来完成的；sockpair是一种进程间通信机制，在众多的通信机制中，这种机制对Tor系统最为合适，所以选用了这种方式；Cpuworker线程的主要工作内容是对称密钥的生成。
这里我们再对称密钥的生成进行说明：
1. 在链路建立的过程中，Tor服务器应该首先接收到CREATE包。CREATE包的负载部分具有如下格式：（针对TAP握手方式）
Payload := PK(Padding || Symmetric key || First part of g^x) || SK(Second part of g^x)
PK：利用服务器的Onion Key进行公钥加密；
SK：利用Symmetric Key进行对称加密；
Padding：填充字节，长度一般为42B
Symmetric Key：用于加密第二部分内容的对称密钥；
g^x：DH密钥交换协议第一部分密钥材料。
2. 服务器接收到CREATE包之后，就要决定DH密钥交换协议的第二部分密钥材料g^y，从而计算出对称密钥。就是因为这个部分的密钥操作过程稍微会耗上一部分的时间，不适合在Tor主进程中进行操作，所以Tor程序利用cpuworker机制，开启线程专门为这种操作提供服务。在处理玩这些操作之后，Tor主进程生成CREATED包，返回给指定的链路。CREATED包的结构如下：
Payload := DH_key || Digest
日志模块是Tor系统中一个非常重要的部件。它将Tor系统中的所有事件，分成不同的严重级别，分成不同的系统域，进行统一的日志处理。同时它还维护着一个日志记录链表。日志记录链表内存储的是所有日志需要输出的目标日志文件或目标日志输出位置。下文中我们会详细地对日志模块进行分析，并简要说明源文件中的各函数的简单作用。
1. 严重等级和域 日志模块内定义了5个严重等级，其具体的设定如下：
/** Debug-level severity: for hyper-verbose messages of no interest to * anybody but developers. */ #define LOG_DEBUG 7 /** Info-level severity: for messages that appear frequently during normal * operation. */ #define LOG_INFO 6 /** Notice-level severity: for messages that appear infrequently * during normal operation; that the user will probably care about; * and that are not errors. */ #define LOG_NOTICE 5 /** Warn-level severity: for messages that only appear when something has gone * wrong.
传统上我们所指的系统信号，就是系统传递给进程的控制信号。例如，SIGINT，SIGTERM等等。这些信号的传递，通常都是指示相关进程完成相应的操作，或暂停或终止，或其他一些操作。在Tor系统中，信号分为两种：传统信号，控制器信号。下面代码段是这些信号的简单罗列： /* These signals are defined to help handle_control_signal work. */ #ifndef SIGHUP #define SIGHUP 1 #endif #ifndef SIGINT #define SIGINT 2 #endif #ifndef SIGUSR1 #define SIGUSR1 10 #endif #ifndef SIGUSR2 #define SIGUSR2 12 #endif #ifndef SIGTERM #define SIGTERM 15 #endif /* Controller signals start at a high number so we don't * conflict with system-defined signals. */ #define SIGNEWNYM 129 #define SIGCLEARDNSCACHE 130 这些信号，是程序最主要关心的信号。他们都有相应的响应处理，其处理函数均为信号回调函数中调用的process_signal函数。在前面的小节中，我们已经提到过了关于信号事件的处理机制，这里就不再多说。但是，值得注意的是，当时的信号事件注册，并没有注册SIGNEWNYM信号和SIGCLEARDNSCACHE信号。也就是说，这两个信号并非由信号处理事件激活的。那他们是出现在何处的呢？答案是控制连接信号传递。
我们暂且将这个部分的内容搁置在这里，标题改成Control。在后期分析完成控制连接之后，将这个系统控制连接的主要作用和用法在这里进行详细描述。
未完待续……