STUN client初试

从前从前很偶然地实现了p2p

完成了 从丹东到北京 的一次难忘的'对话'

我真的感谢 感谢在甚至不知道hole punching之前 能有这么一次运气

让我领略了Internet 带给我的兴奋

 

然后,注定地, 幸运之后 得到了一个不能重现的失望结果.（我的一位同学,你可要长命百岁啊,你是那个历史除了我唯一见证！）

 

不过,毕竟有成功的先例,让我学习一些网络知识有了很多动力.

首先,网络上铺天盖地的 nat类型的解释 真的很容易混淆概念..(而且一些是与标准概念冲突的)

标准的 那些 '对称' 等的类型定义 ,到现在为止 ,我都把RFC2026 的解释当作 我看过的 最清澈 理解参考.

(nat类型的解释 可以参看 我的摘录: http://blog.csdn.net/ga6840/archive/2011/02/10/6177612.aspx)

 

然后,寻寻觅觅,发现自己始终不忍心 去租用服务器.所以这段时间开始实现STUN协议的客户端.

 

昨天晚上兴奋地得到了stun.iol.unh.edu 返回的Binding Request.. 

 

对于STUN协议,我要感谢:

http://beta.codeproject.com/KB/IP/stunner.aspx          上面关于客户端的实现 提供的参考. 

还有

http://basiccoder.com/c-program-to-test-stun.html/comment-page-1#comment-2007

提供的对 初试STUN的很有启发的 helloworld验证程序

 

特别的,感谢 http://kevinxiao.blog.163.com/blog/static/3120379201062652540120/

提醒我们注意不是所有 STUN 服务端 都是 "诚实的", 我一开始就是 用stun.xten.com 这个DN (指向 75.101.138.128)

他不返回结果还好, 返回结果让我很高兴 ,但是却是错误的...

改使用了上述连接 博文 使用的132.177.123.13 (stun.iol.unh.edu) 才返回了正确的值

 

 

 

还有很多路要走

明天继续.

 

 

 

以下配一个截图,仅作纪念:

(收到数据我才猛然注意到 原来 rfc3489 定义的 Binding Response 对应的两个ASCII 原来都是 0x01 ,

加起来就是如图所示的两个笑脸！

不知道 标准的制定者 是有意无意 ....)

 

 

By ga6840