Archive for the '技术流' Category

2 月 18 2010

中国移动GPRS链路的DNS“故障”

Published by under 技术流,闲言蜚语

2月13日上午,我从深圳罗湖口岸回到墙内,依惯例会发推嚷嚷一声:

https://twitter.com/cuilw/status/9038408992

因为已到墙内,所以已经开始使用我自己用Twip架的API。

11:40左右,我登上深圳宝安国际机场的摆渡车,前往我乘坐的ZH9865航班。路上看到顺丰的货机,再次掏出手机想要发推,PockTwit却显示连接错误。打开浏览器,上网,一切正常。开始以为是有推友发了关键词,撞墙了,再加上飞机即将起飞,便关了手机未再细究。

14:00,飞机降落在杭州萧山国际机场。领了行李,买了回绍兴的车票,等车等得无聊的我又掏出手机想要发推,还是连接错误。接着我又试了我用dabr架的另一个Twitter API,也不行,然后我又发现我的blog也打不开了。我的第一反应是主机被墙了,上QQ召唤在澳洲的轰轰测试,他说他那边没问题,我基本上已经断定是被墙了。

坐在机场大巴上,我左思右想还是不死心,想试试是不是临时性撞墙,于是改用SSH的方式去连主机,还是连不上,但客户端返回给我的信息是域名无法解析,我顿时看到了希望。在试遍了托管在Godaddy和Dreamhost的几个域名都无法解析之后,我终于用轰轰托管在万网的一个域名连上了主机。问题找到,托管在Godaddy和Dreamhost的域名“被不解析”了(因为google.com访问正常,不敢断定所有托管在天朝以外的域名都受到了影响)。

找到问题,后面的就好办了。我把CMNET连接的DNS服务器换成了Google的公共DNS,我所有的域名都恢复正常了,我也顺利发出了我这次回墙内的第二推:

https://twitter.com/cuilw/status/9047282846

接着在大巴上,我飞快地把我遇到的情况整理了一下发到了推上:

https://twitter.com/cuilw/status/9047393123

今天BJT1030和1200间的某个时间开始,中国YD的GPRS数据链路无法解析托管在godaddy和dreamhost的域名,到目前为止仍未恢复,我的主机上只有朋友一个托管在万网的域名能正常访问,深圳杭州都受此影响

3:28 PM Feb 13th from dabr

今天,当我写下这篇日志的时候,中国移动的GPRS链路还未从这次DNS“故障”中恢复。



本文链接地址:https://blog.cuilw.com/post/832

2 responses so far

5 月 16 2009

关于WordPress的评论头像

Published by under 技术流

在WordPress的评论中显示头像需要调用一个叫Globally Recognized Avatar的服务
你只需在http://www.gravatar.com注册一个帐号,就可以在全球任何使用Gravatar服务的站点显示个性化的头像
WordPress2.5之前需要安装专门的插件来实现,现在已经原生支持

 

Gravatar的索引是邮箱地址,根据你留在网站上的邮箱显示相应头像
注册后会让你输入一个主邮箱地址
如果你有多个常用邮箱,后面还可以加
每个邮箱都需要通过邮件验证

 

然后是上传头像
上传头像后会让你选图片级别,类似于国外的影片分级,由低到高依次为

  • G — 普通级别,任何年龄的访客都适合查看
    PG — 有一定争议性的头像,只适合13岁以上查看
    R — 成人级,只适合17岁以上成年人查看
    X — 最高等级,不适合大多数人查看

使用Gravatar网站也会有一个相应的显示级别,图片级别过高在有些网站就会显示不出来
所以只要没上传艳照的话,一般就选G吧

 

最后是把图片绑定到邮箱
图片也可以上传多张,随心情换

 

这个服务的好处是不必换个站就需要注册一个帐号上传一次头像
坏处是只要别人填的是你的邮箱,就可以冒用你的头像
不过这应该算开放式讨论系统本身的问题
WordPress后台也可以设成需要注册才允许评论,不过我一般不会这么做

 

Gravatar本身还提供了三套随机头像,用来显示那些没有绑定过的邮箱
具体用哪套就要看网站管理员的心情了
比如我就喜欢用Wavatar那套,好多小星星哦:P



本文链接地址:https://blog.cuilw.com/post/669

No responses yet

5 月 07 2009

腾讯貌似在用搜索引擎优化客服

Published by under 技术流

两次写关于腾讯产品的日志,都是第二天就有不认识的人过来回复。

第一次是写关于Qzone的RSS bug,结果我凌晨写的,上午就有人来回复,晚上我再想重现那个bug发现已经没了(虽然那种改法不算最好,但我确实无话可说了)。当时就在奇怪我这么小个博客怎么会受到腾讯的关注。

前两天又写了篇关于Foxmail的bug的,又是第二天就有位兄台过来很耐心地做了解释。

google了一下两人留下的邮箱,一人确定是Foxmail团队的成员,另一人也疑似是腾讯员工,而且两人的IP也一样。

如此迅速的反应,我猜腾讯应该是有一个专门用来收集产品反馈信息的爬虫,估计是以公司和产品的名称作为关键字的,爬到符合条件的页面就会分发到相应的产品团队(我觉得腾讯有人订了我的blog,看到然后人工提交bug report的可能性可以忽略-_-),由相关客服或技术人员人工处理。

看起来腾讯的这只爬虫非常高效,24小时内就爬到了我的更新,可能是针对语言做过优化,也可能只是用来爬blog、论坛之类的页面,当然这些就是我瞎猜的了。

在财力和技术允许的前提下,用这种方式来收集产品反馈并提供后续服务确实是种不错的方法,效率高,针对性强,信息面大,而且其实运行成本倒不高,最重要的是让用户感受到了企业的积极和诚意。



本文链接地址:https://blog.cuilw.com/post/650

2 responses so far

5 月 04 2009

Foxmail的两个bug

Published by under 技术流

发现Foxmail好大一个bug,在邮箱属性里改了邮箱的POP3密码不会保存下来,下次收信还是用旧密码去登陆。

之前改学校邮箱的密码时发现的,无论在Foxmail里把密码改得如何乱七八糟都能收信。开始还以为是学校邮箱的POP3鉴权有问题,还写信到校网中心去问(现在想想真是囧啊……)。后来越想越不对,试了下直接telnet登上去,密码错了就登不进,看起来一切正常,为什么在Foxmail里就可以无视密码呢?

最后起了Wireshark抓包终于发现问题所在了,Foxmail发出的PASS指令后面清清楚楚地跟着我的旧密码(telnet真是不安全啊-_-),于是问题就是出在Foxmail身上。目前发现唯一能使密码变更生效的方法是在登录鉴权失败弹出重新输入密码对话框时输入正确的密码。

我的Foxmail版本是6.5b3。

还有一个不知道能不能算bug的bug,已经存在于好多版本中,就是Foxmail会缓存邮件服务器的MX记录。我发现这个bug也是在用学校邮箱的时候,浙大的邮件服务器在校内校外解析的结果是不同的,在校内是解析成一个A类私有地址。因为我总是把笔记本合上休眠就带着跑来跑去,Foxmail也一直开着,每次进出校网总会发现学校的邮件服务器被解析成一个当前不能访问的地址。

上次老板跟我说,Foxmail有个地方可以设置是否缓存DNS结果,可惜一直没找到。现在的解决方法是重启一下Foxmail,清空DNS缓存。



本文链接地址:https://blog.cuilw.com/post/647

5 responses so far

2 月 16 2009

大陆Push Mail方案不完全研究

Published by under 技术流

题外话:Blackberry与911

Blackberry的崛起是在2001年911事件之后,按广泛流传的说法,当时全美的常规通信网络都处于瘫痪状态,白宫也不例外,时任副总统的切尼正好有一个黑莓手机,并成功用它指挥了救灾工作,之后美国便掀起了购买黑莓的热潮。

切尼当时是否真的用黑莓指挥救灾我无从考证,但这里面有两个非常明显的误区。第一,911的时候RIM并没有一款能够被称之为手机的产品。RIM第一款基于GSM网络也是第一款具备语音通话功能的设备Blackberry 5810是在2002年推出的,也就是说2002年以后世界上才有了一种叫黑莓手机的东西,这之前所有的黑莓产品都只能被称作数据终端。第二,911时黑莓能够正常使用是因为当时黑莓不依赖于常规通信网络。从Blackberry官方网站的产品目录可以看出,5810以前所有的黑莓终端都是基于DataTAC或者Mobitex两种窄带数据通信网络的。一方面由于是非常规通讯网络,用户基数较小,网络容限与用户数比较常规方式高很多,在突发事件时受的冲击就小;另一方面作为纯数据通信网络,通讯时信道占空比很高,较语音网络而言,发生网络阻塞的概率几乎可以忽略。但如今Blackberry终端绝大多数都是基于GSM或者3G网络的,只有很少几个型号可以使用iDEN网络。简单地讲,现在的黑莓在通讯能力上与普通手机没什么区别,如果再来一次911,黑莓也会和其它手机、电话一样成为废铁。

 

常见Push Mail技术与方案

基于POP3/IMAP客户端定时收信的伪Push我想就没必要提了,目前主流的Push Mail技术主要是OMA EMN Push和IP Push两种。

 

EMN Push

EMN(Email Notification) Push是WAP Push(WAP 1.2标准)的一个扩展。WAP Push分为WAP Push SI(Service Indication)和WAP Push SL(Service Load)。前者就是经常被用于垃圾广告的服务信息,后者最常见的应用就是彩信。EMN Push就是建立在SL之上的,运营商通过一条WAP Push SL信息(通常是以SMS方式发送的)启动手机上的客户端,自动连接数据网络,继而完成邮件收取动作。需要说明的是,中国移动的彩信和中国联通的彩e从本质上来讲就是EMN Push Mail,虽然在OMA标准里将MMS单独列出来写了,但在工作原理和系统结构上两者几乎是一样的。

目前在大陆采用EMN Push方式的方案有移动和RIM合作推出的Blackberry解决方案、移动自已的139邮箱、联通的Redberry。早些时候尚邮曾经推出过基于EMN Push的久久邮业务,但后来中国移动出于众所周知的原因限制了SP使用WAP Push功能,久久邮也就消失了。

 

IP Push

目前所有的Push Mail数据传输都是基于TCP/IP网络的,IP Push顾名思义就是Push Mail服务器通过IP地址定位手机终端。由于手机的IP地址是在连接了数据网络之后通过DHCP方式获得的,Push Mail服务器如果不是与运营商有紧密合作(就像RIM与中国移动,不过有了这层关系当然也可以使用EMN Push了)是无法获知终端的IP地址并进行推送的。IP Push的工作原理是在手机与服务器之间保持一个TCP长连接。手机开机后在后台运行一个客户端程序连接到Push Mail服务器并告知IP地址,之后通过“心跳”等技术保持连接不断,邮件到达时服务器就可以把邮件直接推送到手机的IP端口上。

尚邮采用的就是这种方式,还有Microsoft Exchange Server 2003 SP2起开始支持的Direct Push技术,也是基于IP Push的。

 

技术比较

两者相比,EMN Push的优点在于省电和省流量。通常情况下,手机不连接数据网络,服务器在进行推送时才唤醒手机上的客户端连接数据网络。而IP Push则需要一直维持一个数据连接,并定时发送心跳消息以保证连接不被运营商踢掉,因而耗电非常厉害,同时也会造成大量不必要的数据流量。国外有网友拿HTC TyTN II做过对比实验,使用Direct Push,一天之内一块电池必定耗尽,而使用Blackberry Connect,一块电池至少可以维持三天。可惜他没有给出心跳频率的设置数据,这组结果只能做一个大概的参考。一直保持数据网络连接还有可能影响正常的电话和短信使用,不支持Class A的手机在连接了GPRS后会阻塞电话功能。我的O2 Atom Life虽然在使用数据网络时还能拨入电话,但短信会被阻塞,至今还未找到理论上的解释。

EMN Push的问题在于必须与运营商合作才能实现,市场处于被垄断的状态。如中国移动的Blackberry解决方案,最便宜的一档月费也要400元。139邮箱虽然只要5元或20元的月费,但只提供了最简单的邮件收发功能,而且没有与企业级邮件服务器连接的接口,只适合于一般个人用户。因而企业如果需要,还是只能选用Blackberry解决方案,这对于中小型企业是一笔不小的经济负担。相比之下,自行架设一台Microsoft Exchange Server并使用免费的Direct Push就有了很大的优势。

 

适用终端

Blackberry解决方案:最早仅支持Blackberry,现在通过Blackberry Connect软件,已经可以支持Windows Mobile、Symbian OS、Palm OS

139邮箱:Windows Mobile、Symbian OS、Linux

尚邮:Windows Mobile、Symbian OS、Blackberry

Microsoft Direct Push:Windows Mobile

 

139邮箱Push Mail功能体验

去年暑假的时候,5元版的139邮箱搞了一个免月费到年底的活动,我便把我的三个邮箱都做了自动转信到139邮箱,以实现推送,到现在用了有半年了。目前已发现的问题主要有两个,一是经常出现推送丢失,二是容易泄漏用户的手机号。

对于第一个问题,我经过观察发现,通常是因为收到EMN信息时,手机暂时无法连接数据网络造成的。我猜测139邮箱的EMN信息只是启动手机客户端,并进行一次收取邮件的动作,缺乏相应的同步数据,也没有确认机制,客户端甚至没有失败重试的功能。手机客户端在暂时无法收取邮件时直接放弃执行,便出现了推送丢失的现象。而下一条EMN信息到达时,又会连前面没有推送成功的一起收下来。网上盛传的139邮箱推送延时很厉害,可能就是因为这个。相比之下,Blackberry解决方案在推送流程中已经有了Delivery Confirmation的机制,超时后服务器会再次执行推送,确保了推送的即时性。

第二个问题源于139邮箱是以手机号作为帐号的,出于保护隐私的考虑,移动允许用户设置一个别名映射到手机号帐号。问题在于手机客户端仍然采用手机号帐号来连接移动的邮件服务器,因而通过手机客户端发送的邮件头部仍然可以找到发信人的手机号。

其实诸如无法与桌面邮件客户端进行同步,缺乏与企业级邮件服务器连接的接口等问题我倒都不是很在意,相比月费数百元的Blackberry解决方案,139邮箱还算对得起它的价格。

 

替代方案

国内某些邮箱还支持将邮件内容通过短信或者彩信发送给用户,就是所谓的SMS Push和MMS Push,或者更简单点的邮件到达短信通知。虽然这些方案在易用性上无法与真正的Push Mail相比,但从即时性上来讲也不相上下。而且这类服务有一个优点就是不需要智能手机就可以使用,作为经济型替代品,也是不错的选择。



本文链接地址:https://blog.cuilw.com/post/511

No responses yet