在完成了最基本STUN客户端功能(发送Binding request,接收Binding response)之后,做了一些测试.
之前一直纠结在 端口号为何 返回的 与其它软件的返回结果 有出入. 当中.
于是疑心四起,在怀疑了NAT修改,字节顺序 之后,不停地调试....
然后发现我用0x1111去& 某个值, 而事实是 ,我应该用 0xffff . ( 囧0z)
但之后所做的种种测试,让我 决定再写一篇 用来备忘 STUN协议应该注意的很多重要细节。
同时也希望能帮助更多 还没接触过该协议的人,我相信我的这些记录能帮助他们少走弯路.
首先说说我为什么怀疑NAT修改, 这就引出了一个替代RFC3489 的STUN协议 : rfc5389.
rfc5389 在第一页就以Session Traversal Utilities for NAT的缩写 重名名了 老的RFC3489 STUN 缩写,
老实说我严重怀疑这篇的起草人在凑名字 -- 他们希望 rfc5389代替RFC3489 所有东西.包括 STUN 缩写.
呵呵,当然是开玩笑.其实rfc5389 之所以从新定义STUN 缩写,主要是STUN 不再是p2p的完全解决方案。
正如描述:
而rfc5389 中描述的所谓的magic cookie (rfc34