Browsed by
分类:C/C++

强大的系统语言,编写服务器系统的不二选择!

“r”与”rb”

“r”与”rb”

最近做一个测试,模拟收发和解析一些SIP消息。方式方法很简单:将消息存在一个文本文件(.txt)中,读取该文件,然后解析、发送等操作即可。

因为是文本文件,因此想当然地就调用fopen函数”r”模式读取好了:

fopen("d:/demo.txt", "r");

然而让人惊讶的是:读取的结果和实际消息居然有差异,直接导致消息解析失败。百思不解之下不得不进行调试,结果发现丢掉了所有的’\r’符号。

从问题的现象看,感觉是windows平台的C库在读取文本文件时,擅自判断了CRLF(’\r\n’),并错误认为CR符号多余,从而跳过了所有该符号。这个处理只是猜测,对一般的文本处理当然没有问题。而对绝大部分基于文本的互联网协议而言,例如SIP、HTTP、EMAIL等,CRLF有非常重要意义,丢失CR符号无疑会产生非常严重的问题。

解决方法也很简单,就是不再当成文本文件读取,而采用二进制文件读取模式,无差别读取所有内容即可:

fopen("d:/demo.txt", "rb");

补充:在Debian中做了同样的测试。结果表明:linux系统的C库以’r’方式打开文本文件时,不会自作主张地将CR符号去掉,与预期结果一致。

掉坑里了

掉坑里了

Qt无疑是个非常好的framework,我们一直用TA。虽然不敢说已经是行家里手,不过好歹也开发这么久程序了,渐渐地有些自负起来,因此掉坑里了。

坑来自Qt最经典的设计:signal-slot。我以前的理解这是异步的,常用于模块间解耦。在windows平台,这个理解似乎没错,signal-slot底层依赖window的message机制。而在linux平台,其实现方式默认仍然是callback机制。

callback机制在多线程编程里最容易出问题的就是“锁”。这次掉坑里,就是在slot中应用“锁”时不小心,导致了死锁。

这次竟然忘了这点! :-(

php坑:ftok

php坑:ftok

最近有个小需求,需要php程序和服务器程序之间进行一些简单通信。调研了几个进程间通信的技术,选择了消息队列方式。

消息队列技术本身不复杂,无非就是生成一个ID,然后使用该ID发送消息或者接受消息。在C程序中,使用ftok来生成ID,而php同样提供了相同名字的函数。因此,在php代码中,想当然地写下了类似语句:

$key_t = msg_get_queue(ftok("/home", 2));

让人惊讶的是,C程序始终接受不到php发送的消息。百思不解之下,使用命令查看系统的消息队列情况:

ipcs -q

结果表明php程序的确在发送消息,只是php的消息队列ID与C程序的消息队列ID居然是不一致的。重新翻看了php的手册,对ftok函数是这么描述的:

int ftok ( string $pathname , string $proj )

值得注意的是:第二个参数居然是字符串型。而在C函数中,该参数定义为int型:

key_t ftok(const char *pathname, int proj_id);

因此,在php代码中,当我们传递整数2给函数ftok时,php转换成了字符‘2’,也就是说,上述示例的php代码实际相当于以下语句:

$key_t = msg_get_queue(ftok("/home", '2'));

导致最终的计算结果与C函数不一致。修改方式也简单,在C程序中,将第二个参数修改为0x32,与php一致即可。

无法理解php为什么将第二个参数改成字符串型,实在是多此一举,而且毫无意义。

多线程调试的一点技巧

多线程调试的一点技巧

最近几天遇到一个问题,程序在客户的虚拟机中跑了几分钟就不响应了。这实在是很无厘头的一件事情,因为在实体机以及相同配置的虚拟机里,居然无法重现这个问题,而客户几乎每次都重现。

问题本身不复杂。SIP协议栈收到SIP消息后,产生内部数据放入队列,同时通知UA进行处理。诡异的地方在于:UA层居然没有任何反应。初步判断是线程挂住了,可是不知道是什么原因导致的。于是乎各种修改、各种debug、各种打印都用上了,始终不得其解。

google了相关主题后发现其实也挺简单,使用gdb就可以(原谅一个一直使用IDE的人吧),比如程序名是mss:

(1)查找mss当前的pid:ps -A | grep mss

(2)假设pid为1234,则使用gdb调试:gdb mss 1234

(3)进入gdb后,使用bt命令即可查找当前堆栈情况,了解程序卡在什么位置。

(4)也可以使用info threads了解程序各线程的状况。

linux环境中getnameinfo的问题

linux环境中getnameinfo的问题

在linux环境下获取本地IP地址的方法,通常都是先getifaddrs获取当前计算机中所有的接口信息,然后循环调用getnameinfo获取各接口的IP地址。

这是网络上常见的描述方式。在IPv4组网时,没有任何问题。但是在IPv6组网(获取IPv6地址)时,出现了问题。由该函数返回的IP地址字符串中包含了当前接口的名称,例如以下返回值:

fe80::5a94:6bff:fe48:4cec%wlan1

如果想获得纯粹的IPv6地址,应当通过接口地址信息,调用inet_ntop来转换IP地址为字符串,如下处理:

char ipstr[512]={0};
sockaddr_in6* sockaddr_ipv6=reinterpret_cast<sockaddr_in6*>(ifa->ifa_addr);
inet_ntop(AF_INET6,&sockaddr_ipv6->sin6_addr,ipstr,sizeof(ipstr));

此时获取的IP地址字符串信息就不再包含当前接口的名称:

fe80::5a94:6bff:fe48:4cec

IPv6地址带接口名称实际是“zone identifier (区域标识)”,在RFC6874规范中有相应的定义。

2014-06-08 updated:

在Linux系统中,要使用ping6命令来ping IPv6的地址,并且要求带上接口索引。例如如果只是ping IPv6地址,会返回以下错误:

ping6 fe80::a00:27ff:fe37:a9d0
connect: Invalid argument

正确的使用方法如下所示:

ping6 fe80::a00:27ff:fe37:a9d0%eth0
qt network中的一点问题

qt network中的一点问题

在一个小应用中使用了qt的network模块,调用网站的一个接口(HTTP GET方式),获得相应的结果。操作非常简单,可是却出现了问题。

首先是在windows上,运行程序后,提示无法定位libeay32.dll。这个是openSSL的动态链接库,不明白为什么qt4.8.5(windows)默认链接了这个库。查看文档,貌似缺省情况下是不编译进SSL功能的,而且我们用的包并不是自己编译的,是直接从qt网站下载安装的。解决方法也简单,无非就是安装openssl的库,copy相应的dll到exe文件同一目录下即可。

接着又出现了问题,调用HTTP后,服务器返回“406 NOT acceptable”。直接将链接放在浏览器中执行又没有任何问题。检查server上的log,发现apache启动了ModSecurity模块,该模块检查了User-Agent头,如果太简单则认为是假请求(spam请求?),拒绝该HTTP请求。

用wireshark抓了一下包,发现QNetworkRequest默认的User-Agent的确非常简单:

User-Agent: Mozilla/5.0

解决方式同样简单,我们强行修改为稍微复杂一点即可,例如:

QNetworkRequest netReq;
netReq.setUrl(destUrl);
netReq.setRawHeader("User-Agent","Mozilla/5.0 (X11; Linux x86_64)");

这样就可以绕开apache模块的检查。

简单判断当前linux的发行版本

简单判断当前linux的发行版本

初步用了一下最新发布的Ubuntu 14.04版本,大体上来说还是很不错。不过Unity7还是一如既往的奇葩,在与Qt程序的配合中更是如此。很不幸,我们的软件就是采用Qt,因此在Unity中有些莫名奇妙的小冲突,例如systemTray等问题,虽然不影响使用,但是给人的感觉很不爽、很不专业。

简单的处理方式就是程序自动判断当前是不是Ubuntu版本,然后再针对性地做一些处理就好了。目前还没有统一的API可以说明当前linux的发行版本信息,网上有各种各样的方式进行判断。对deb系的发行版本而言,以下方式经验证还比较靠谱:

直接读取/etc/issue文件,这个文件的内容目前包含发行版本信息。

这种方式有一些不确定之处:

(1)首先这个文件名就很奇葩。’issue’为什么是用来存储版本信息的? 为什么不直接用version或者别的更好、更直接的文件名?linux开发人员的思维总是让人搞不懂啊。

(2)既然没有人解释为什么会使用这个文件,同样也就没有人保证以后还会这么做。

qt编译中抑制特定告警信息

qt编译中抑制特定告警信息

在编译某些代码时,我们希望抑制掉一些VC的编译告警,例如C4244(丢失精度告警)。我们可以直接修改mkspecs目录下对应的配置文件,但这样做会影响到所有工程,而我们实际上只希望对某些特定的工程关闭该告警。

可以直接修改pro文件,加入以下内容即可:

QMAKE_CFLAGS += /wd4244

如果是cpp文件,则指定以下参数即可:

QMAKE_CXXFLAGS += /wd4244
mkfifo与select

mkfifo与select

基本上,创建有名管道和平常的文件操作没有太大的差别。在用select对有名管道句柄进行操作时,有些比较奇怪的地方。

例如,我们有两个程序(进程),一个向有名管道写,另一个负责从有名管道读。逻辑很简单,因此我们很自然地在读进程程序中设置read_only,然后用select等待数据。

奇怪的事情发生了,select总是能返回成功,可是read的数据为空。这个问题让我们百思不得其解,结果google后发现,对于只读的有名管道,也需要设置为“读写”模式,否则它对select总是会立刻返回成功。

经过多次测试,对linux下的有名管道,如果采用select判断是否可读,需要设置以下参数:

(1)非阻塞

(2)可读可写

例如以下演示代码:

fd = open(COMMAND_PIPE, O_NONBLOCK | O_RDWR);
... ...
int ret = select(fd+1, &read_set, NULL, NULL, &timeVal);
QT程序自动重启

QT程序自动重启

一行代码就可以了:

// restart application
QProcess::startDetached(qApp->applicationFilePath(), QStringList());