这个东西，稍微有点程序经验的人应该都接触过，比如在设计数据时候冗余了部分数据，避免关联表查询，减少开销，实际上也减少了查询时间，所谓空间换时间。还比如，我们将一个有点开销的计算结果存储起来，避免下次再次运算，减少时间消耗，再如，CPU的设计，设置了高速缓存，一级缓存，二级缓存，主存（通常所说的内存），其实一个硬盘和一个CPU也可以干活，只是干得不怎么样，因为硬盘和CPU之间速度实在是差别太大了，如是就有人想把可能要用到的数据预先加载到高速缓存或者主存中，慢慢形成了今天的个人计算机架构。

2、以时间换空间法则

这个其实也是天天在用的一个法则，只是一般技术人员看到“压缩”二字的时候，没联想到那么多，压缩就是最典型的拿时间换空间的例子，就是不断的重复前面已经存储过的存储地址，用来避免存取真实的数据。

3、循环法则

大部分稍微有点经验的人不会在同一个函数中循环两次同样的变量，但是仅限于同一个函数，假如在一个函数里调用了另外一个函数，那么就不一定了，很多人为了看似解耦的一个操作，在两个函数对同一个变量做了多次的循环。循环法则有几个比较经典细则：
第一、将代码移除循环，这是最容易想到的，当然，可以移除的条件是，每次循环都执行同样的某次操作。
第二、合并测试条件，高效的内循环应该包含尽量少的测试条件，最好只有一个，因此，程序员尽量用一些退出条件来模拟循环的其他退出条件。
第三、哨兵法则，在数据结构边界上放一个哨兵以减少测试是否已经搜索结束的开销。
第四、展开循环，展开循环可以减少修改循环下标的开销，对于避免管道延迟，减少分支以及增加指令级的并行性也有很大帮助。
第五、删除赋值，赋值的开销实际上在整个程序的执行过程中占的开销可以忽略不计，但假如你要在一个循环十万次的循环中赋值，那么开销就不能不计了，尽可能的在循环中减少赋值吧。
第六，消除无条件分支，快速的循环中不应该包含无条件分支，通过旋转循环，在底部加上一个条件分支，能够消除循环结束处的无条件分支。
第七、循环合并，如果你不小心做了傻事，那么合并两个对同一个变量循环操作吧

4、逻辑法则
利用等价的代数表达式。如果逻辑表达式的求值开销太大就将其替换为开销较小的等价代数表达式。
短路单调函数。如果我们想测试几个变量的单调非递减函数是否超过了某个特定的阈值，那么一旦达到这个阈值就不在需要计算任何变量了。
对测试机条件重新排序。在组织逻辑测试的时候，应该是降低开销的，经常成功的测试放在高开销的，很少成功的测试前面。

5、过程法则
打破函数层次。对于（非递归地）调用自身的函数，通常可以通过将其改写为内联版本并固定传入的变量来缩短其运行时间。
并行性。在底层硬件条件下，我们构建的程序应该尽可能多的挖掘并行性。

6、表达式法则
编译时初始化。在程序执行前，应该尽可能多的变量初始化。
利用等价的代数表达式。如果表达式的求值开销过大，就将其替换为开销更小的等价的代数表达式，比如换一种算法
消除公共子表达式。如果两次对同一个表达式求值，其所有变量都没有任何改动，那么我们可以用下面方法避免二次求值：存储第一次的计算结果并用其取代第二次求值。

相关文章

• 2009年06月8日 — 开发环境的三大规则
• 2009年06月6日 — 数据完整性策略
• 2010年08月8日 — UDP hole punching 翻译
• 2010年04月18日 — 类设计
• 2010年03月23日 — Firefox使用SSH配合autoproxy自动翻山图文教程

第三种技术，也是这篇文章主要要研究的，就是非常有名的“UDP打洞技术”，UDP打洞技术依赖于由公共防火墙和cone NAT，允许适当的有计划的端对端应用程序通过NAT“打洞”，即使当双方的主机都处于NAT之后。这种技术在 RFC3027的5.1节[NAT PROT] 中进行了重点介绍，并且在Internet[KEGEL]中进行了非正式的描叙，还应用到了最新的一些协议，例如[TEREDO,ICE]协议中。不过，我们要注意的是，“术”如其名，UDP打洞技术的可靠性全都要依赖于UDP。

We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. In the first situation, representing the common case, two clients desiring direct peer-to- peer communication reside behind two different NATs. In the second, the two clients actually reside behind the same NAT, but do not necessarily know that they do.

这里将考虑两种典型场景，来介绍连接的双方应用程序如何按照计划的进行通信的，第一种场景，我们假设两个客户端都处于不同的NAT之后；第二种场景，我们假设两个客户端都处于同一个NAT之后，但是它们彼此都不知道(他们在同一个NAT中)。

3.3.1. Peers behind different NATs 处于不同NAT之后的客户端通信

Suppose clients A and B both have private IP addresses and lie behind different network address translators. The peer-to-peer application running on clients A and B and on server S each use UDP port 1234.? A and B have each initiated UDP communication sessions with server S, causing NAT A to assign its own public UDP port 62000 for A’s session with S, and causing NAT B to assign its port 31000 to B’s session with S, respectively.

我们假设 Client A 和 Client B 都拥有自己的私有IP地址，并且都处在不同的NAT之后，端对端的程序运行于 CLIENT A,CLIENT B,S之间，并且它们都开放了UDP端口1234。 CLIENT A和CLIENT B首先分别与S建立通信会话，这时NAT A把它自己的UDP端口62000分配给CLIENT A与S的会话，NAT B也把自己的UDP端口31000分配给CLIENT B与S的会话。如下图所示：

Now suppose that client A wants to establish a UDP communication session directly with client B.? If A simply starts sending UDP messages to B’s public address, 138.76.29.7:31000, then NAT B will typically discard these incoming messages (unless it is a full cone NAT), because the source address and port number does not match those of S, with which the original outgoing session was established. Similarly, if B simply starts sending UDP messages to A’s public address, then NAT A will typically discard these messages.

假如这个时候 CLIENT A 想与 CLIENT B建立一条UDP通信直连，如果 CLIENT A只是简单的发送一个UDP信息到CLIENT B的公网地址138.76.29.7:31000的话，NAT B会不加考虑的将这个信息丢弃（除非NAT B是一个 full cone NAT），因为 这个UDP信息中所包含的地址信息，与CLIENT B和服务器S建立连接时存储在NAT B中的服务器S的地址信息不符。同样的，CLIENT B如果做同样的事情，发送的UDP信息也会被 NAT A 丢弃。

Suppose A starts sending UDP messages to B’s public address, however, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A’s public address.? A’s outgoing messages directed to B’s public address (138.76.29.7:31000) cause NAT A to open up a new communication session between A’s private address and B’s public address. At the same time, B’s messages to A’s public address (155.99.25.11:62000) cause NAT B to open up a new communication session between B’s private address and A’s public address. Once the new UDP sessions have been opened up in each direction, client A and B can communicate with each other directly without further burden on the “introduction” server S.

假如 CLIENT A 开始发送一个 UDP 信息到 CLIENT B 的公网地址上，与此同时，他又通过S中转发送了一个邀请信息给CLIENT B，请求CLIENT B也给CLIENT A发送一个UDP信息到 CLIENT A的公网地址上。这时CLIENT A向CLIENT B的公网IP(138.76.29.7:31000)发送的信息导致 NAT A 打开一个处于 CLIENT A的私有地址和CLIENT B的公网地址之间的新的通信会话，与此同时，NAT B 也打开了一个处于CLIENT B的私有地址和CLIENT A的公网地址(155.99.25.11:62000)之间的新的通信会话。一旦这个新的UDP会话各自向对方打开了，CLIENT A和CLIENT B之间就可以直接通信，而无需S来牵线搭桥了。(这就是所谓的打洞技术)！

The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of “introducer” and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. The application does not need to attempt to detect explicitly what kind of middlebox it is behind, if any [STUN], since the procedure above will establish peer- to-peer communication channels equally well if either or both clients do not happen to be behind a middlebox.? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public Internet via two or more levels of address translation.

UDP打洞技术有很多实用的地方：第一，一旦这种处于NAT之后的端对端的直连建立之后，连接的双方可以轮流担任 对方的“媒人”，把对方介绍给其他的客户端，这样就极大的降低了服务器S的工作量；第二，应用程序不用关心这个NAT是属于cone还是symmetric，即便要，如果连接的双方有一方或者双方都恰好不处于NAT之后，基于上叙的步骤，他们之间还是可以建立很好的通信通道；第三，打洞技术能够自动运作在多重NAT之后，不论连接的双方经过多少层NAT才到达Internet，都可以进行通信。

相关文章

• 2010年02月8日 — 代码格式规范的List
• 2010年08月18日 — 代码调优法则–编程珠玑笔记
• 2010年03月23日 — Firefox使用SSH配合autoproxy自动翻山图文教程
• 2010年03月15日 — 数据库的层次结构
• 2010年01月31日 — 上海Think In Lamp 聚会记

server端代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# -*- coding: utf-8 -*-
from socket import * 
import sys, time, encodings
 
if __name__ == '__main__':
	if len(sys.argv) < 2:
		print u'请输入端口号'
	else:
		sockobj = socket(AF_INET, SOCK_STREAM)
		sockobj.bind( ('', int(sys.argv[1])) )
		sockobj.listen(2)
		while True:
			connection,address = sockobj.accept()
			rcvd = connection.recv(1024)
			if not rcvd :
				pass
			else:
				print u'收到:', rcvd.decode('utf-8').encode('gb2312')
				print u'发送：能'
				connection.send("能")
				break
			connection.close()

Client端代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#coding: utf-8
from socket import * 
import time
 
if __name__ == '__main__':
	sockobj = socket(AF_INET, SOCK_STREAM)
	sockobj.connect(('localhost', 2828) )
	send_info = "能收到信息吗？"
	time.sleep(1)
	print u"发送:", send_info.decode("utf-8").encode("gbk")
	sockobj.send(send_info)
	rcvd = sockobj.recv(1024)
	print u"收到：", rcvd.decode('utf-8').encode('gb2312')
	sockobj.close()
	print u"完成"

特别说明一下，我是在Windows下面搞的，CMD默认只能显示GBK编码，所以在print的时候转来转去，如果在Linux终端，直接显示就行了

相关文章

• 2010年06月20日 — Django 1.2.1 CSRF verification failed. Request aborted.
• 2010年06月17日 — Windows平台安装Python2.6 和 MySQL-Python
• 2010年03月5日 — django Settings cannot be imported 错误解决
• 2009年12月15日 — Google AppEngine Launcher不能启动的解决方法
• 2009年03月30日 — 在Linux上安装mod_wsgi文档中文翻译（二）

假设一个句子S可以表示为一个序列S=w1w2…wn，语言模型就是要求句子S的概率P(S)：

这个概率的计算量太大，解决问题的方法是将所有历史w1w2…wi-1按照某个规则映射到等价类S(w1w2…wi-1)，等价类的数目远远小于不同历史的数目，即假定：

N-Gram模型

其中，C(w1w2…wi)表示w1w2…wi在训练数据中出现的次数

平滑技术的引入

N>>K

其中K为随机变量能够取到的值的个数。

K=140*140*140=2,744,000

给定一个10万词左右的人工标注训练集，即

N=100,00，可见训练数据显得非常不足。

p(k)=N(k)/N

对于计数为r的计数等价类，定义nr为等价类中成员的个数，pr为等价类中事件的概率，R是最大可能出现的计数次数，则

我们使用Cr表示保留部分中计数为r的计数等价类的观察个数。对于保留部分使用最大似然法对进行概率pr进行估计，即使对数似然函数最大化：

如果测试部分也作为保留部分的话，就是典型的极大似然估计：

对于留一方法，pr的极大似然估计为：

因为nRpR与1相比一般可以忽略，留一估计公式可以近似为：

留一估计可以利用计数r=1的事件来模拟未现事件，对于未现事件有如下估计：

这个公式就是著名的Turing-Good公式。

空等价类

留一估计中要求么个nr均不为0，在实际问题中当r=5时，这个要求通常都不能满足，即计数等价类G1,…,GR中存在空的等价类。这时按照出现次数进行排序：

对应的出现r(l)次的事件的个数记为nr(l)，在进行留一估计时，使用下一个非空的等价类Gr(l+1)代替可能为空的等价类Gr(l)+1，留一估计公式变为：

式中对空的等价类没有估计概率，因为空等价类并没有对应任何有效事件。

Turing-Good估计的优缺点和适用范围

缺点：( 1 )无法保证概率估计的“有序性”，即出现次数多的事件的概率大于出现次数少的事件的概率。(2)pr与r/N不能很好地近似，好的估计应当保证pr<=r/N。

优点：其它平滑技术的基础。

适用范围：对0<r<6的小计数事件进行估计。

约束留一估计

单调性约束：pr-1<=pr；折扣约束：p<=r/N。

约束留一估计：让计数估计r*=pr•N处于距其最近的绝对频数之间：

在这个约束下，单调性约束自然满足。

计算方法：计算m时检查每个pr是否满足约束，不然就用约束的上下界进行裁剪，然后重新计算m，一直迭代下去直到所有pr满足约束。

Katz指出Turing-Good公式实质是对模型中观察到的事件进行折扣，将折扣得来的概率摊到所n0个未现事件中。在这个思想的指导下，估计公式可以下成如下形式：

其中，dr是对计数为r的事件的计数的一个折扣函数。

若折扣函数定义为：dr=b，其中b为一个大于0的常数。那么未现事件的总概率为：

对应绝对折扣模型的估计公式为：

线性折扣模型

若折扣函数定义为：dr=a·r，其中a为一个大于0的常数。那么未现事件的总概率为：

对应线性折扣模型的估计公式为：

若a=n1/N，则n0p0=n1/N，与Turing-Good估计相同。

删除插值法（Deleted Interpolation）

其基本思想是，由于N-Gram比N+1-Gram出现的可能性大的多，所以使用N-Gram估计N+1-Gram的概率，例如trigram的计算公式如下：

其中，

参数l的确定：将训练数据分为两部分，一部分用于估计f(wi| w1w2…wi-1)，一部分用于计算参数l，求使语言模型的困惑度最小的l。

相关文章

• 2010年05月20日 — AMQP协议介绍
• 2010年04月11日 — Linux网络管理中的几个小工具
• 2010年01月7日 — varnish安装记录
• 2009年10月10日 — VPS上安装Centos的几个错误解决
• 2009年08月29日 — Linux进程创建

CSRF verification failed. Request aborted.
Help

Reason given for failure:

CSRF cookie not set.

Hopefully this saves you some time because I sure wasted a lot of mine solving it.  I ended up having to add ‘django.middleware.csrf.CsrfViewMiddleware’, and  ‘django.middleware.csrf.CsrfResponseMiddleware’ to my MIDDLEWARE_CLASSES in settings.py and my problems were solved.  All I had to say was mutha eff.  Django also was no help with their debug.  My MIDDLEWARE_CLASSES now looks like:

MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.csrf.CsrfResponseMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
)

Hope this helps.

相关文章

• 2010年08月5日 — 超级简单Python Socket Server一例
• 2010年06月17日 — Windows平台安装Python2.6 和 MySQL-Python
• 2010年03月5日 — django Settings cannot be imported 错误解决
• 2009年12月15日 — Google AppEngine Launcher不能启动的解决方法
• 2009年03月30日 — 在Linux上安装mod_wsgi文档中文翻译（二）