Browsed by
Author: YI

如何使用jQuery获取radio类型的值

如何使用jQuery获取radio类型的值

在HTML编程中,经常使用radio类型的<input>作为输入选项,例如:

<tr>
    <td>System audio</td>
    <td><input type="radio" name="annID" id="annID_AA" value="0a080001" checked /> Automatic attendant </td>
</tr>
<tr>
   <td></td>
   <td><input type="radio" name="annID" id="annID_VM" value="02080004" /> Voice-mail greeting voice</td>
</tr>

我们可以通过id来获取对象,但是这种情况下,需要循环判断属性是否checked。

在上述例子中,radio具有同一个name属性,因此我们可以通过name来获取被checked的radio的值,采用jQuery实现则非常简单:

$("input:checked[name='annID']").val()
在Ubuntu/Kubuntu中以非root用户身份运行wireshark

在Ubuntu/Kubuntu中以非root用户身份运行wireshark

缺省情况下,只允许以root身份运行wireshark,否则无法抓包,命令如下:

sudo wireshark

每次都这样启动实在是比较麻烦,最好还是允许普通用户也运行wireshark并抓包。为此,需要执行以下命令即可:

sudo dpkg-reconfigure wireshark-common
sudo chmod o+x /usr/bin/dumpcap
RFC4028的不足与SIP keep-alive方法

RFC4028的不足与SIP keep-alive方法

在SIP族协议中,只有RFC4028明确讨论了对话keep-alive问题。实际上这在工程应用、生产环境部署中,是个非常重要的话题,尤其是SIP基于UDP协议时,网络原因丢包是很常见的,另外还有软终端任意退出对话等情况。缺乏keep-alive保护的SIP服务器毫无疑问将会严重消耗资源,最终导致整个server被迫退出服务。

RFC4028协议考虑到有状态Proxy、无状态Proxy等情况,提出扩展Session-Expires以及Min-SE两个新的Header,并且通过reINVITE消息来keep-alive dialog。基本上,这个协议本身没有太多问题,按照它的思路,的确是可以解决keep-alive的问题,但是在实际部署中,该协议未必可取,有很大的缺陷:

(1)SIP运营商可能会拒绝reINVITE消息。实际上很多SIP运营商会拒绝reINVITE消息,这是出于SIP运营商媒体处理方面的考虑。最初应用reINVITE就是为了修改媒体流,而这毫无疑问会导致SIP运营商媒体服务器重新分配资源等情况出现。RFC4028中只是定义了新增Header和callFlow,不幸的是,却没有区分出这个reINVITE与更改媒体流的reINVITE,因此实际部署时是否有效,我们需要打一个很大的问号。

(2)采用reINVITE流程太过重型了。正如前面所说,keep-alive的reINVITE消息是没有与更改媒体流的reINVITE进行区分,因此可以肯定绝大部分SIP服务器或者终端,在收到这个reINVITE消息时,会启动媒体更改流程。对话内重改媒体毫无疑问是个很重型的流程,一旦对话内本身就可能有媒体类业务,例如Music On Hold等,就很有可能导致冲突。

如果不采用reINVITE消息,在4028协议中也同时建议可以采用UPDATE消息。在UPDATE消息中可以不携带SDP更改媒体。这种方式可能是比较可行,但是未必所有的SIP设备会支持UPDATE消息并用于keep-alive过程。

方案之二应该采用SIP最基础协议RFC3261中定义的OPTIONS消息。理由如下:

(1)该消息定义在RFC3261协议中,这个协议是整个SIP协议族的基础。基本上不可能有SIP设备(包括服务器、Proxy、终端等)会不支持这个消息。

(2)我们注意到,这个消息可以在对话内,也可以在对话外使用。在RFC3261中很明确地定义了:

An OPTIONS request received within a dialog generates a 200 (OK) response
that is identical to one constructed outside a dialog and does not
have any impact on the dialog.

(3)对话内使用OPTIONS,最显著的优点就是“does not have any impact on the dialog”,对现有对话没有任何影响,更不可能去更改媒体。

(4)对端设备如果由于某种原因已经退出,当然就不能产生200OK响应消息,此时可以理所当然地拆除当前对话,从而保护服务器自身资源,达到keep-alive的目的。

对于设备层级的keep-alive,采用OPTIONS没有任何问题。但是对于dialog层级的keep-alive,则会有问题。原因在于:dialog内的OPTIONS消息有可能被对端作为对话外的OPTIONS来处理。也就是说,如果设备是alive的,但是dialog的BYE消息丢失了,无论dialog内还是dialog外,设备对OPTIONS都可能会返回200OK。

Requests that do not change in any way the state of a dialog may be 
received within a dialog (for example, an OPTIONS request).  They are 
processed as if they had been received outside the dialog.

方案三是采用RFC5626协议,对于UDP-SIP的情况,该协议建议采用STUN keep-alive方式。缺陷在于:定义有些复杂,而且很多SIP设备未必会支持。

呼叫服务器和媒体服务器合一的情况下,当然也可以由媒体服务器检测RTP/RTCP来keep-alive,不过这是另外一个topic了,这种方式可能更合适于SIP终端设备。

一路向北

一路向北

这个不是周董的歌,而是一段广告词,相当有才:

出发,

无所谓先后,

一路向北;

登顶,

无所谓高低,

一路向北;

探寻,

无所谓昼夜,

一路向北!

kubuntu 11.10初体验

kubuntu 11.10初体验

怀着对KDE不可名状的留恋,在得知最新的kubuntu发布后,又忍不住下载下来安装试试。由于没有单独的计算机安装,又不想在虚拟机里体验,因此利用了以前一个旧的移动硬盘进行安装。

从这两三天的体验情况看,kubuntu11.10比以前又有了很不错的进步,以前几个让人烦恼的问题都已经解决了,当然也有新的烦恼产生。

主要进步在于:

(1)界面比以前有优化,感觉比较流畅。在开始菜单中的有个细节改进估计是参考了Mint的实现,即进入多级菜单后,不是在左边用丑陋的箭头回退,而是在上方类似页面导航一样列出菜单的级别,回退非常方便,也很美观。

(2)Network management有很大的进步。以前的NM经常有各种各样诡异的问题,例如VPN无法断开、无线无法登录等等,这些问题都解决了。老实说,以前放弃使用KDE的一个重要原因就是这个NM造成的。现在体验还不错。

(3)默认安装LibreOffice套件而不是让人极度不爽的Koffice。以前的Kubuntu似乎也是采用OpenOffice作为缺省套件,不过其他的KDE发行版本似乎还是保留了Koffice,实在没有必要,除非Koffice能有突破性创新。

当然,新版Kubuntu也有问题:

(1)ibus的问题。这实在是没有想到,因为以前试过的所有kubuntu似乎都没有这个问题。即ibus启动后,能输入中文,但是看不到单词候选小窗口,也无法进行选择,这基本上就不能用!而且将ibus添加到自动启动后,系统启动及其慢,而且启动后,系统运行各项程序都很慢!将ibus删除后,就没有什么问题。最后不得不换上了fcitx(当然,现在发现fcitx输入法也相当不错)。

(2)CPU占用会突然占用100%,时间不长,但是会影响到程序运行,有明显的迟滞感。不知道是什么原因,感觉以前的版本没有这个问题。以前的感觉是一直很慢:-)

总体上感觉似乎可以将kubuntu作为稳定的工作环境继续尝试下去,而且对比之下,ubuntu11.10的Unity实在让人难以适应(而且速度比10.04版本差太远了)。

挥别Amazon EC2

挥别Amazon EC2

过去一直在尝试使用Amazon的EC2云计算环境,并曾经逐步将工作中大量相关资源转移到该系统中。

应该说EC2给我留下了非常深刻的印象,然而结果却并不美好,有各方面的原因,最终导致我放弃了EC2。

最根本的原因是目前从国内访问EC2实在是太慢了。回想起去年我刚接触EC2时,非常惊讶于EC2的速度,无论是虚拟机的运行速度还是网速,都非常让人满意,当时的上传速度轻松就能达到近百KB/s,为此我甚至将VPN环境也转移到了EC2,实在是太方便了。而现在,常常出现连接超时、龟速等让人难以忍受的情况。这个问题不能全部归结于Amazon本身,也与我们猥琐的墙有关(具体原因大家都懂的)。

而最近Amazon本身似乎也有问题。在重新创建instance时,居然只有us-east四个区可选择(?现在的情况是否有改善不得而知)。而恰恰是这四个区今年以来问题不断,要么是连接性问题,要么是API问题,几乎每月都会有。当然这些问题不一定会影响到最终的接入速度或运行状态,但是毫无疑问让人感觉很担忧,尤其是将企业业务运行在这种环境时就显得更严重了。

从一些Amazon的一些新闻判断,Amazon可能将大量EC2或者S3的资源调度给自身的云应用了,例如Amazon视频、Kindle fire等,而留给外部客户的资源自然就少而且差了,这可能也是为什么只有us-east四个区可选择的原因之一。Amazon很有可能不会平等对待外部客户,而以内部应用优先。这对Amazon来说理所当然,但对外部客户而言就需要重新考虑了。

鉴于以上各种因素,最终我们转向了独立VPS提供商。虽然费用比EC2贵些,但是目前至少还没有受到太多的鸟气,感觉比较满意。

最后,再一次Fuck那个众所周知的墙以及它的设计者、制造者和维护者。

Ubuntu中添加一个新用户

Ubuntu中添加一个新用户

Ubuntu中添加一个新用户时不会自动创建用户的主目录,需要在命令中指定,例如:

sudo useradd -d /home/yxh -m yxh

其中,-m就是要求Ubuntu创建目录。

创建完目录后,可以使用passwd设置用户密码,例如:

sudo passwd yxh

按照提示输入密码即可。

2011-11-02 update:

将一个现存的用户加入某个组,例如:将yxh加入www-data组

sudo usermod -a -G www-data yxh

察看用户的用户id以及组id信息命令:

id yxh
谁出卖了我们?

谁出卖了我们?

在现在的中国,出卖个人信息似乎是件司空见惯的事情,无论大小企业,只要拿到客户的联系资料,都会出于商业利益出卖自己的客户,基本上没有什么企业道德。一旦客户问责,都会信誓旦旦、道貌岸然,将责任推个一干二净。

比如说中国移动。

垃圾短信一直困扰移动客户,其中就包括我。我曾经投诉过,得到的回答是,移动不会透露客户信息,一定是我在别的什么地方透露给别的商家,最终泄漏出去了。

真的是这样吗? 我重新买了个神州行的号,开通后就一直在家放着,期间只拨打了几次自己的全球通号码确认通话等基本功能成功,同时也没有告诉任何别的什么人。按照中国移动的说法,这个号码应该收不到任何垃圾短信。可是,过了一个月,垃圾短信来了。

真不要脸啊!

wordpress中添加google analytics代码

wordpress中添加google analytics代码

GA是非常不错的跟踪工具,在WordPress中添加GA支持,有利于分析blog的质量和搜索情况,操作起来也非常简单:

进入WordPress的DashBoard后,点击 Appearance / Editor,选择footer.php进行编辑,将GA代码添加到</body>之前,保存修改即可。