回顾半鞅下的伊藤公式

    再次回顾半鞅下，伊藤公式的最一般形式如下（包含了跳跃部分）：

为了一般性，考虑一个d维半鞅：,以及一个d+1元二次连续可微函数, 那么随机过程f(t,X)也是半鞅，并且

上式是伊藤公式的积分形式，在形式推演中，采用其微分形式更为方便：

注意：1)  代表的连续部分
            2)  对于这个微分形式，在 Δf仅仅被理解为f的纯跳跃的情况下是不正确的。但是，如果我们对Δf进行二重理解：第二种理解，就Δf是f的纯跳部分的形式微分。

考虑到d[X,Y]=dX dY和和的形式关系,  为了形式推演的通用性，上述微分形式可以改写为：

注意：  代表的连续部分，在这个表达式中消失了。相应地，表达式多出两个纯跳跃的项。

随机分析库中伊藤公式的完整实现

         假设《随机分析库初实现(Mathematica应用)》中的代码已经整理到StochasticAnalysis.m中，并且已经将该文件放置在Mathematica软件的合适目录下。为了继续下面的论述，需要先加载此随机分析库的实现：

补充一些记号

说明：用代表强度为λ的泊松过程，泊松过程不是鞅，但补偿泊松过程是鞅。
Δ代表严格意义上的纯跳跃，也代表纯跳过程的形式微分。

扩充和上述记号相关的运算法则

      说明：这些运算法则定义了如下这些关系
1）
2）
3）a(b==c)→ a b==a c
4)   =0,i≠j
5）X dY==0
6）
7）

含泊松跳跃的化简

      说明：由于泊松跳跃的二值性：{0,1},故有关系:
        PoissonSimplify功能就是利用这个关系进行化简。

跳跃的计算

      说明：上述规则就是将形如f[t,x[t],y[t],…]的表达式变换成f[t,x,y,...]，
        然后调用后面的规则计算[f[t,x,y,..],t]==φ[t,x,y,...]，
        最后再变回成φ[t,x[t],y[t],…]

      说明：这两个规则表示 : J({X,Y,Z})=={J(X),J[Y],J[Z]}

      说明：这两个规则是技术性规则 J[Y,t,X,Y,Z,...]==J[Y],J[t,t,X,Y,...]==0

      说明：这个规则就是跳跃的最终实现:f(t,x,y)==f(t,x+J[x],y+J[y])-f(t,x,y)。

伊藤公式的扩展

      说明：至此，已经完全实现了伊藤公式在半鞅下的实现。

代码整合

    最后需要将上述代码整合到到StochasticAnalysis.m中。

应用

例一：含跳跃的随机链式法则

     和不含跳跃的情形一致

例二：标准维纳过程平方的伊藤全微分

例三：带漂移项的几何泊松过程

例四：伊藤公式的一个常用形式

     不含跳跃的情况

     含跳跃的情况

例五：解含泊松跳跃随机微分方程

待求解的随机微分方程

对应的纯跳跃成分

求log(S(t))的伊藤微分

写成积分形式，就是原随机微分方程的显示解

参考资料

1）《金融随机分析(II)-连续时间模型(中文版)》-(美)S.E.Shreve，上海财经出版社

2）《半鞅与随机分析》，何声武,汪嘉冈,严加安，科学出版社

3）《随机金融基础(第2卷)-理论》，(俄)A.H.施利亚耶夫，-高等教育出版社

4）A Benchmark Approach to Quantitative Finance，Echhard.Platen，David.Heath，Springer

Created with Wolfram Mathematica 8.0

© 2012, 無處不在. 版权所有.

（*转载务必注明出处*）

在Mathematica中推演了两类鞅方法：一类是经典的等价鞅测度(风险中性世界)上的鞅方法，另一类就是真实概率测度（真实世界）上的鞅方法,也就是所谓的基准分析法。

等价鞅测度法是基于所谓的资产定价的第一与第二基本定理：粗略地说，即，市场无套利机会等价于存在等价鞅测度，使得所有证券的贴现价格()过程为鞅(第一定理)，并且当市场完全时，这样的鞅测度是唯一的(第二定理)。
基准分析法则是基于最优增长组合(GOP)的存在性，使得证券的基准化价格()过程在真实概率测度中为鞅。
最优增长组合(GOP)的存在性的条件，相对于等价鞅测度的存在性算是一个很宽松的条件。 所以基准分析法相对而言具有更大优势。

关于这两种鞅方法，我个人认为，优先采用等价鞅测度法，如果不存在等价鞅测度，则考虑基准分析法。

随机分析库

很遗憾，Mathematica并没有提供随机分析相关的符号运算库，为此本人实现一个Mathematica的随机分析库StochasticAnalysis。本着够用就行的原则，随着推演的深入而逐步丰富完善。
具体实现参见上一篇文章：《随机分析库初实现(Mathematica应用)》

Black-Scholes模型

基础证券价格过程S(t)随机微分方程(SSDE)：

无风险资产价格过程B(t)微分方程(BDE)：

等价鞅测度法

真实世界(真实概率测度)中,基础证券贴现SDE(SDiscSDE)

其中被称为基础风险证券贴现价格

寻找风险中性世界(等价鞅测度)中的标准维纳过程

资本定价基本定理告诉我们：市场无套利并且完全时，存在唯一的等价鞅测度。 为了能够使用等价鞅测度，我们不妨假设市场无套利并且完全。
我们用来表示鞅测度下标准维纳过程。依据伊藤积分的鞅性定理，如果满足如下方程，那么就是鞅。

比较方程SMDiscSDE和SDiscSDE，和W(t)有如下关系：

    其中：被称为市场风险价格。

上述论述说明了：是鞅等价于是标准维纳过程。
于是问题归结为：寻找一个测度变换，变换后的是标准维纳过程。

Girsanov定理给出了肯定的回答：在测度变换

下，成为一个标准维纳过程。
这个定理同时构造了一个等价测度，由前面的分析知：是标准维纳过程，意味着在这个等价测度下构成鞅，进而这个等价测度就是唯一的等价鞅测度。

风险中性世界中,基础证券贴现SDE(SMDiscSDE)

既然在等价鞅测度下成为一个标准维纳过程，于是有：

风险中性世界中,基础证券SDE(SMSDE)

SMSDE的求解：

此解对应的积分形式：

注意：W是风险中性世界中的标准维纳过程，正是这个原因才使得α(t)在这个方程中消失了。

当波动率σ(t)==σ为常数时,满足对数正态分布，可以直接用Mathematica中LogNormalDistribution表示:

           其中：r在这里应该理解为，即某个时间段的平均利率。虽然它也不是常数，但对于特定的时间区间， 可以看成是常数.  
                     波动率不能简单的这样处理，因为当波动率不为常数时，只能说明在很短的时间段内才是正态分布，就整体而言无法直接用正态分布表示,。

依据贴现价格的鞅性进行资产定价

由基础证券贴现价格在等价鞅测度下鞅性，很容易推导出基础证券的投资组合的贴现价格在等价鞅测度下也具有鞅性。根据市场的完全性假设，任何资产都可以用基础证券的投资组合来复制。资产的贴现价格也在等价鞅测度下具有鞅性。

所以资产的贴现价格在这个鞅测度下构成鞅，即：

将此鞅性变换成定价公式的形式:

当波动率为常数时，此定价公式可以简单表述为：

对应基础证券的分布：

基准分析法

投资组合

投资组合(PortsEq)

自融资组合(SelfPortsEq)

投资组合的SDE(PortSDE)

    其中：,并且因为PortEq，故有关系π0(t)+π1(t)1。

最优增长组合（GOP）(GopSDE)

的SDE

设投资组合的增长率是g[t]：

于是PortsSDE1变成：

所谓GOP过程，就是使g(t)最大化的投资组合的价格过程。求g(t)的极值点：

GOP SDE

基准化基础证券(SGopSDE)

    其中：

依据伊藤积分的鞅性定理知：基准化基础证券在真实概率测度中构成鞅。

基准化无风险资产(BGopSDE)

     其中：

依据伊藤积分的鞅性定理知：基准化无风险资产在真实概率测度中构成鞅。

基准化投资组合(PortsGopSDE)

    其中：

投资组合的鞅性分析

前面的分析告诉我们：基础证券(包括有风险的，无风险的)的基准化价格在真实概率测度中构成鞅。

可以看出： 基础证券的这种鞅性是模型内生，GOP过程的存在性也是模型内生的，并不要求经典鞅方法的等价鞅测度。

基准化投资组合并不一定是鞅，原因是： 并非是一个可料过程。

但是根据鞅论知识，还是能够获得基准化投资组合的一些性质：

１）首先，基准化投资组合是无漂移项的SDE，故基准化投资组合在真实概率测度中至少是局部鞅。
２）其次，由于任何非负的局部鞅都是一个上鞅，而由于公司法，破产法等相关的法律制度可以保证投资组合的非负性，故基准化投资组合在真实概率测度中构成上鞅。
３）最后，依据可选采样定理和基准化投资组合的上鞅性，可以推导出任何非负的投资组合不允许套利的存在。

另外，虽然基准化的投资组合不一定是鞅，但不妨碍我们将基准化价格满足鞅性的投资组合价格的定义公平价格。
依据鞅论知识：最小的非负的上鞅是鞅。故非负公平投资组合的价格是所有非负组合价格的最小值。

所以：在基准分析法中计算的资产价格都是特指公平价格，因为公平价格的基准化在真实概率测度中构成鞅。即

注意：上面的叙述是粗略的，并且依据概率论的惯例，应该都是在“几乎确定”的修饰下才成立的。

利用基准分析法进行资产定价－计算公平价格

将前面的鞅性直接转换成定价公式

注意：基准分析法的定价公式具有一般性，和具体模型无关。只有在具体计算的时候才需要结合具体的模型。
而等价鞅测度法，也和具体模型无关，但需要等价鞅测度的存在性作为基本假设。

定价函数偏微分方程的推导

以贴现价格是鞅的情况为例，对贴现定价函数运用伊藤公式，然后代入风险中性世界证券过程SMSDE和无风险资产过程BDE,整理得：

由于是鞅，上述结果的漂移项必须是零，于是获得贴现定价函数的偏微分方程(VDiscPDE)：

进而得到定价函数的偏微分方程(VPDE)：

另一方面，从“基准化价格是鞅”也能推导出同样的定价函数偏微分方程方程：(注意，代入的是真实世界的风险证券过程SSDE和GOP过程GopSDE)

注意： 我们发现这里的推导根本不需要Feynman-Kac公式，因为Feynman-Kac公式的具体细节都体现在各种规则中了。

常参数Black-Scholes模型的定价公式

    就一般的金融模型而言，金融产品的定价函数往往没有显示解，需要依靠数值计算或蒙特卡洛模拟。 但对常参数Black-Scholes模型下的欧式期权是有显示解，下面通过三种方法推导出这个定价公式。

方法一：风险中性世界下的鞅定价

   自然，我们必须选择风险中性世界下的SDE来描述基础证券的运动：

这表示（对常系数而言）：

    其中： 是基础证券的到期价格，S是基础证券的当前价格.

考虑一个看涨欧式期权的偿付函数P(S,K):

于是,依据鞅定价公式，直接计算看涨欧式期权定价公式的显式表达式(VCall)：

为了和教科书的公式一致，只要将Erf(x),Erfc(x)用标准正态分布函数表示：

方法二：真实世界下的鞅定价

   这里，我们必须选择真实世界下的SDE和GOP过程来描述基础证券的运动，：

对于常数参数，其解为：

考虑一个看涨欧式期权的偿付函数P(S,K):

于是,依据鞅定价公式，直接计算获得看涨欧式期权定价公式的显式表达式：

     注意到：和前面方法一的结果一致，并且参数θ在结果中消失了。

方法三：解定价函数的偏微分方程

Mathematica功能扩充

为了让推演更加方便，首先扩充了 “非等式表达式和等式表达式的乘积” 和 “傅立叶变换/逆变换对泛函的支持”

待求解的偏微分方程

待定系数法将偏微分方程变换成最简形式

考虑的含待定参数γ的变量变换关系(varChange):

        说明： 之所以出现了(T-t)，是因为需要将终值边界条件变换成初值边界条件。
                    的出现是为了将PDE的最简形式中消去σ参数。
                   第二个等式是为了，保证最终积分形式解的被积函数最简化，其中γ是一个待定参数.

考虑含待定参数{α,β}的函数变换关系(funChange):

于是获得完整的函数变换形式(fullFunChange)：

进而获得完整变换规则(rules)：

利用变换规则对原PDE进行变换：

为了使方程最简单，只要前两项系数为零即可：

    于是得到最简单的偏微分方程（热传导方程）：

前含待定系数的变换方程，变成了：

对于T时刻的函数变换规则：

对于T时刻的变量变换规则：

于是边界方程变成了

用傅立叶变换解变换后的偏微分方程（热传导方程）

对含边界条件的热传导方程做傅里叶变换(只对变量x变换)：

  这是一个关于τ的微分方程的初值问题，很容易求解

这里我们就要选择适当的γ，使得表达式最简单，关注的表达式部分

很明显，当ξ的系数为零时，表达式最简单:

于是三个待定参数{α,β,γ}全部找出了:

于是解的形式可以变的更简单：

考虑欧式看涨期权

看涨欧式期权的偿付函数P(S,K):

变量恢复,得到原始目标偏微分方程的解

根据αβγ确定 函数变换关系 和 变量变换关系：

得到偏微分方程的解

为了和前面两个方法比较，并且考虑当前期权价格t→0

很明显，和方法一和方法二的结论一致。

参考资料

1）《金融随机分析(II)-连续时间模型(中文版)》-(美)S.E.Shreve，上海财经出版社

2）《期权、期货及其他衍生产品(中文版.第七版)》，(加)John.C.Hull，机械工业出版社

3）《随机金融基础(第2卷)-理论》，(俄)A.H.施利亚耶夫，-高等教育出版社

4）A Benchmark Approach to Quantitative Finance，Echhard.Platen，David.Heath，Springer

5）Arbitrage Theory in Continuous Time (Second Edition)，Tomas BJORK，Oxford University Press

Created with Wolfram Mathematica 8.0

© 2012, 無處不在. 版权所有.

随机分析之伊藤公式

    这个初步实现，仅仅包含“ 随机分析”中非常重要的伊藤公式的实现。在半鞅下，伊藤公式的最一般形式如下（包含了跳跃部分）：

为了一般性，考虑一个d维半鞅：,以及一个d+1元二次连续可微函数, 那么随机过程f(t,X)也是半鞅，并且

上式是伊藤公式的积分形式，在形式推演中，采用其微分形式更为方便：

作为“随机分析库”的一个初步实现，暂时不考虑含跳跃过程的随机过程，并且考虑到d<X,Y>=dX dY的形式关系,于是有进一步简化的形式：

随机分析库的初步实现

首先，确定伊藤全微分ItoDt的函数参数，类似Dt:

参数定义：
ItoDt[f,t] 给出以t为时间参数,表达式f中形如x[t]为随机过程，f的伊藤全微分.
ItoDt[f,t,x] 给出以t为时间参数,x为随机过程参数，f的伊藤全微分.
给出以t为时间参数,为向量随机过程参数，f的伊藤全微分.

引入一些记号：

         说明：用代表标准维纳过程，用D代表伊藤全微分.

扩充和上述记号相关的运算法则：

说明：这些运算法则定义了如下这些关系
1）
2）
3）
4）

最后，给出伊藤公式的实现：

         说明：上述规则就是将形如f[t,x[t],y[t],…]的表达式变换成f[t,x,y,...]，
                 然后调用后面的规则计算D[f[t,x,y,..],t]==φ[t,x,y,...]，
                 最后再变回成φ[t,x[t],y[t],…]

         说明：这两个规则表示  D({X,Y,Z})=={DX,DY,DZ}

         说明：这两个规则是技术性规则 D(Y,t,X,Y,Z,…)==DY,D(t,t,X,Y,…)==dt

         说明：这个规则就是伊藤公式的最终实现。

应用

例一：随机链式法则

例二：标准维纳过程平方的伊藤全微分

例三：

例四：伊藤公式的一个常用形式

例五：Black-Scholes模型

无风险资产B(t)满足的微分方程（DE）：

风险资产S(t)满足的随机微分方程（SDE）:

真实世界下，风险资产的贴现价格 ：

风险中性世界下的贴现价格

依据伊藤积分的鞅性知： 在风险中性世界中，风险资产的贴现价格过程是鞅。

后记

本文涉及的“随机分析库”，可能会根据我的需要而修改添加，但此文作为程序包开发范例的初步实现，不会进行更新。
下载：“随机分析库”初步实现的源代码： StochasticAnalysis.m

Created with Wolfram Mathematica 8.0

© 2012, 無處不在. 版权所有.

我的目标是：

１）软件免安装（U盘携带）；

２）正常工作时，数据和软件全部在电脑上（不需要插入U盘）;

３）在其它环境中工作时（比如：网吧）中能够直接在U盘上处理;

４）能方便快捷地将数据转移到U盘，而不需要复制大量文件,也不需要仔细地选择需要复制的文件。

我的方案是： PortableApps.com ＋ Synkron

PortableApps.com 是一款绿色软件的下载和管理软件，解决了软件的免安装问题。

Synkron 是一款文件夹同步程序，解决了电脑数据和U盘数据的同步问题。（当然如果你喜欢其他的文件夹同步程序也可）

这两款软件都支持中文界面，这两款程序本身也都是绿色软件。并且Synkron可以从PortableApps.com下载。

方案实施前提：

已经安装了PortableApps.com，并通过PortableApps.com下载好了所有我需要的绿色软件（自然也包括了Synkron）.并且将其他途径获的的绿色软件也放置在PortableApps.com中进行管理。日常经常用的文档也用PortableApps.com进行管理。 这样所有我需要携带的数据全部在PortableApps.com的安装目录中。

正常使用的场景：

１）本地个人文档，我一般存储在PortableApps.com的Documents目录下。

２）可能使用谷歌浏览器访问网络，离线或在线访问Gmai，并且可能会使用一些谷歌浏览器的扩展程序。

３）可能使用火狐浏览器访问网络，并且可能会使用一些扩展程序。

４）可能会使用FeedDemon离线或在线访问谷歌阅读器。

５）可能会使用Windows Live Writer离线或在线写博文。

……

关机前的数据同步：

所有上述行为涉及的软件都是绿色版，程序产生的数据都在各自的目录下，自然也都在PortableApps.com的安装目录下。

关电脑前，为了能在其它地方继续使用这些数据和软件，你必须将含有这些数据和软件的文件夹PortableApps复制到U盘上。

直接复制到U盘上？ 不，你想象一下这么多软件和数据总共估计有上G，偶尔这样大量复制一下没有问题，但要你天天复制这么多数据，你可能就烦了。

选择修改的部分复制到U盘上？ 不，简单几个文件还可以，如果要将所有变化的部分（可能包括程序生成的数据）仔细选择后复制到U盘上，估计你也不干了。

这时文件夹同步软件Synkron就派上用场了。第一次同步实际上就是整体复制到U盘上，可能要一段时间。但以后同步时只会复制/删除变化的部分(已删除的，新创建的，已修改的)。

注意：１）要同步已删除的可能需要一些设置 ２）为了保证同步的可靠性，必要保证任何要用到的机器时间基本准确。

其他环境下的使用场景（比如网吧）：

由于PortableApps.com本身也是绿色软件，只要你插入已正确同步了数据的U盘，找到其启动程序：PortableApps/Start.exe ，就可以通过PortableApps继续使用相关的程序和数据。由于是在U盘上直接运行，就不存在数据同步的问题。

回到家中或公司的正常环境下，插上U盘，启动同步程序将U盘中的数据同步到电脑中，然后拔掉U盘。又可以继续延续以前的工作环境和数据。 其实通过这种方式也可以将公司产生的数据和家中产生的数据进行同步， 很方便。

目前我通过PortableApps.com安装或管理的绿色软件列表：

从PortableApps直接下载的绿色软件

Synkron        文件夹同步程序
Toucan        又一款文件夹同步程序
Foxit Reader    PDF阅读器
WinDjView    Djvu阅读器
FileZilla    文件传输客户端
谷歌浏览器
火狐浏览器
Putty        ssh客户端
WinSCP          sftp客户端
7-Zip        解压缩软件
Thunderbird    邮件客户端
Command        Win命令行

从其他途径获得的绿色软件

Windows Live Writer    博客工具
FeedDemon        RSS离线阅读器(支持谷歌阅读器)
无※界            翻墙软件
自※由※门        翻墙软件       
GaoAgent        翻墙软件

© 2012, 無處不在. 版权所有.

使用前必须加载mEngine模块

一个Mathematica矩阵

将Mathematica矩阵x存储到Matlab的工作空间中。
注：第一次操作Matlab会先启动Matlab命令行（默认是隐藏状态）

查看Matlab工作空间的的x变量

在Mathematica中寻求Matlab命令帮助

对Matlab工作空间中的变量x求逆

将Matlab中的结果变量y转换成Mathematica的变量y

将Mathematica已存在的两个变量x,y存储到Matlab的工作空间中

在Matlab中求特征矩阵和特征向量

将Matlab的特征矩阵和特征向量变换成Mathematica的特征矩阵和特征向量

默认是隐藏了Matlab的命令行窗口，必要的话你可以通过下面的命令显示Matlab的命令行窗口，从而你可以直接在Matlab的这个命令行窗口内直接执行Matlab命令，并且同样可以在Mathematica中获取你的结果。

隐藏Matlab命令行窗口的命令:

一个稍微复杂的Mathematica与Matlab交互的例子

寻求帮助(注意：m开头的命令对于我们交互已经足够了)

mEngine`eng

eng=LinkObject[\"D:\\Program\\Mathematica\\8.0\\AddOns\\Applications\\matlab\\mEngine.exe\",14,8]

Created with Wolfram Mathematica 8.0

© 2012, 無處不在. 版权所有.

为何需要互操作？
        数值计算和图形方面Matlab毫无疑问是最强的，但其符号演算方面就比较弱。
        符号运算方面Maple和Mathematica各有千秋。我个人感受：就符号运算本身而言，Mathematica应该比Maple更强，但软件自带工具包的丰富程度，Maple比Mathematica更丰富。此外，Mathematica本身的数值计算能力总体上还是比Maple更强，而Maple的易用性比Mathematica更强。
        由上面的优缺点对比，就存在可能会同时使用两款以上的软件，也就存在互操作问题。

本文成功配置的参考环境：
        Win7-x86+Matlab2011a+Mathematica8+Maple15+Microsoft Visual Studio 2010

一）在Matlab环境中调用Maple

• 1) 确认Matlab和Maple都已经安装。
• 2) 确认设置环境变量：MATLAB_SYMBOLIC=Maple
• 3) 安装Maple Toobox for Matlab
  可以在Maple15安装目录下找到：MapleToolbox.bat 。 运行依向导运行之，并且依次按提示选择Maple和Matlab的安装目录。
• 4) 启动Matlab 并执行命令：toolbox_version，验证Maple工具箱是否安装成功
  如果成功，该命令返回： toolbox_version=maple
• 5) 确保Matlab真的会使用Maple符号计算引擎
  在Matlab命令行中输入: pathtool , 执行之会弹出一个对话框，下拉到最后，选中最后两个，然后点击左边的”Move to Top“（移动到顶端）按钮，然后选择保存。exit退出matlab，现在设置好了。
• 6) 重启Matlab,验证之：

        maple(‘discrim(a*x^2+b*x+c,x)’)
        int(‘atan(x)/x^(3/2)’,0,1)
        syms x
        maple(‘solve(x^2*exp(x)-10,x)’)
        maple(‘plot(exp(x)*x^2-1, x = -5 .. .5)’)

        如果能正确地返回结果，则表明安装配置成功.

二）在Maple环境中调用Matlab   

• 1) 确认Matlab和Maple都已经安装。
• 2) 确认已将%MATLAB%\bin;%MATLAB%\bin\win32添加到PATH的环境变量中，其中%MATLAB%就是Matlab的安装路径。
• 3) 重新启动Maple,执行如下代码看是否正常
  

  Matlab[setvar]("x",3.14);
  Matlab[getvar]("x");

         如果能正确地返回结果，则表明安装配置成功. 

   另：我们可以注意到，随着这个的代码的执行，会自动打开一个Matlab命令行窗口。
        如果你愿意的话，可以在这个窗口中输入：x 。查看其结果，看看是否和Maple中的结果一致。
        你可以手工启动这个Matlab命令行窗口：   Matlab[openlink]();
        你可以通过Matlab[closelink](); 来关闭这个Matlab命令窗口。

三）在Matlab中调用Mathematica

• 1) 确认Matlab和Mathematica都已经安装，并且为了编译源代码还要求安装Microsoft Visual Studio
• 2) 确认已将Mathematica的安装目录添加到PATH的环境变量中。
• 3) 下载Mathematica Symbolic Toolbox for MATLAB – Version 2.0
         http://library.wolfram.com/infocenter/MathSource/5344/
      并将其中的math.zip\mathematica_for_matlab\math_windows.zip\的文件解包到%MATLAB%\toolbox\mathematica目录下,并且删除其中math.dll（因为这个文件太老，可能不适用于当前版本）
• 4) 确定Mathematica中mathlink.h所在的目录,以及ml32i1m.lib所在的目录,比如，对我的系统而言在：
  D:\Program\Mathematica\8.0\SystemFiles\Links\MathLink\DeveloperKit\Windows\CompilerAdditions\mldev32\include
  D:\Program\Mathematica\8.0\SystemFiles\Links\MathLink\DeveloperKit\Windows\CompilerAdditions\mldev32\lib
     将这两个文件复制到%MATLAB%\toolbox\mathematica中 .
     修改mathrun.m，将C:\XXX 替换为%MATLAB%\toolbox\mathematica的全路径目录
• 5) 确认Microsoft Visual Studio作为默认编译器:
       打开Matlab命令行,执行mex –setup 选择Microsoft Visual Studio作为默认编译器。(建议设置好后退出Matlab)
• 6) 再次打开Matlab命令行，将当前目录切换到%MATLAB%\toolbox\mathematica, 然后运行mathrun.m   ,这个程序将会编译math.c
       如果编译成功，确认%MATLAB%\toolbox\mathematica 已被添加到Matlab的Path路径中。 
       最后运行在Matlab环境下运行测试代码: testscript.m 确认是否配置成功.

        另：使用方法直接可参见testscript.m的代码.

四）在Mathematica中调用Matlab

• 1) 确认Matlab和Mathematica都已经安装，并且为了编译源代码还要求安装Microsoft Visual Studio
• 2) 下载 mEngine
              http://library.wolfram.com/infocenter/MathSource/4821/
          将压缩包mEngine.zip\mEngine\mEngineSource中的的文件复制到 D:\Program\Mathematica\8.0\AddOns\Applications\matlab    
          将压缩包mEngine.zip\mEngine中的的文件mEngine.m和mEngine.nb也复制到 D:\Program\Mathematica\8.0\AddOns\Applications\matlab
• 3) 确认已将%MATLAB%\bin;%MATLAB%\bin\win32添加到PATH的环境变量中，其中%MATLAB%就是Matlab的安装路径。
• 4) 打开Microsoft Visual Studio命令行环境，切换目录

cd D:\Program\Mathematica\8.0\AddOns\Applications\matlab

• 5) 在Microsoft Visual Studio命令行环境中，设置临时的编译环境(包括MathLink开发环境和Matlab开发环境)

SET MATHLINK=D:\Program\Mathematica\8.0\SystemFiles\Links\MathLink\DeveloperKit\Windows\CompilerAdditions\mldev32
SET MATENGINE=D:\Program\MATLAB\R2011a\extern
SET PATH=%PATH%;%MATHLINK%\bin\
SET INCLUDE=%INCLUDE%;%MATHLINK%\include\;%MATENGINE%\include\
SET LIB=%LIB%;%MATHLINK%\lib\;%MATENGINE%\lib\win32\microsoft

• 6) 在Microsoft Visual Studio命令行环境中，设置编译参数

SET CL=/nologo /c /DWIN32 /D_WINDOWS /W3 /O2 /DNDEBUG
SET LINK=/NOLOGO /SUBSYSTEM:windows /INCREMENTAL:no /PDB:NONE kernel32.lib user32.lib gdi32.lib

• 7) 在Microsoft Visual Studio命令行环境中， 编译生成mEngine.exe

MPREP template.tm -o templatetm.c
CL *.c
LINK *.obj ml32i3m.lib  libeng.lib libmx.lib /OUT:mEngine.exe

• 设置mEngine的Mathematica的搜索路径：
  在Mathematica中查看$BaseDirectory的值。（我系统中其值为 C:\ProgramData\Mathematica）
  然后在$BaseDirectory\Kernel\init.m中添加一行代码, 保存，重启Mathematica .

AppendTo[$Path,ToFileName[{$InstallationDirectory,"AddOns","Applications","matlab"}]]

• 9) 参考mEngine.nb学习其用法且验证安装是否成功.

        另：使用前的加载方法:  << mEngine`

© 2012, 無處不在. 版权所有.

　　就普通的HTTP代理方案而言，无论是HTTP代理还是HTTPS代理(加密的)，其实都不是安全的方案。因为HTTPS的加密仅仅是对传输的内容进行加密，而代理访问的目标网址的传输暴露在外面。仅仅对目标网址进行判断就可以使之“撞墙”。非加密HTTP代理就更不安全了。　　

　　为此需要对HTTP代理方式进行改造来保证其安全性，首先在“墙内”的本地电脑中设置一个本地HTTP代理客户端，在”墙外”电脑中设置远程HTTP代理服务端 。

　　其次，“本地HTTP代理”和“远程HTTP代理”之间交换的数据采用“准加密的压缩包”方式进行传输。“准加密的压缩包”指的是：将包括网址，内容等相关HTTP数据打包压缩后，然后对压缩包头16个字节进行3DES加密。由于是压缩包的部分加密，故我称之为“准加密压缩包”。之所以采用“准加密”的方式是出于性能的考虑。　我认为（不知是否正确？）：头16个字节进行3DES加密的压缩包是无法破解的。这样就解决了由于网址暴露而导致的不完全性。

　　其实，上述方案(我称之为“客户端式HTTP代理”)就是“自×由×门”，“无×界”采用的方案，但由于“自×由×门／“无×界”的通用性而导致其不可靠性（会被定点封锁）。

　　于是我认为，越是个性化的翻墙方式越不可能会被定点封锁。goagent这款代理是一个很好切入点，其远程HTTP代理服务端(fetch.py)搭建在GoogleAppEngine上（免费的），本地HTTP代理就是一个python程序:proxy.py. 

http://code.google.com/p/goagent/

https://github.com/phus/goagent

　　我们可以对goagent这款客户端式代理进行改造，获得一个个性化安全的翻墙工具。（注：goagent交换的数据压缩包没有加密，也就不是完全安全的）。考虑到我的翻墙安全，我就不把改造后的程序公布了。仅仅介绍一下我对goagent做了哪些改造。

１）远程HTTP代理服务端：　用Google　Go语言重新开发了，部署在GAE上，然后绑定到一个特定域名上。

２）本地和远程代理间的数据交换：采用了前述的“准加密压缩包”的形式进行传输。

３）本地HTTP代理服务端：　本想用Google　Go语言重新开发，但目前Go开发的程序还不能运行在Window操作系统下，故还是使用proxy.py。但是删除了大量代码，专注于通过远程GAE的代理。

４）保留了本地HTTPS劫持功能：在本地HTTP代理中自动伪造HTTPS证书，将用户的HTTPS请求进行劫持解密，然后按HTTP数据的“准加密压缩包”的方式传输。

５）将proxy.py原本单线程的运行模式改造成多线程的运行模式。

　　最后，你们可能会失望了，我并没有给你提供了一个拿来即用的程序，仅仅是给你一个方法。这是因为如果具体程序一旦扩散开来，最终会遇到被定点封锁的命运。GAE已经被拦在“墙外”，本人是通过特殊方式绕过了拦截，一旦扩散开来会影响到我的使用。基于我的私心，就不公布具体程序：）

© 2012, 無處不在. 版权所有.

第二章 NIO扩展

2.1. 非阻塞式I/O模型的优缺点

与一般的观点相反：当原始数据吞吐量足够大时，NIO的执行性能要明显低于阻塞式IO。所以NIO并不一定适合所有的情况，只有如下几种情况可以考虑使用NIO：

　　• 需要处理成千上万个连接，但有相当数量的连接是空闲的。

　　• 需要处理高延迟的连接。

　　• 请求/响应处理需要被解耦。

2.2. 和其它的NIO框架的区别

虽然其它的框架也解决了类似的问题，但是此框架还是有些独特的地方：

　　• 极简抽象化,针对诸如Http协议的数据进行了优化.

　　• 高效内存管理: 数据消费当且仅当需要更多数据时才读取，并且不需要分配更多的内存。

　　• 可能的话,直接访问NIO通道.

2.3. I/O反应器

译者注：I/O反应器是I/O事件层的核心。

　　HttpCore NIO是基于Reactor模式的(曾被Doug Lea描述过的模式)。I/O反应器的目的是响应I/O事件并且分派事件通知给特定的I/O会话。I/O反应器模式的主要观念：打破经典阻塞式I/O模型下的一个连接一个线程的情况。IOReactor接口描绘了一个实现Reactor模式的抽象。在内部，IOReactor的实现类封装了NIO(java.nio.channels.Selector)的功能。

I/O反应器一般会用少量调度线程(常常是一个)分派I/O事件通知给数量相当大的(常常是数千个) I/O会话或连接。而这又是被推荐的方式：每个CPU核一个调度线程.

HttpParams params = new BasicHttpParams();

int workerCount = 2;

IOReactor ioreactor = new DefaultConnectingIOReactor(workerCount,

　　　　　　　　　　　　　params);

2.3.1. I/O调度

　　IOReactor的实现会使用IOEventDispatch接口将特定会话事件通知顾客。IOEventDispatch的所有方法都在I/O反应器的一个调度线程中执行。事件方法不要堵塞调度线程太久时间，这点很重要，因为一旦被堵了，I/O 反应器将不能反应其它事件。

HttpParams params = new BasicHttpParams();

IOReactor ioreactor = new DefaultConnectingIOReactor(2, params);

IOEventDispatch eventDispatch = new MyIOEventDispatch();

ioreactor.execute(eventDispatch);

在IOEventDispatch接口中定义了一般的I/O事件:

　　• connected: 当一个新的会话被创建时触发。

　　• inputReady: 当会话即将有输入时触发。

　　• outputReady: 当会话准备输出时触发。

　　• timeout: 当会话超时触发。

　　• disconnected: 当会话已经被终止时触发。

2.3.2. I/O反应器的关闭

　　I/O反应器的关闭是一个复杂的过程，一般需要等待直到完全停止。I/O反应器将试图在指定的期限内温和地终止所有活动的I/O会话和调度线程。如果有任何I/O会话不能正确地终止，那么I/O反应器将强制关闭余下的会话。

long gracePeriod = 3000L; // milliseconds

ioreactor.shutdown(gracePeriod);

IOReactor#shutdown(long) 方法必须是线程安全的。

2.3.3. I/O会话

　　IOSession接口描绘了在两个端点(比如客户端和服务端)上进行数据交换逻辑序列。IOSession封装了NIO(java.nio.channels.SelectionKey和java.nio.channels.SocketChannel)的功能。一个通道关联一个IOSession,能够从会话中读取或写入数据。

IOSession iosession;

ReadableByteChannel ch = (ReadableByteChannel) iosession.channel();

ByteBuffer dst = ByteBuffer.allocate(2048);

ch.read(dst);

2.3.4. I/O会话的状态管理

I/O会话没有绑定到一个执行线程上，所以不能使用线程的上下文保存会话状态。特定会话的所有详情必须存储在会话自身。

IOSession iosession;

Object someState;

iosession.setAttribute(“state”, someState);

Object currentState = iosession.getAttribute(“state”);

请注意：如果数个会话使用了共享对象，那么访问这些对象必须确保线程安全。

2.3.5. I/O会话事件掩码

如果关注特定I/O会话的特定类型I/O事件，可以在此I/O会话中设置事件掩码。

IOSession iosession;

iosession.setEventMask(SelectionKey.OP_READ | SelectionKey.OP_WRITE);

也可以单独触发OP_READ 和 OP_WRITE事件。

iosession.setEvent(SelectionKey.OP_READ);

iosession.clearEvent(SelectionKey.OP_READ);

没有被设置标志位的相关事件通知不会被清空(就是原样不变)。

2.3.6. I/O会话的缓冲器

　　为了能在返回数据给客户或写数据到基础通道之前进行输入输出数据转换，I/O会话经常要操纵内部I/O缓冲。HttpCore NIO的内存管理原理是基于：数据消费者当且仅当需要更多数据时才实际读取，而不需要分配更多的内存。这意味有一些在内部或外部缓冲的未读输入数据。I/O反应器能够查询这些会话缓冲的状态，并且确保数据消费者获得正确的通知(是否还有一些存储在某个会话缓冲中的数据？)，所以允许数据消费者在能处理的时候读取这些遗留数据。I/O会话能够知道外部会话缓冲状态，方法就是使用SessionBufferStatus接口。

IOSession iosession;

SessionBufferStatus myBufferStatus = new MySessionBufferStatus();

iosession.setBufferStatus(myBufferStatus);

iosession.hasBufferedInput();

iosession.hasBufferedOutput();

2.3.7. I/O会话的关闭

　　可以调用IOSession#close()以温和有序的方式关闭I/O会话，或调用IOSession#shutdown()强制关闭I/O会话的基础通道。对具体的IOSession实现而言，上面两个方法的区别主要体现在：涉及有序的会话握手终止，比如SSL/TLS连接。

2.3.8. I/O监听反应器

ListeningIOReactor接口描述了能够在一个或多个端口上监听进站连接的I/O反应器。

ListeningIOReactor ioreactor;

ListenerEndpoint ep1 = ioreactor.listen(new InetSocketAddress(8081));

ListenerEndpoint ep2 = ioreactor.listen(new InetSocketAddress(8082));

ListenerEndpoint ep3 = ioreactor.listen(new InetSocketAddress(8083));

// Wait until all endpoints are up

ep1.waitFor();

ep2.waitFor();

ep3.waitFor();

　　一个端点一旦完全初始化，就能开始够接受进站连接，并且能够将I/O活动通知给IOEventDispatch接口。

也能够获得运行时已注册的端点集，能够查询运行时的一个端点的状态，并且也能够关闭它。

ListeningIOReactor ioreactor;

Set<ListenerEndpoint> eps = ioreactor.getEndpoints();

for (ListenerEndpoint ep: eps) {

　　// Still active?

　　System.out.println(ep.getAddress());

　　if (ep.isClosed()) {

　　　　// If not, has it terminated due to an exception?

　　　　if (ep.getException() != null) {

　　　　　　ep.getException().printStackTrace();

　　　　}

　　} else {

　　　　ep.close();

　　}

}

2.3.9. I/O连接反应器

ConnectingIOReactor描绘了一个能够和远端主机建立连接的I/O反应器。

ConnectingIOReactor ioreactor;

SessionRequest sessionRequest = ioreactor.connect(

　　　　　　　　new InetSocketAddress(“www.google.com”, 80),

　　　　　　　　null, null, null);

打开一个到远端主机的连接通常要消耗一定的处理时间来确保其完成。然后通过SessionRequest接口来监控在建立连接过程中的会话初始化。

// Make sure the request times out if connection

// has not been established after 1 sec

sessionRequest.setConnectTimeout(1000);

// Wait for the request to complete

sessionRequest.waitFor();

// Has request terminated due to an exception?

if (sessionRequest.getException() != null) {

　　sessionRequest.getException().printStackTrace();

}

// Get hold of the new I/O session

IOSession iosession = sessionRequest.getSession();

预期SessionRequest的实现是线程安全的。会话请求可以在任何时刻在其它线程中通过调用IOSession#cancel()而中止。

if (!sessionRequest.isCompleted()) {

　　sessionRequest.cancel();

}

　　可以通过ConnectingIOReactor#connect()的可选参数来控制会话的初始化处理。

一个非空的本地socket地址参数可以被用来将socket绑定到特定的本地地址上(connect的第二个参数)。

ConnectingIOReactor ioreactor;

SessionRequest sessionRequest = ioreactor.connect(

　　new InetSocketAddress(“www.google.com”, 80),

　　new InetSocketAddress(“192.168.0.10″, 1234),

　　null, null);

可以将一个附件对象通过connect的第三个参数绑定到返回SessionRequest中所携带的会话上。

SessionRequest sessionRequest = ioreactor.connect(

　　new InetSocketAddress(“www.google.com”, 80),

　　null, new HttpHost(“www.google.ru”), null);

IOSession iosession = sessionRequest.getSession();

HttpHost virtualHost = (HttpHost) iosession.getAttribute(

　　IOSession.ATTACHMENT_KEY);

　　也可以令人满意地进行异步连接而无需等待，不会堵塞当前线程的执行。可以通过SessionRequestCallback接口作为connect的第四个参数来实现这点。通过这个接口可以获得关于SessionRequest的事件，比如：请求完成(completed(…))，取消(cancelled(…))，失败(failed(…))和超时(timeout(…))。

ConnectingIOReactor ioreactor;

SessionRequest sessionRequest = ioreactor.connect(

　　new InetSocketAddress(“www.google.com”, 80), null, null,

　　new SessionRequestCallback() {

　　　　public void cancelled(SessionRequest request) {

　　　　}

　　　　public void completed(SessionRequest request) {

　　　　　　System.out.println(“new connection to ” +

　　　　　　request.getRemoteAddress());

　　　　}

　　　　public void failed(SessionRequest request) {

　　　　　　if (request.getException() != null) {

　　　　　　　　request.getException().printStackTrace();

　　　　　　}

　　　　}

　　　　public void timeout(SessionRequest request) {

　　　　}

　　});

2.3.10. 队列化的I/O interest集操作

　　有几个老的JRE实现(主要是来自IBM的实现,可以参考Java API文档中关于java.nio.channels.SelectionKey类本地实现的注解)。java.nio.channels.SelectionKey在这些JRE上问题是：如果正在进行某个选择操作，那么读取或写入 interest 集合可能会无限期地阻塞。在上述特殊情况下，HttpCore NIO能够配置在调度线程中以队列化的方式执行interest 集合的操作，当然是在I/O selector的select操作不忙的时候实质执行

HttpParams params = new BasicHttpParams();

NIOReactorParams.setInterestOpsQueueing(params, true);

ListeningIOReactor ioreactor = new DefaultListeningIOReactor(2, params);

2.4. I/O反应器的异常处理

　　和I/O异常类似，协议层的异常也是一种和会话通道交互过程中抛出的异常。可预期由特殊的协议处理者(protocol handlers)进行处理。这些异常可能会导致个别会话终止，但应该不会影响到I/O反应器和其他活动的会话。然而也可能有另外一种情况：I/O反应器自身遭遇到一个内部错误(比如基础NIO类的I/O异常或者一个未处理的运行时异常)。这种类型的异常通常是致命的，并且会导致I/O反应器自动关闭。

当然还是有可能通过重载一些行为来阻止I/O反应器由于运行时异常或内部类的I/O异常而导致的自动停机。那就是技巧性的定制IOReactorExceptionHandler接口的一个实现。

DefaultConnectingIOReactor ioreactor;

ioreactor.setExceptionHandler(new IOReactorExceptionHandler() {

　　public boolean handle(IOException ex) {

　　　　if (ex instanceof BindException) {

　　　　　　// bind failures considered OK to ignore

　　　　　　return true;

　　　　}

　　　　return false;

　　}

　　public boolean handle(RuntimeException ex) {

　　　　if (ex instanceof UnsupportedOperationException) {

　　　　　　// Unsupported operations considered OK to ignore

　　　　　　return true;

　　　　}

　　　　return false;

　　}

});

需要非常小心对待不加区别地异常丢弃。让I/O反应器关闭自身再干净地重启，通常要好于在不一致的或不稳定状态下继续运行。

2.4.1. I/O反应器的旁听日志

　　如果I/O反应器不能够自动地从运行时或I/O异常中恢复过来，那么她将会进入shutdown模式。首先，她将关闭活动的监听反应器并且取消即将的会话请求。然后她将试图在给定时间期限下温和地关闭活动的I/O会话，以便刷新输出和终止前的清理工作。最后，超过时间期限，她将强制关闭余下活动I/O会话。这是一个相当复杂的过程。可能会导致许多失败，抛出很多异常甚至导致关闭整个进程(如果我只希望关闭单个反应器，那么关闭整个进程就不是我们希望看到的)。I/O反应器将会记录这些在关闭过程抛出的异常和导致进入shutdown模式的异常，这些异常保存在一个旁听日志(audit log)对象中。可以通过检查这个日志对象来决定是否能安全地重新启动I/O反应器。

DefaultConnectingIOReactor ioreactor;

// Give it 5 sec grace period

ioreactor.shutdown(5000);

List<ExceptionEvent> events = ioreactor.getAuditLog();

for (ExceptionEvent event: events) {

　　System.err.println(“Time: ” + event.getTimestamp());

　　event.getCause().printStackTrace();

}

2.5. 非阻塞式HTTP连接

　　一个有效的非阻塞式HTTP连接封装了满足HTTP规范的IOSession。非阻塞式HTTP连接是有状态的，但不是线程安全的。非阻塞式HTTP连接的输入/输出操作应该被严格限制：由同一个I/O 调度线程来执行其触发的所有调度事件。

2.5.1. 非阻塞式HTTP连接的执行上下文

　　非阻塞式HTTP连接不是绑定在一个特定的线程上执行，所以它们需要维持自己的执行上下文。每个非阻塞式HTTP连接有一个关联的HttpContext实例，它可被用来维护一个处理状态。这个HttpContext实例是线程安全的，能够被多个线程操作。

// Get non-blocking HTTP connection

DefaultNHttpClientConnection conn;

// State

Object myStateObject;

HttpContext context = conn.getContext();

context.setAttribute(“state”, myStateObject);

2.5.2. 非阻塞式HTTP连接的工作

　　在任何时刻，都能够获得非阻塞式HTTP连接的请求和响应对象，无论这些对象是否已经被传递了。如果当前还没有进站或出站的消息传输，获取到的任何请求或响应对象可能是空，甚至可能同时为空。

NHttpConnection conn;

HttpRequest request = conn.getHttpRequest();

if (request != null) {

　　System.out.println(“Transferring request: ” +

　　request.getRequestLine());

}

HttpResponse response = conn.getHttpResponse();

if (response != null) {

　　System.out.println(“Transferring response: ” +

　　response.getStatusLine());

}

　　无论如何，请注意的是当前请求和当前响应并不必然表示发生了同样的消息交换。非阻塞式HTTP连接能在完全双工模式下操作。可以完全相互独立地处理进站和出站消息。这使得非阻塞式HTTP连接能够完全管道化，但是也意味着匹配请求和响应的逻辑关系也是协议处理者(protocol handler)的工作。

在客户端的简单请求提交过程，看起来像：

// Obtain HTTP connection

NHttpClientConnection conn;

// Obtain execution context

HttpContext context = conn.getContext();

// Obtain processing state

Object state = context.getAttribute(“state”);

// Generate a request based on the state information

HttpRequest request = new BasicHttpRequest(“GET”, “/”);

conn.submitRequest(request);

System.out.println(conn.isRequestSubmitted());

服务端的简单响应提交过程，看起来像：

// Obtain HTTP connection

NHttpServerConnection conn;

// Obtain execution context

HttpContext context = conn.getContext();

// Obtain processing state

Object state = context.getAttribute(“state”);

// Generate a response based on the state information

HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1,

HttpStatus.SC_OK, “OK”);

BasicHttpEntity entity = new BasicHttpEntity();

entity.setContentType(“text/plain”);

entity.setChunked(true);

response.setEntity(entity);

conn.submitResponse(response);

System.out.println(conn.isResponseSubmitted());

请注意的是：使用低级别的方法进行消息传输是很少见的，并且应该使用高级别Http服务(service)的实现来代替。

2.5.3. HTTP的I/O控制

　　所有的非阻塞式HTTP连接类都实现了IOControl接口，该接口作为连接功能的子集能够控制其关注的I/O事件通知。IOControl实例能够完全线程安全地执行。所以IOControl能够在任何线程上request / suspend I/O事件通知。

　　必须小心谨慎地对待和非阻塞式连接的交互。HttpRequest和HttpResponse不是线程安全的。一般而言，将某个非阻塞式连接上所有的输入输出操作都限制在同一个I/O事件调度线程上执行的方式是明智的。

推荐的几种模式：

　　• 使用IOControl接口从另外一个线程/会话来控制连接的I/O事件。

　　• 如果输入输出操作需要在一个特定的连接上执行，那么需要在连接上下文中存储所有的请求信息(状态)，并且通过调用IOControl#requestInput()或IOControl#requestOutput()方法来发起适当的请求操作。

　　• 使用存储在连接上的上下文信息，在调度线程事件方法中执行请求操作。

请注意：发生在事件方法中的所有操作不应该阻塞太长时间，因为一旦调度线程在一个会话中被堵塞，它将不能处理所有其他会话中的事件。会话的基础通道的I/O操作能够保证其非堵塞性。

2.5.4. 非阻塞式内容传递

　　非阻塞式连接上的内容传输过程的工作完全不同于阻塞式连接，作为非阻塞式连接需要适应NIO模型的自然异步性。两种连接类型最主要的区别是：无法使用平常的，但具有内在阻塞性的java.io.InputStream和 java.io.OutputStream类(在这里被用来作为内容的输入输出流)。HttpCore NIO提供了ContentEncoder和ContentDecoder接口来处理异步内容传输过程。非阻塞式HTTP连接将实例化一个恰当的内容编解码器(content codec),它是消息体的一个属性。

非阻塞式HTTP连接将激活输入事件，直到消息体的内容完全被传输。

//Obtain content decoder

ContentDecoder decoder;

//Read data in

ByteBuffer dst = ByteBuffer.allocate(2048);

decoder.read(dst);

// Decode will be marked as complete when

// the content entity is fully transferred

if (decoder.isCompleted()) {

　　// Done

}

非堵塞式HTTP连接将激活输出事件，直到消息体的内容已被标记为完全传输。

// Obtain content encoder

ContentEncoder encoder;

// Prepare output data

ByteBuffer src = ByteBuffer.allocate(2048);

// Write data out

encoder.write(src);

// Mark content entity as fully transferred when done

encoder.complete();

请注意：可用HttpEntity的一个实例作为消息体，将一个含消息体的消息提交到非阻塞式HTTP连接。用消息体的属性初始化一个ContentEncoder实例进行消息体内容传输。然而，非堵塞式HTTP连接会忽略内在阻塞性的方法HttpEntity#getContent()和HttpEntity#writeTo()。

// Obtain HTTP connection

NHttpServerConnection conn;

HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1,

　　HttpStatus.SC_OK, “OK”);

BasicHttpEntity entity = new BasicHttpEntity();

entity.setContentType(“text/plain”);

entity.setChunked(true);

entity.setContent(null);

response.setEntity(entity);

conn.submitResponse(response);

同样，含消息体的进站消息也将有一个HttpEntity 实例相关联，但调用HttpEntity#getContent()或HttpEntity#writeTo()的企图会导致java.lang.IllegalStateException。根据HttpEntity实例可以确定诸如content length之类的进站消息体性质。

// Obtain HTTP connection

NHttpClientConnection conn;

HttpResponse response = conn.getHttpResponse();

HttpEntity entity = response.getEntity();

if (entity != null) {

　　System.out.println(entity.getContentType());

　　System.out.println(entity.getContentLength());

　　System.out.println(entity.isChunked());

}

2.5.5. 支持的非阻塞式内容传递机制

非阻塞式HTTP连接的默认实现支持三种内容传输机制（定义在HTTP/1.1规范中):

　　• 由Content-Length确定:消息体的终止由消息头中Content-Length的值确定.最大消息体长度: Long#MAX_VALUE。

　　• 标识码：消息体的终止由基础连接的关闭决定(流终止条件)。基于明显的原因，标识码只能用在服务端。最大消息体长度：无限制。

　　• 成块编码 (Chunk coding)：内容被成块发送。最大实体长度：无限制。

一个恰当的内容编解码器(content codec)会根据消息体性质自动创建。

I/O反应器，I/O会话和I/O事件调度，他们三者的关系”心脏－血液－肢体”的关系。　

2.5.6. 直接通道I/O

　　内容编码器优化了从I/O会话基础通道的直接数据读取或数据写入，任何时候都可能绕过会话的缓冲，此外这些不执行任何转换(Content-Length限定和标识码等)的编解码器能够有效地利用NIO java.nio.FileChannel的方法提高入站/出站数据的传输性能。

译者注：在这个数据的转换过程中，可以在完全进行数据读写完毕后进行适当的代码处理。在这个内容的传递机制的过程中，完成这个的函数的分析过程。对

一个实际的内容解码器实现FileContentDecoder就能够直接读取文件入站内容，并且绕过了中间缓冲java.nio.ByteBuffer。

//Obtain content decoder

ContentDecoder decoder;

//Prepare file channel

FileChannel dst;

//Make use of direct file I/O if possible

if (decoder instanceof FileContentDecoder) {

　　long Bytesread = ((FileContentDecoder) decoder)

　　　　.transfer(dst, 0, 2048);

　　// Decode will be marked as complete when

　　// the content entity is fully transmitted

　　if (decoder.isCompleted()) {

　　　　// Done

　　}

}

一个实际的内容编码器实现FileContentEncoder就能够直接写出站内容到文件，并且绕过了中间缓冲java.nio.ByteBuffer.。

// Obtain content encoder

ContentEncoder encoder;

// Prepare file channel

FileChannel src;

// Make use of direct file I/O if possible

if (encoder instanceof FileContentEncoder) {

　　// Write data out

　　long bytesWritten = ((FileContentEncoder) encoder)

　　　　.transfer(src, 0, 2048);

　　// Mark content entity as fully transferred when done

　　encoder.complete();

}

2.6. HTTP I/O事件调度

译者注：HTTP I/O事件调度是I/O事件转换成HTTP协议事件中介。

　　HTTP I/O事件调度器可通过I/O反应器将一般的已触发I/O事件转换为特定的HTTP协议事件。他们依赖NHttpClientHandler和NHttpServiceHandler接口将HTTP协议事件传递给HTTP协议处理(handler).

NHttpServiceHandler接口定义了服务端HTTP I/O事件：

　　•connected: 当一个新的进站连接成功建立后触发。

　　•requestReceived: 当已经接收到一个HTTP请求时触发。通过本方法的参数(NHttpServerConnection)可以确保获得一个有效的HttpRequest对象。如果已经接收的请求包含消息体,那么这个方法随后会有一系列inputReady事件来传输请求消息体的内容。

　　•inputReady: 当已经准备好从基础通道中读请求消息体新的部分(经过内容解码器)时触发。如果内容消费不能处理这些入站内容，那么能够使用IOControl接口将输入事件通知临时性挂起。

　　•responseReady: 当连接已经准备接受新的HttpResponse时触发。如果连接没有准备好，那么协议处理者(handler)是不能提交响应的。

　　•outputReady: 当基础通道已经准备好写入响应消息体的下一个部分(经过内容编码器)时触发。如果内容生产者不能产生出站内容，那么能够使用IOControl接口将输出事件通知临时性挂起。

　　•exception: 当读写基础通道发生一个I/O错误时，或者在接受HttpRequest发生HTTP协议违反时触发。

　　•timeout: 当在设定的时间期限内没有探测到输入时触发。

　　•closed: 当连接已经被关闭时触发。

NHttpClientHandler接口定义了客户端HTTP I/O事件：

　　•connected: 当出站连接已成功建立时触发。作为参数的附件对象就是会话请求(SessionRequest)的附件。

　　•requestReady: 当连接已经准备好接受HTTP请求时触发。如果连接没有准备好，那么协议处理者(handle)是不能提交请求的。

　　•outputReady: 当基础通道已准备写入请求消息体的下一个部分(通过内容编码器)时触发。如果内容生产者不能产生出站内容，那么能够使用IOControl接口将输出事件通知临时性挂起。

　　•responseReceived: 当一个HttpResponse被接受时触发。通过本方法的参数(NHttpClientConnection)可以确保获得一个有效的HttpResponse对象。如果已经接收的响应包含消息体,那么这个方法随后会有一系列inputReady事件来传输响应消息体的内容。

　　•inputReady: 当已经准备好从基础通道中读响应消息体新的部分(通过内容解码器)时触发。如果内容消费不能处理这些入站内容，那么能够使用IOControl接口将输入事件通知临时性挂起。

　　•exception: 当读写基础通道发生一个I/O错误时，或者在接受HttpResponse发生HTTP协议违反时触发。

　　•timeout: 当在设定的时间期限内没有探测到输入时触发。

　　•closed: 当连接已经被关闭时触发。

2.7. 非阻塞式HTTP消息体

　　前面的讨论已经提及：非阻塞式连接的工作过程和阻塞式连接完全不一样。一个明显的原因是经典I/O抽象是基于具有内在阻塞性的java.io.InputStream和java.io.OutputStream两个类，不能处理异步数据传输。所以非阻塞式HTTP消息体提供了对HttpEntity接口进行NIO特殊扩展的接口：ProducingNHttpEntity和ConsumingNHttpEntity。

　　如果接口的特定实现类不能从java.io.InputStream实例获得内容流或不能将内容流写入java.io.OutputStream，那么可能会从HttpEntity#getContent()和HttpEntity#writeTo()抛出java.lang.UnsupportedOperationException。

2.7.1. 消费性内容的非阻塞式HTTP消息体

ConsumingNHttpEntity接口描绘了允许从内容解码器消费的非阻塞式消息体。

ConsumingNHttpEntity继承自HttpEntity接口，新添几个特定的NIO通知方法:

　　•consumeContent: 有可消费内容的通知。通过ContentDecoder(第一个参数)获得有效可读内容。如果出现临时性的消息体不能为进站内容分配更多存储的情况，那么可通过IOControl(第二个参数)挂起输入事件。

　　•finish: 由于读而分配的资源的释放通知。

HttpCore NIO提供的ConsumingNHttpEntity实现：

　　•BufferingNHttpEntity

　　•ConsumingNHttpEntityTemplate

2.7.1.1. BufferingNHttpEntity

　　BufferingNHttpEntity是HttpEntityWrapper的子类，它将所有进站内容存储进内存。一旦消息体内容完全被接受，就可以通过HttpEntity#getContent()获得java.io.InputStream，或者通过HttpEntity#writeTo()写到输出流。

2.7.1.2. ConsumingNHttpEntityTemplate

ConsumingNHttpEntityTemplate是HttpEntityWrapper的子类，它装饰了入站HttpEntity并且委托ContentListener实例来处理入站内容。

static class FileWriteListener implements ContentListener {

　　private final FileChannel fileChannel;

　　private long idx = 0;

　　public FileWriteListener(File file) throws IOException {

　　　　this.fileChannel = new FileInputStream(file).getChannel();

　　}

　　public void contentAvailable(

　　　　ContentDecoder decoder, IOControl ioctrl) throws IOException {

　　　　long transferred;

　　　　if (decoder instanceof FileContentDecoder) {

　　　　　　transferred = ((FileContentDecoder) decoder).transfer(

　　　　　　　　fileChannel, idx, Long.MAX_VALUE);

　　　　} else {

　　　　　　transferred = fileChannel.transferFrom(

　　　　　　　　new ContentDecoderChannel(decoder),

　　　　　　　　idx, Long.MAX_VALUE);

　　　　}

　　　　if (transferred > 0) {

　　　　idx += transferred;

　　　　}

　　}

　　public void finished() {

　　　　try {

　　　　　　fileChannel.close();

　　　　} catch(IOException ignored) {}

　　}

}

HttpEntity incomingEntity;

File file = new File(“buffer.bin”);

ConsumingNHttpEntity entity = new ConsumingNHttpEntityTemplate(

　　　　incomingEntity,

　　　　new FileWriteListener(file));

2.7.2. 生产性内容的非阻塞式HTTP消息体

ProducingNHttpEntity接口描绘了允许内容写到内容编码器的非阻塞式实体。

ProducingNHttpEntity继承至HttpEntity接口，新添几个特定的NIO通知方法:

　　•produceContent: 内容可以写到编码器(第一个参数)的通知。如果消息体生产过多的内容，那么可通过IOControl(第二个参数)临时性挂起输出事件。请注意：必须调用ContentEncoder#complete()通知基础连接：所有的内容已经写完。如果不这样做，可能会导致不正确的消息体界定。

　　•finish: 由于写而分配的资源的释放通知。

HttpCore NIO提供的ProducingNHttpEntity实现：

　　• NByteArrayEntity

　　• NStringEntity

　　• NFileEntity

2.7.2.1. NByteArrayEntity

这是一个简单的自包含可重复消息体,它从字节数组中接受它的内容。这个字节数组被提供给构造函数。

String myData = “Hello world on the other side!!”;

NByteArrayEntity entity = new NByteArrayEntity(myData.getBytes());

2.7.2.2. NStringEntity

这是一个简单的自包含可重复消息体,它从java.lang.String对象中获得它的数据。它有两个构造函数，一个简单地用给定的字符串为参数的构造函数，另一个同时指定了字符串数据的字符编码。

String myData = “Hello world on the other side!!”;

// construct without a character encoding

NStringEntity myEntity1 = new NStringEntity(myData);

// alternatively construct with an encoding

NStringEntity myEntity2 = new NStringEntity(myData, “UTF-8″);

2.7.2.3. NFileEntity

这个实体从文件中读取内容体。这个类最常用在各种类型大文件流上，所以需要支持文件的内容类型，以确保能正确地验证和接受处理。

File staticFile = new File(“/path/to/myapp.jar”);

NFileEntity entity = new NFileEntity(staticFile,

　　　　”application/java-archive”);

NFileEntity将尽可能使用直接通道I/O,提供的内容编码器能够直接从文件传输数据到基础连接的socket。

2.8. 非阻塞式HTTP协议处理

2.8.1. 服务端异步HTTP协议处理

　　AsyncNHttpServiceHandle是一个完全异步的服务端HTTP协议处理者，它实现了HTTP协议中服务端消息处理的基本需求(RFC2616)。对特定的HTTP连接而言，AsyncNHttpServiceHandler具有在接近常数内存消耗下处理HTTP请求的能力。当使用ConsumingNHttpEntity或ProducingNHttpEntity将消息体的内容直接从消息体流向基础通道(或相反方向)时，这个处理者在内存中保存了HTTP消息头。

　　当使用这个实现时，必须保证消息体支持并实现了ProducingNHttpEntity的写。这样做将允许消息体进行异步写。如果消息体所支持的写没有实现ProducingNHttpEntity接口，那么一个委托会被添加：全部的内容会缓存在内存中。此外，这个缓存动作可能会发生在I/O调度线程中，可能会导致I/O暂时性阻塞。最好是，确保NHttpRequestHandler中，在HTTP响应中设置的所有的消息体都实现了ProducingNHttpEntity 接口。

　　如果进站请求附带有消息体,NHttpRequestHandler接口被期望能返回一个ConsumingNHttpEntity,便于读内容。在消息体完成数据读后，NHttpRequestHandler#handle()会被调用生成响应。

　　AsyncNHttpServiceHandler依赖于HttpProcessor对出站消息生成的消息头，以及对所有进站/出站消息进行一般的，交叉的消息转换，然而个别的HTTP请求处理者还被期望能够照顾到特定内容的生成和处理。

HttpParams params;

// Initialize HTTP parameters

HttpProcessor httpproc;

// Initialize HTTP processor

AsyncNHttpServiceHandler handler = new AsyncNHttpServiceHandler(

　　　　httpproc,

　　　　new DefaultHttpResponseFactory(),

　　　　new DefaultConnectionReuseStrategy(),

　　　　params);

2.8.1.1. 非阻塞式HTTP请求处理者

　　NHttpRequestHandler接口描绘了特定的一类非阻塞式HTTP请求的处理程序。NHttpRequestHandler的实现被期望能够实现协议方面或应用方面的特殊需求。请求处理者的主要目的是根据请求产生能够响应给客户端一个含消息体的响应对象。

NHttpRequestHandler myRequestHandler = new NHttpRequestHandler() {

　　public ConsumingNHttpEntity entityRequest(

　　　　HttpEntityEnclosingRequest request,

　　　　HttpContext context) throws HttpException, IOException {

　　　　// Buffer incoming content in memory for simplicity

　　　　return new BufferingNHttpEntity(request.getEntity(),

　　　　new HeapByteBufferAllocator());

　　}

　　public void handle(

　　　　HttpRequest request,

　　　　HttpResponse response,

　　　　NHttpResponseTrigger trigger,

　　　　HttpContext context) throws HttpException, IOException {

　　　　　　response.setStatusCode(HttpStatus.SC_OK);

　　　　　　response.addHeader(“Content-Type”, “text/plain”);

　　　　　　response.setEntity(new NStringEntity(“some important message”));

　　　　　　// Submit response immediately for simplicity

　　　　　　trigger.submitResponse(response);

　　}

};

请求处理者的实现必须是线程安全的。和servlet相似，请求处理者不应该使用实例变量，除非要同步化访问其变量。

2.8.1.2. 异步响应触发器

　　非阻塞式和阻塞式请求处理者最根本的差别是：延迟给客户端响应，而不阻塞I/O线程并将HTTP请求的处理过程转交给工作者线程的能力。一旦响应变得可用，工作者线程能够在随后的时刻，使用含参数NHttpResponseTrigger 的NHttpRequestHandler#handle方法来提交响应。

NHttpRequestHandler myRequestHandler = new NHttpRequestHandler() {

　　public ConsumingNHttpEntity entityRequest(

　　　　HttpEntityEnclosingRequest request,

　　　　HttpContext context) throws HttpException, IOException {

　　　　　　// Buffer incoming content in memory for simplicity

　　　　　　return new BufferingNHttpEntity(request.getEntity(),

　　　　　　new HeapByteBufferAllocator());

　　}

　　public void handle(

　　　　HttpRequest request,

　　　　HttpResponse response,

　　　　NHttpResponseTrigger trigger,

　　　　HttpContext context) throws HttpException, IOException {

　　　　　　new Thread() {

　　　　　　　　@Override

　　　　　　　　public void run() {

　　　　　　　　　　try {

　　　　　　　　　　　　Thread.sleep(10);

　　　　　　　　　　}catch(InterruptedException ie) {}

　　　　　　　　　　try {

　　　　　　　　　　　　URI uri = new URI(request.getRequestLine().getUri());

　　　　　　　　　　　　response.setStatusCode(HttpStatus.SC_OK);

　　　　　　　　　　　　response.addHeader(“Content-Type”, “text/plain”);

　　　　　　　　　　　　response.setEntity(

　　　　　　　　　　　　　　new NStringEntity(“some important message”));

　　　　　　　　　　　　　　trigger.submitResponse(response);

　　　　　　　　　　} catch(URISyntaxException ex) {

　　　　　　　　　　trigger.handleException(

　　　　　　　　　　　　new HttpException(“Invalid request URI: ” +

　　　　　　　　　　　　　　ex.getInput()));

　　　　　　　　　　}

　　　　　　　　}

　　　　　　}.start();

　　}

};

请注意：HttpResponse对象并非是线程安全的，不能发生同时性修改。非阻塞式请求处理则必须确保HttpResponse不能在同一时刻被多个线程访问。

2.8.1.3. 非阻塞式请求处理者解析器

　　非阻塞是HTTP请求处理者的管理和阻塞式HTTP请求处理则很类似。通常是使用NHttpRequestHandlerResolver的实例来维护请求处理者的注册，并且匹配请求URI到一个特定的请求处理者。HttpCore只包括一个非常简单的NHttpRequestHandlerResolver实现，它基于一个简单而琐碎的模式匹配算法：NHttpRequestHandlerRegistry支持三种格式：*, <uri>* 和*<uri>。

// Initialize asynchronous protocol handler

AsyncNHttpServiceHandler handler;

NHttpRequestHandlerRegistry handlerResolver =

new NHttpRequestHandlerRegistry();

handlerReqistry.register(“/service/*”, myRequestHandler1);

handlerReqistry.register(“*.do”, myRequestHandler2);

handlerReqistry.register(“*”, myRequestHandler3);

handler.setHandlerResolver(handlerResolver);

鼓励用户提供一个更精致稳健的NHttpRequestHandlerResolver实现，比如基于正则表达式的实现。

2.8.2. 客户端异步HTTP协议处理

　　AsyncNHttpClientHandler是一个完全异步的客户端HTTP协议处理者，它实现了HTTP协议中客户端消息处理的基本需求(RFC2616)。对特定的HTTP连接而言，AsyncNHttpClientHandler具有在接近常数内存消耗下处理HTTP请求的能力。当使用ConsumingNHttpEntity或ProducingNHttpEntity将消息体的内容直接从消息体流向基础通道(或相反方向)时，这个处理者在内存中保存了HTTP消息头。

　　当使用这个实现时，必须保证消息体支持实现了ProducingNHttpEntity的写。这样做将允许消息体进行异步写。如果消息体所支持的写没有实现ProducingNHttpEntity接口，那么一个委托会被添加：全部的内容会缓存在内存中。此外，这个缓存动作可能会发生在I/O调度线程中，可能会导致I/O暂时性阻塞。最好是，确保NHttpRequestExecutionHandler中，在HTTP请求中设置的所有的消息体都实现了ProducingNHttpEntity 接口。

　　如果进站响应附带有消息体, NHttpRequestExecutionHandler接口期望返回一个ConsumingNHttpEntity,便于读取内容。在消息体完成数据读后，NHttpRequestExecutionHandler#handleResponse()会被调用处理响应。

　　AsyncNHttpClientHandler依赖于HttpProcessor对出站消息生成的消息头，以及对所有进站/出站消息进行一般，交叉的消息转换，然而个别的HTTP请求处理者还被期望能够照顾到特定内容的生成和处理。

// Initialize HTTP parameters

HttpParams params;

//Initialize HTTP processor

HttpProcessor httpproc;

//Create HTTP request execution handler

NHttpRequestExecutionHandler execHandler;

AsyncNHttpClientHandler handler = new AsyncNHttpClientHandler(

　　　　　　httpproc,

　　　　　　execHandler,

　　　　　　new DefaultConnectionReuseStrategy(),

　　　　　　params);

2.8.2.1. 异步HTTP请求执行处理者

　　异步HTTP请求执行处理者被当作客户端的协议处理者，用来触发新的HTTP请求的提交和HTTP响应的处理。

HTTP请求执行事件定义在NHttpRequestExecutionHandler接口中：

　　•initalizeContext: 当一个新的连接成功建立并且HTTP上下文初始化完毕时触发。这个方法的第二个参数(一个附件对象)就是ConnectingIOReactor#connect()第三个参数对应的附件对象。这个可能存在的附件对象可能包含一些为了正确初始化HTTP上下文所需要的状态信息。

　　•submitRequest: 当基础连接已经准备好发送一个新的HTTP请求到目标主机时触发。如果客户端还没有准备好发送一个请求时，这个方法可能会返回一个null。在这种情况下，连接将保持打开并且稍后能被激活。如果请求包含消息体，那么这个消息体必须是一个ProducingNHttpEntity实例。

　　•responseEntity: 当含消息体的响应已经被接受时触发。这个方法应该返回一个ConsumingNHttpEntity(一个可消费的消息体)。响应值能为null,这表示消息体应该被忽略。在消息体完全被消费后，handleResponse方法会被调用来通知完整的含消息体的响应已经准备好被处理。

　　•handleResponse: 当HTTP响应已经准备好被处理时触发。

　　•finalizeContext: 当连接被终止时触发。这个事件能被用来释放已经存储在上下文的对象或执行其他的一些清理工作。

NHttpRequestExecutionHandler execHandler =

　　new NHttpRequestExecutionHandler() {

　　　　private final static String DONE_FLAG = “done”;

　　　　public void initalizeContext(

　　　　　　HttpContext context,

　　　　　　Object attachment) {

　　　　　　　　if (attachment != null) {

　　　　　　　　　　HttpHost virtualHost = (HttpHost) attachment;

　　　　　　　　　　context.setAttribute(ExecutionContext.HTTP_TARGET_HOST,

　　　　　　　　　　　　virtualHost);

　　　　　　　　}

　　　　}

　　　　public void finalizeContext(HttpContext context) {

　　　　　　context.removeAttribute(DONE_FLAG);

　　　　}

　　　　public HttpRequest submitRequest(HttpContext context) {

　　　　　　// Submit HTTP GET once

　　　　　　Object done = context.getAttribute(DONE_FLAG);

　　　　　　if (done == null) {

　　　　　　　　context.setAttribute(DONE_FLAG, Boolean.TRUE);

　　　　　　　　return new BasicHttpRequest(“GET”, “/”);

　　　　　　} else {

　　　　　　　　return null;

　　　　　　}

　　　　}

　　　　public ConsumingNHttpEntity responseEntity(

　　　　　　HttpResponse response,

　　　　　　HttpContext context) throws IOException {

　　　　　　　　// Buffer incoming content in memory for simplicity

　　　　　　　　return new BufferingNHttpEntity(response.getEntity(),

　　　　　　　　　　new HeapByteBufferAllocator());

　　　　}

　　　　public void handleResponse(

　　　　　　HttpResponse response,

　　　　　　HttpContext context) throws IOException {

　　　　　　　　System.out.println(response.getStatusLine());

　　　　　　　　if (response.getEntity() != null) {

　　　　　　　　　　System.out.println(EntityUtils.toString(response.getEntity()));

　　　　}

　　}

};

2.8.3. 兼容阻塞式I/O

　　除了上述异步协议处理者，HttpCore还提供了两种HTTP协议处理者，它们在非阻塞上层模拟了阻塞式I/O模型，允许消息内容使用标准的java.io.OutputStream和java.io.InputStream的API进行数据的生产和消费。兼容后的协议处理者能够工作在含阻塞式HttpEntity的HTTP请求处理则和请求执行者环境下。

　　兼容后的协议处理者依赖于HttpProcessor对出站消息生成的消息头，以及对所有进站/出站消息进行一般的，交叉的消息转换，然而个别的HTTP请求执行者/处理者还被期望能够照顾到特定内容的生成和处理。

2.8.3.1. 缓冲式协议处理者

　　BufferingHttpServiceHandler和BufferingHttpClientHandler就是实现了兼容阻塞式I/O模型并将HTTP消息完整内容都存储在内存中的协议处理者。请求/响应回调处理只在当完整消息内容都被读到内存缓冲器中才激活。请注意：请求执行/请求处理会占用主I/O线程，所以个别请求执行者/请求处理者必须确保他们不会无限期阻塞。

　　缓冲式协议处理者应该只能用在长度有限的HTTP消息交换的情况下。

2.8.3.2. 流控式协议处理者

　　ThrottlingHttpServiceHandler和ThrottlingHttpClientHandler就是实现了兼容阻塞式I/O模型的另两个协议处理者，他们利用共享的内容缓冲器和一个小型的工作者线程池。这个流控式协议处理者初始化时分配了固定长度的输入/输出缓冲器,并且控制I/O事件的速率，目的是确保这些缓冲器不会溢流。这些有助于在内容流进和流出条件下，HTTP连接能保持接近常数内存，也避免了内存溢出。请求/响应的回调处理将在消息已被接受的时候立刻激活。流控制式协议处理者委托请求处理/生成响应的任务给执行者，这些执行者被期望使用工作者线程执行这些任务，从而避开阻塞I/O线程的可能。

　　通常流控式协议处理者只需要适当数量的工作者线程，大大小于并发连接数。如果消息的长度较小或者有一个恰当尺寸的共享的内容缓冲器，那么的工作者线程正好将内容存储在缓冲器中后立刻中止，而不会阻塞。I/O调度线程将专注于将已经缓存的内容异步向外发送。工作者线程将在处理大消息或共享缓冲器被填满时阻塞。对性能优化而言，依据内容体的平均尺寸来分配共享缓冲器的做法是明智的。

2.8.4. 连接事件听众

　　和HTTPCore其它类类似，协议处理者没有记录日志，目的是不强制用户对日志框架的选择。然后可以通过注入一个EventListener的实例到协议处理者中，可以记录重要的连接事件日志。

定义在EventListener接口中的连接事件：

　　•fatalIOException: 当一个I/O错误导致连接终止时触发。

　　•fatalProtocolException: 当HTTP协议错误导致连接终止时触发。

　　•connectionOpen: 当一个新的连接建立时触发。

　　•connectionClosed: 当连接被终止时触发。

　　• connectionTimeout: 当连接超时触发。

2.9. 非阻塞式TLS/SSL

2.9.1. SSL I/O会话

SSLIOSession是一个装饰者类，目的是通过继承IOSession来实现基于SSL/TLS协议的安全层传输能力。一个现有的协议处理者应该能够和SSL会话一起工作，而不需要前置条件或修改。然而I/O调度器则需要添加一些动作，以确保正确的安全层传输功能。

　　• 当基础I/O会话已经建立时，I/O调度者必须调用SSLIOSession#bind()方法，目的是使SSL会话进入客户端或服务端模式。

　　• 当基础I/O会话准备输入时，I/O调度者应该通过调用SSLIOSession#isAppInputReady()来检查SSL I/O会话是否准备好输入数据生产，通过对协议处理者的控制，最终会调用SSLIOSession#inboundTransport()方法，目的是做必须做的SSL握手和输入数据解密。

　　• 当基础I/O会话准备输出，I/O调度者应该通过调用SSLIOSession#isAppOutputReady()来检查SSL I/O会话是否准备好输出数据的接受，通过对协议处理这的控制，最终会调用SSLIOSession#outboundTransport()方法，目的是做必须做的SSL握手和应用数据的加密。

2.9.1.1. SSL I/O会话处理者

通过定制SSLIOSessionHandler接口的实现，可以自定义TLS/SSL协议的各个方面。SSLIOSessionHandler接口中定义SSL事件：

　　•initalize: 当SSL连接已经初始化时触发。这个处理者可以用这个回调函数来定制javax.net.ssl.SSLEngine属性，目的是建立SSL会话。

　　•verify: 当SSL连接已经建立并且SSL握手已经成功完成时触发。这个处理者能用这个回调函数来验证SSL会话的属性。作为一个实例，应该能正确地强制SSL密码强度，并且验证证书链和主机检查。

// Get hold of new I/O session

IOSession iosession;

// Initialize default SSL context

SSLContext sslcontext = SSLContext.getInstance(“SSL”);

sslcontext.init(null, null, null);

SSLIOSession sslsession = new SSLIOSession(

　　　　iosession, sslcontext, new SSLIOSessionHandler() {

　　public void initalize(

　　　　　　SSLEngine sslengine,

　　　　　　HttpParams params) throws SSLException {

　　　　// Ask clients to authenticate

　　　　sslengine.setWantClientAuth(true);

　　　　// Enforce strong ciphers

　　　　sslengine.setEnabledCipherSuites(new String[] {

　　　　　　”TLS_RSA_WITH_AES_256_CBC_SHA”,

　　　　　　”TLS_DHE_RSA_WITH_AES_256_CBC_SHA”,

　　　　　　”TLS_DHE_DSS_WITH_AES_256_CBC_SHA” });

　　}

　　public void verify(

　　　　SocketAddress remoteAddress,

　　　　SSLSession session) throws SSLException {

　　　　X509Certificate[] certs = session.getPeerCertificateChain();

　　　　// Examine peer certificate chain

　　　　for (X509Certificate cert: certs) {

　　　　　　System.out.println(cert.toString());

　　　　}

　　}

});

2.9.2. SSL I/O事件调度器

　　HttpCore提供了SSLClientIOEventDispatch和SSLServerIOEventDispatch的I/O调度者的实现。这些调度者所有必须的动作封装了活动I/O会话，这是一个SSL I/O会话的装饰者，并且确保能够正确地处理SSL协议握手。

© 2012, 無處不在. 版权所有.

       本文的目标就是进一步充分利用GAE后台实例(Frontend Instance)的免费配额资源。就是尽可能地将运行在前台实例(Frontend Instance)上的一部分任务分摊到后台实例(Backend Instance)上运行。本文的另外一个目标就是提供一个如何应用GAE后台实例的范例。

           我们按GAE平台上urlfetch.fetch(…)抓取一次目标页面所耗时分成两类：１）能在5秒中以内抓取成功的任务  2)５秒中以内无法成功抓取的任务(抛DeadlineExceededError异常)。如果是前者很自然是在前台实例上运行，然后将抓取成功的目标页面内容缓存后输出到页面。（这就是上一篇博文所附网页代理程序的核心流程）

       如果是后者，则首先提交给任务队列后，然后直接重定向到目标页面（这部分计算还是运行在前台实例上）：

# 可能是在5秒钟限制下失败的页面读取请求，将其抛入队列等待处理
taskqueue.add(url=’/refetchtask’, params={‘key’: key_name,’value’: mirrored_url})
# 重定向到目标页面(结束)
logging.debug("Redirect ‘%s’",mirrored_url)
self.response.set_status(302)
return self.redirect(mirrored_url)

       上述进入队列的任务出列后，优先提交给后台实例运行(注：这个任务提交过程本身是运行在前台实例上的)：

try:
       # 优先交给后台实例处理
       backend_url = backends.get_url(BACKEND_NAME)+’/_ah/start’
              logging.debug("backend_url ‘%s?key=%s&value=%s’",backend_url,key_name,mirrored_url)
              form_fields = {
              "key": key_name,
              "value": mirrored_url
       }
       form_data = urllib.urlencode(form_fields) 
       result = urlfetch.fetch(backend_url,
                                               payload=form_data,
                                               method=urlfetch.POST,
                                               headers={‘Content-Type’: ‘application/x-www-form-urlencoded’})
       self.response.headers['Content-Type'] = ‘text/plain’
       self.response.out.write(result.content)
except (urlfetch.Error, apiproxy_errors.Error):
……

       如果后台实例也无法运行时(很可能是超配额，因为后台实例的免费配额比前台实例的免费配额还更少)，转而将任务按60秒超时重新在前台实例(就是当前流程中)上运行网页抓取任务:

    ……
except (urlfetch.Error, apiproxy_errors.Error):
       # 超配额则按６０秒的限制重新抓取目标页面
       logging.debug("Try refetching ‘%s’",mirrored_url)
       content = MirroredContent.fetch_and_cache(key_name,mirrored_url,timeout=60)
       self.response.headers['Content-Type'] = ‘text/plain’
       if content :
               self.response.out.write(‘successful’)
       else :
               self.response.out.write(‘unsuccessful’)

       下面才是本文的重点（后台实例的部署,为了使前面“提交后台实例运行：向一个特殊的URL发起的一个HTTP请求”的动作能正常执行） ：

       1)首先，要在backends.yaml中配置后台实例，(命名为fetch_backend,配置最小内存,一个后台实例，由HTTP请求驱动的动态启动方式)：

backends:
- name: fetchbackend
       class: B1
       instances: 1
       options: dynamic

              后台实例需要单独部署的，部署命令：

appcfg backends webproxy/ update

              后台实例有一个形如单独的网址：[instance].[backend].[app].appspot.com 可由API：backends.get_url(BACKEND_NAME)获取，动态启动后台实例的过程就是向这个网址＋请求路径（比如：/_ah/start）发起一个可以带参数的HTTP请求。

       2)其次，要在app.yaml中配置处理后台实例启动的HTTP请求路径“/_ah/start”：

．．．
handlers:
．．．
- url: /_ah/start
       script: webproxy.py
       login: admin
．．．

       3)最后，对上例而言，就是在webproxy.py中编写/_ah/start响应代码（这部分代码才是真正运行在后台实例上的）：

class FetchBackend(webapp.RequestHandler): 
       def get(self): 
              self.response.headers['Content-Type'] = ‘text/plain’
              self.response.out.write(‘Finish’)

       def post(self):
              key_name = self.request.get(‘key’)
              mirrored_url = self.request.get(‘value’)
              if not MirroredContent.get_by_key_name(key_name):
                     MirroredContent.fetch_and_cache(key_name,mirrored_url,timeout=120)
              self.response.headers['Content-Type'] = ‘text/plain’
              self.response.out.write(‘Finish’)

……
application = webapp.WSGIApplication([('/refetchtask',ReFetchTask), 
                                                                      ('/_ah/start',FetchBackend),
                                                                      ('(/.*)/?', WebProxy)], 
                                                                      debug=True)

       最后说明：作为GAE后台实例使用范例的目的算是完成了。至于是否能有效地减少前台实例的计算时间，分摊一部分计算任务给后台实例，有待运行数据的验证。

【２０１１－１１－１９补记】

       经过一段时间的运行，发现GAE后台实例根本不适合单个小任务的运行，因为启动一个后台实例的耗时远远大于直接抓取页面的耗时。它适合于长时间的批量的数据处理。于是做了些改进：
      1) 利用GAE－Cron－Jobs定时在凌晨１点启动后台实例， 在后台实例上首先抓取网站地图sitemap.xml,根据网站地图逐个抓取目标网页并缓存之。
      2)由于缓存数据是不可靠的很可能会失效，为此再次利用GAE－Cron－Jobs每１０分钟对存在的缓存数据进行维持(在前台实例上运行)，减少缓存数据失效的可能性。
      3)拦截用户评论动作，删除对应评论页面的缓存数据。

       如此改进后博客访问速度大增，前台实例每天消耗的计算时间稳定在25Instance Hours上下(免费配额是28),因为用户的请求几乎都是从缓存中读取数据；后台实例每天消耗的计算时间稳定在１Instance Hours上下(免费配额是9)，因为批量抓取网页的过程耗时在一个小时左右。

© 2011, 無處不在. 版权所有.

     对应本博客(http://blog.chaoskey.com)的具体部署过程如下：

          １）将原部署在GAE的博客程序micolog数据，导出成wordpress格式
          ２）在SinaApp上搭建wordpress, 将上导出的数据导入到wordpress
          ３）在GAE上部署一个类似于网页代理的程序（支持缓存,后附代码），基本思路：
               *首先试图读取GAE预先存储的缓存页面数据
               *如果没有缓存数据，则试图到SinaApp博客页面抓取页面内容，抓取成功后存入GAE缓存(缓存24小时后失效,因为GAE平台的免费配额是按天分配的)
               *如果抓取SinaApp博客页面内容失败，则直接重定向到SinaApp博客页面。

       
     之所以采用上述“挂GAE羊头卖SinaApp的狗肉”的方案，是因为：

          １）对于这个GAE网页代理程序而言，GAE免费配额还是足够用的。（如果博客程序完全部署在GAE上必然超免费配额，对我的博客而言每天至少要0.6美元，太贵了。）
          ２）SinaApp云计算平台的收费相对GAE还是很便宜的，对于我的博客而言每天估计只需要0.5人民币。
          ３）GAE支持域名绑定自然也不需要备案。SinaApp云计算平台绑定域名需要预先域名备案，但又不协助用户进行域名备案。

     按我的方案可是算是两全其美了 ：）

     附GAE网页代理程序关键代码供参考：

# -*- coding: utf-8 -*-

__author__ = ‘混沌 (youliang@chaoskey.com)’

import logging
import urllib
import hashlib
import re

from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
from google.appengine.api import memcache
from google.appengine.api import urlfetch
from google.appengine.ext import db
from google.appengine.ext.db import Model
from google.appengine.runtime import apiproxy_errors

DEBUG = False
EXPIRATION_DELTA_SECONDS = 86400
MAX_CONTENT_SIZE = 1000000

IGNORE_HEADERS = frozenset([
  'set-cookie',
  'expires',
  'cache-control',

  # Ignore hop-by-hop headers
  'connection',
  'keep-alive',
  'proxy-authenticate',
  'proxy-authorization',
  'te',
  'trailers',
  'transfer-encoding',
  'upgrade',
])

baseUrlMap = {‘blog.chaoskey.com’:'chaoskey.sinaapp.com’,
              ‘www.chaoskey.com’:'chaoskey.sinaapp.com’,
              ‘alerts-bot.appspot.com’:'chaoskey.sinaapp.com’,
              ‘reurl20.alerts-bot.appspot.com’:'chaoskey.sinaapp.com’,
              ‘reurl30.alerts-bot.appspot.com’:'chaoskey.sinaapp.com’}
             
reUrlMap = {‘/SITEMAP’:’http://chaoskey-wordpress.stor.sinaapp.com/sitemap.xml’,
            ‘/SITEMAP.XML’:’http://chaoskey-wordpress.stor.sinaapp.com/sitemap.xml’}
           
class MirroredContent(object):
    def __init__(self, status, headers, data):
        self.status = status
        self.headers = headers
        self.data = data
   
    @staticmethod
    def get_by_key_name(key_name):
        return memcache.get(key_name)
   
    @staticmethod
    def fetch_and_cache(key_name,mirrored_url):
        logging.debug("Fetching ‘%s’",mirrored_url)
        try:
            response = urlfetch.fetch(mirrored_url)
        except (urlfetch.Error, apiproxy_errors.Error):
            logging.exception("Could not fetch URL")
            return None

        adjusted_headers = {}
        for key, value in response.headers.iteritems():
            adjusted_key = key.lower()
        if adjusted_key not in IGNORE_HEADERS:
            adjusted_headers[adjusted_key] = value

        content = response.content
        oldurl = ‘http://chaoskey.sinaapp.com’
        newurl = ‘http://blog.chaoskey.com’
        pattern = re.compile(oldurl+r’(/?"|s|/tag|/category|/20|/feed|/sitemap|/robots.txt)’)
        content = pattern.sub(newurl+r’1′, content)
       
        # If the transformed content is over 1MB, truncate it (yikes!)
        if len(content) > MAX_CONTENT_SIZE:
            logging.warning(‘Content is over 1MB; truncating’)
            content = content[:MAX_CONTENT_SIZE]

        new_content = MirroredContent(
            status=response.status_code,
            headers=adjusted_headers,
            data=content)
        if not memcache.add(key_name, new_content, time=EXPIRATION_DELTA_SECONDS):
            logging.error(‘memcache.add failed: key_name = "%s", original_url = "%s"’, key_name, mirrored_url)
     
        return new_content   
                             

class ReUrl(webapp.RequestHandler):   
    def get(self,key_name):
        if key_name is ‘/deletememcache’ :
            memcache.flush_all()
            self.response.headers['Content-Type'] = ‘text/plain’
            return self.response.out.write(‘ok’)     
        baseUrl=self.request.host_url
        baseUrl=baseUrl.split(‘://’)
        newBaseUrl=baseUrlMap.get(baseUrl[1])
        if not newBaseUrl:
            self.response.headers['Content-Type'] = ‘text/plain’
            return self.response.out.write(‘ok’)
           
        newBaseUrl = baseUrl[0].lower()+"://"+newBaseUrl
        mirrored_url = newBaseUrl
        if key_name :
            mirrored_url = reUrlMap.get(key_name.upper())
            if not mirrored_url :
                mirrored_url = newBaseUrl+key_name
           
        content = MirroredContent.get_by_key_name(key_name)
        if content is None:
            logging.debug("Cache miss")
            content = MirroredContent.fetch_and_cache(key_name,mirrored_url)
           
        if content is None:
            self.response.set_status(301)
            return self.redirect(mirrored_url)
                           
        for key, value in content.headers.iteritems():
            self.response.headers[key] = value
        if not DEBUG:
            self.response.headers['cache-control'] = ‘max-age=%d’ % EXPIRATION_DELTA_SECONDS
        self.response.out.write(content.data)

application = webapp.WSGIApplication([('(/.*)', ReUrl)],
                                     debug=True)

def main():
    run_wsgi_app(application)

if __name__ == "__main__":
    main()

© 2011, 無處不在. 版权所有.