p2p之UDP打洞

当今互联网到处存在着一些中间件(MIddleBoxes),如NAT和防火墙,导致两个(不在同一内网)中的客户端无法直接通信。 这些问题即便是到了IPV6时代也会存在,因为即使不需要NAT,但还有其他中间件如防火墙阻挡了链接的建立。 目前部署的中间件多都是在C/S架构上设计的,其中相对隐匿的客户机主动向周知的服务端(拥有静态IP地址和DNS名称)发起链接请求。 大多数中间件实现了一种非对称的通讯模型,即内网中的主机可以初始化对外的链接,而外网的主机却不能初始化对内网的链接, 除非经过中间件管理员特殊配置。

在中间件为常见的NAPT的情况下(也是本文主要讨论的),内网中的客户端没有单独的公网IP地址, 而是通过NAPT转换,和其他同一内网用户共享一个公网IP。这种内网主机隐藏在中间件后的不可访问性对于一些客户端软件如浏览器来说 并不是一个问题,因为其只需要初始化对外的链接,从某方面来看反而还对隐私保护有好处。然而在P2P应用中, 内网主机(客户端)需要对另外的终端(Peer)直接建立链接,但是发起者和响应者可能在不同的中间件后面, 两者都没有公网IP地址。而外部对NAT公网IP和端口主动的链接或数据都会因内网未请求被丢弃掉。本文讨论的就是如何跨越NAT实现内网主机直接通讯的问题。

Read on →

浅谈元编程

为什么会突然想到写这篇文章呢?其实是因为我曾经向一位朋友推荐学习一下ruby/lisp这类支持元编程的语言,尽管可能永远不会在生产环境中用到,但是可以让人学习用另一种思路思考问题,然后友人就要求我解释我学了之后思考问题的角度有何不同,当时确实把我难住了,因为这个问题的确不好描述。

对于这个问题,我思前想后好几周后,我还是决定从理性和感性两个方面,稍微描述一下,什么是元编程?学习了元编程之后你的思考到底可能在什么地方和别人产生差异?

P.S. 鉴于ruby在元编程领域的强大能力,本文将用ruby来辅助我的描述,即便是没有ruby基础,我也会尽量描述清楚不影响理解;至于为什么不用lisp,那是因为它在这行当走得太彻底了,彻底到我觉得自己现阶段没有能力描述清楚 Read on →

Http原理

Go语言中处理http请求主要涉及两个对象: ServeMuxhttp.Handler接口

ServeMux即http请求路由,将http请求分发到注册的对应路由处理方法中。http.Handler及http的路由处理接口,该接口实际上仅包含一个方法ServeHTTP:

src/net/http/server.go
1
2
3
type Handler interface {
	ServeHTTP(ResponseWriter, *Request)
}
Read on →
go

Task Tracer – 实时任务追踪系统

产生背景

Task Tracer(以下简称tt)的产生原因其实是为了解决一个用户体验的缺憾。由于在生产环境中,我们一直使用salt-stack作为任务的发布和执行机构,然而salt使用的Pub/Sub这种模式下有一个遗留缺陷: 就是任务一旦发出,直到它执行结束退出,任务的发起者无法知道任务当前的执行状态,唯一能做的仅仅能够判断该任务是否在running,而不能实时获取其进程输出;其次,当该salt任务执行完成后,需要独立获取其任务标准输出和进程退出状态(exit code),无法一次性获取其输出和退出状态。salt社区也意识到这个问题,在逐步开发VT模块以求解决,不过这个特性截止到目前仍在实验阶段。

所以,为了消除salt任务执行阶段的黑洞焦虑,我决定开发tt。 虽然tt是为了解决salt的一个问题,但在开发时,我决定将其和salt分离开来,使得tt其实是能够解决这样一类问题: 如果需要实时获取命令执行输出,就可以将命令包裹到tt中执行,从而利用tt Server实时获取其执行输出及结果

Read on →

Gulp Js的构建工具

0. 简介

gulp是javascript世界的构建工具,它并不是js世界第一个构建工具,但由于它小而快的特点,一出现就快速赶超它的前辈grunt,在npm的下载榜上一直高居前列。

Read on →

分享你的Angular指令

Angular directive on bower

用Angular做web开发不但听起来是非常炫酷的事情,而且从我实际的开发体验来看,它确实是极大减轻了开发者的痛苦。我可以把精力都花在组织业务逻辑,创建更为流畅和漂亮的UI上,而完全不用去反复沦陷在事件绑定数据更新这些无趣的事情上。此外,angular框架本身依照设计模式上定义出了一套MVC漂亮的实现,了解其controller,server,directive后,写出大型web app已经不是难事了。

Angular中最漂亮的两个组件是service和directive,简单说来,service是逻辑代码的抽象和封装,它将应用中重复使用的逻辑代码抽象为公共服务,便于打造瘦controller;而directive则是对UI组件的抽象,其对directive的封装和接口设计简直刷新了我对前端的认识。

这里我就不准备详细介绍怎么写指令了,google的文档和我之前的博客都可供参考,这里说一下,如果你写出来非常cool的指令,怎么分享给大家呢?答案是bower。

Read on →

关于后台任务

关于sidekiq

在做ruby开发时,通常会遇到耗时操作的处理,sidekiq由于其使用简单,性能强劲,所以常被用来作为Ruby应用的后台任务的执行引擎。不过sidekiq有个令人头疼的问题,就是任务提交到后台异步执行后,对于其状态的监测和管理就成为很大的问题。

Read on →

AngularJs之Isolated Scope

分离式scope(Isolated Scope)

在angularjs指令中问什么需要使用分离式的scope,主要是为了分离指令和执行所在的”环境”,这个环境其实就是指controller的scope和指令自身的scope,使用分离式scope达到隔离各自scope变量,避免变量污染,从而最大程度上达到指令的重用。

Read on →

高效读取excel

前面介绍ruby写excel文件的一个很cool的gem包axlsx,这里介绍另一个高效读取excel的包creek

一个读一个写,ruby轻松搞定execel处理。 Read on →

脚下的路

本来之前就想写写关于2014年的经历,但一直心里都是满满的负能量,所以一直没有下笔。今天其实也是,和家人闹得不开心,然后愤懑地来公司上班,没想到在路上反而突然想明白了,所以就回顾一下过去的2014,还有现在心里的想法吧。

life分类下,之前的两篇文字都是非常积极的,我之前耕耘多年,凭着自己的努力进入了百度,我自己其实是非常自豪的。即便进入了百度后,能力也被非常认可。所以在2014上半年,其实我是感觉意气风发的,在工作中,也做出了一些很cool的事情。那时候的我,感觉自己离梦想只有一步之遥,仿佛站在天梯之巅,拨开云层再踏一步,可能我就能出去,去Google朝圣。那是在朋友们眼中,我就是个疯子,什么都可以不要。那时,我是幸福的,虽然在别人眼里,那时的我是一个不负责任,狂热的人。

但是在下半年,我逐渐感受到狂热背后的东西,尽管在百度,也要做很多机械重复的事情,此外更重要的是,我发现自己很孤独,除开工作,我一无所有,独自在上海漂泊,心里非常寂寞。再加上后来家人生病,我选择了离开,回到成都。

在离开百度的那段日子,我的情绪非常低落,每天只吃一点东西。真的,人有时候在失去时才知道珍惜。回到成都小半年里,我常常回忆起临走前一天,在食堂吃过饭后翠姐问我:你不是想去Google吗,你怎么办? 那时我心里如遭重锤,是啊,有路吗?我沉默了下,算是安慰自己回答她:走一步看一步吧。这种答案,我自己都觉得好难过……

people must pay for their choices,每个人必须为他的选择付出代价。

Read on →