分类目录: C/C++

一道基础的词法解析题

原日志信息
标题:《计算单词数目的小程序-2009-05-24考试》
发布时间:5/24/2009
作者:童燕群

2009年,公司开始推行技能鉴定考试,这是我第一次参加的技能鉴定考试,那次考试最终以成绩不作为技术等级评定的依据收场。据说有的部门直接以金钱来奖励考分高者,在天涯论坛上面闹得沸沸扬扬。当年做这道题目时用完了所有考试时间,但是仍然没有调通,晚上回家后又接着奋战几个小时,重新写了这份代码。在现在看来,当时那个迫切想写代码的心情真的是难以理解。软件维护工作做多了,好像是会有这样的感觉。

直接贴代码,题目在代码头部的注释中。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.86- 7票) Loading ... Loading ... | 同时归档在:算法数据结构, 职业发展 | 标签: , |

[转] 高并发系统设计

一、服务器内部设计

服务器设计涉及Socket的阻塞/非阻塞,操作系统IO的同步和异步(之前被人问到过两次。第一次让我说说知道的网络模型,我说ISO模型和TCP/IP模型,结果被鄙视了。最后人说了解linux epoll吗?不了解呀!汉,回去查资料才知道是这回事。第二次让我说说知道线程模型,汉!这个名词感觉没有听说过,线程?模型?半同步/半异步,领导者/跟随者知道吗。再汉,我知道同步/异步,还有半同步/半异步?啥呀?领导者/跟随者,我现在没有领导。回去一顿恶补,原来是ACE框架里边经常有这样的提法,Reactor属于同步/半同步,PREACTOR属于领导者/跟随者模式。瀑布汗。小插曲一段,这些不懂没关系,下边我慢慢分解),事件分离器,线程池等。内部设计希望通过各个模块的给出一个简单设计,经过您的进一步的组合和打磨,就可以实现一个基本的高并发服务器。

1. Java高并发服务器

Java设计高并发服务器相对比较简单。直接是用ServerSocket或者Channel+selector实现。前者属于同步IO设计,后者采用了模拟的异步IO。为什么说模拟的异步IO呢?记得网上看到一篇文章分析了java的selector。在windows上通过建立一个127.0.0.1到127.0.0.1的连接实现IO的异步通知。在linux上通过建立一个管道实现IO的异步通知。考虑到高并并发系统的要求和java上边的异步IO的限制(通常操作系统同时打开的文件数是有限制的)和效率问题,java的高并发服务器设计不做展开深入的分析,可以参考C高并发服务器的分析做同样的设计。

2. C高并发服务器设计
1) 基本概念

Ø 阻塞和非阻塞socket

所谓阻塞Socket,是指其完成指定的任务之前不允许程序调用另一个函数,在Windows下还会阻塞本线程消息的发送。所谓非阻塞Socket,是指操作启动之后,如果可以立即得到结果就返回结果,否则返回表示结果需要等待的错误信息,不等待任务完成函数就返回。一个比较有意思的问题是accept的Socket是阻塞的还是非阻塞的呢?下边是MSDN上边的一段话:The accept function extracts thefirst connection on the queue of pending connections on socket s. It thencreates and returns a handle to the new socket. The newly created socket is thesocket that will handle the actual connection; it has the same properties assocket s, including the asynchronous events registered with the WSAAsyncSelector WSAEventSelect functions.

Ø 同步/异步IO

有两种类型的文件IO同步:同步文件IO和异步文件IO。异步文件IO也就是重叠IO。 
      在同步文件IO中,线程启动一个IO操作然后就立即进入等待状态,直到IO操作完成后才醒来继续执行。而异步文件IO方式中,线程发送一个IO请求到内核,然后继续处理其他的事情,内核完成IO请求后,将会通知线程IO操作完成了。 
      如果IO请求需要大量时间执行的话,异步文件IO方式可以显著提高效率,因为在线程等待的这段时间内,CPU将会调度其他线程进行执行,如果没有其他线程需要执行的话,这段时间将会浪费掉(可能会调度操作系统的零页线程)。如果IO请求操作很快,用异步IO方式反而还低效,还不如用同步IO方式。 
      同步IO在同一时刻只允许一个IO操作,也就是说对于同一个文件句柄的IO操作是序列化的,即使使用两个线程也不能同时对同一个文件句柄同时发出读写操作。重叠IO允许一个或多个线程同时发出IO请求。异步IO在请求完成时,通过将文件句柄设为有信号状态来通知应用程序,或者应用程序通过GetOverlappedResult察看IO请求是否完成,也可以通过一个事件对象来通知应用程序。高并发系统通常采用异步IO方式提高系统性能。

Ø 事件分离器

事件分离器的概念是针对异步IO来说的。在同步IO的情况下,执行操作等待返回结果,不要事件分离器。异步IO的时候,发送请求后,结果是通过事件通知的。这是产生了事件分离器的需求。事件分离器主要任务是管理和分离不同文件描述符上的所发生的事件,让后通知相应的事件,派发相应的动作。

Ø 线程池

线程池基本上比较简单,实现线程的借入和借出,创建和销毁。最完好可以做到通过一个事件触发一个线程开始工作(注:在epoll中,事件触发又分为边沿触发和水平触发)。

2) 常见的设计模式

根据Socket的阻塞非阻塞,IO的同步和异步。可以分为如下4中情形

阻塞同步 阻塞异步
非阻塞同步 非阻塞异步

阻塞同步方式是原始的方式,也是许多教科书上介绍的方式,因为Socket和IO默认的为阻塞和同步方式。基本流程如下:

listen_fd = socket( AF_INET,SOCK_STREAM,0 )

bind( listen_fd, (struct sockaddr*)&my_addr, sizeof(struct sockaddr_in))

listen( listen_fd,1 )

accept( listen_fd, (struct sockaddr*)&remote_addr,&addr_len )

recv( accept_fd ,&in_buf ,1024 ,0 )

close(accept_fd)

阻塞异步方式有所改进,但是Socket的阻塞方式,前一个连接没有处理完成,下一个连接不能接入,是高并发服务器所不可接收的方式。只不过在上边阻塞同步方式的基础上使用select(严格来说select是一种IO多路服用技术。因为linux尚没有完整的实现异步IO,而winsock实在理解socket没有linux上面那么直观。,这里为了方便,没有做严格的区分)或者其它异步IO方式。

非阻塞同步方式,通过设置socket选项为NONBLOCK,可以很快的接收连接,但是处理采用同步IO方式,服务器处理性能也比较差。

上边三种方式不做深入介绍。下边主要从非阻塞异步IO方式介绍。

非阻塞异步IO方式中,由于异步IO方式在同一系统可能有多种实现,不同系统也有不同实现,下边介绍几种常见的IO方式和服务器框架。

Ø Select

Select采用轮训注册的fd方式。是一种比较老的IO多路服用实现方式,效率相对要差一些。Select方式在windows和linux上都支持。

基本框架如下:


socket( AF_INET,SOCK_STREAM,0 )
fcntl(listen_fd, F_SETFL,flags|O_NONBLOCK);
bind( listen_fd, (structsockaddr *)&my_addr,sizeof(struct sockaddr_in))
listen( listen_fd,1 )
FD_ZERO( &fd_sets );
FD_SET(listen_fd,&fd_sets);
for(k=0; k<=i; k++){

FD_SET(accept_fds[k],&fd_sets);
}
events = select( max_fd + 1,&fd_sets, NULL, NULL, NULL );
if(FD_ISSET(listen_fd,&fd_sets) ){
accept_fd = accept( listen_fd, (structsockaddr
*)&remote_addr,&addr_len );
}
for( j=0; j<=i; j++ ){
if(
FD_ISSET(accept_fds[j],&fd_sets) ){

recv( accept_fds[j] ,&in_buf ,1024 ,0 );
}
}

Ø Epoll

Epoll是linux2.6内核以后支持的一种高性能的IO多路服用技术。服务器框架如下:

socket( AF_INET,SOCK_STREAM,0 )
fcntl(listen_fd, F_SETFL,flags|O_NONBLOCK);
bind( listen_fd, (structsockaddr *)&my_addr,sizeof(struct sockaddr_in))
listen( listen_fd,1 )
epoll_ctl(epfd,EPOLL_CTL_ADD,listen_fd,&ev);
ev_s = epoll_wait(epfd,events,20,500 );
for(i=0; i<ev_s;i++){

if(events[i].data.fd==listen_fd){

accept_fd = accept( listen_fd,(structsockaddr *)&remote_addr,&addr_len
);

fcntl(accept_fd, F_SETFL,flags|O_NONBLOCK);

epoll_ctl(epfd,EPOLL_CTL_ADD,accept_fd,&ev);

}

else if(events[i].events&EPOLLIN){

recv( events[i].data.fd ,&in_buf,1024 ,0 );

}
}

Ø AIO

在windows上微软实现了异步IO,通过AIO可以方便的实现高并发的服务器。框架如下:

WSAStartup( 0x0202 , & wsaData)
CreateIoCompletionPort(INVALID_HANDLE_VALUE,NULL, 0 , 0 )
WSASocket(AF_INET,SOCK_STREAM, 0 , NULL, 0 , WSA_FLAG_OVERLAPPED)
bind(Listen, (PSOCKADDR) & InternetAddr, sizeof
(InternetAddr))
listen(Listen, 5 )
WSAAccept(Listen, NULL, NULL,NULL, 0 )
PerHandleData =(LPPER_HANDLE_DATA) GlobalAlloc(GPTR, sizeof
(PER_HANDLE_DATA)
CreateIoCompletionPort((HANDLE)Accept, CompletionPort, (DWORD) PerHandleData,
0 )
PerIoData= (LPPER_IO_OPERATION_DATA)GlobalAlloc(GPTR, sizeof
(PER_IO_OPERATION_DATA))
WSARecv(Accept,&(PerIoData->DataBuf),1,&RecvBytes,&Flags,&(PerIoData->Overlapped),
NULL)
(GetQueuedCompletionStatus(CompletionPort, & BytesTransferred,
(LPDWORD) &
PerHandleData,(LPOVERLAPPED * ) & PerIoData, INFINITE)
if (PerIoData -> BytesRECV >PerIoData ->
BytesSEND){
WSASend(PerHandleData-> Socket, & (PerIoData
->DataBuf), 1 , & SendBytes, 0 ,

& (PerIoData ->Overlapped), NULL)
}

3) 引入线程池和事件分离器后

由于上边只是单纯的使用非阻塞Socket和异步IO的方式。提高了接收连接和处理的速度。但是还是不能解决两个客户端同时连接的问题。这时就需要引入多线程机制。引入多线程后,又有许多策略。Linux上通常采用主进程负责接收连接,之后fork子进程处理连接。Windows通常采用线程池方式,避免线程创建和销毁的开销,当然linux上也可以采用线程池方式。采用多进程和多线程方式后。事件处理也可以再优化,定义一个简单的事件处理器,把所有事件放入一个队列,各个线程去事件队列取相应的事件,然后自己开始工作。这就是我上边提到的半同步/半异步方式了。如果线程工作的时候是接收到连接后,自己处理后续的发送和接收,然后选出另外一个线程作为领导继续接收连接,其它线程作为追随者。这就是领导者/追随者模式了。具体可以参考ACE的Reactor和Preactor的具体实现。半同步和/半异步网上也有很多的讨论,可以自己深入研究。代码就比较复杂了,这里就不给出代码了。

二、分布式系统设计

前面讲述了分布式系统中的核心的服务器的实现。可以是http服务器,缓存服务器,分布式文件系统等的内部实现。下边主要从一个高并发的大型网站出发,看一个高并发系统的设计。下边是一个高并发系统的逻辑结构:

分布式系统设计

主要是参考这篇文章http://www.chinaz.com/web/2010/0310/108211.shtml。下边主要想从这个架构的各个部分的实现展开。

1. 缓存系统

缓存是每一个高并发,高可用系统不可或缺的模块。下边就几个常见缓存系统系统进行介绍。

Squid

Squid作为一个前端缓存,通常部署在网络的离用户最近的地方,通过缓存网站的页面,使用户不必每次都跑到服务器去取数据,提高系统响应和性能。实现应该比较简单:一个带有存储功能的代理。用户访问页面的时候,由它代理,然后存储请求结果,下次再访问的时候,查看是否需要更新,有更新就去服务器取新数据,否则直接返回用户页面。

Ehcache

Ehcache是一个对象缓存系统。通常在J2EE中配合Hibernate使用,这里请原谅作者本人之前是做J2EE开发的,其它使用方式暂不是很了解。应用查询数据库,对经常需要查询,却更新不频繁的数据,可以放入ehcache缓存,提高访问速度。Ehcahe支持内存缓存和硬盘两种方式,支持分布式缓存。数据缓存的基本原理就是:为需要缓存的对象建立一个map,临时对象放入map,查询的时候先查询map,没有找到再查找数据库。关机时可以序列化到硬盘。分布式缓存没有研究过。

页面缓存和动态页面静态化

在大型网站经常使用的一种缓存技术就是动态页面的缓存。由于动态页面经常更新,上边的缓存就不起作用了。通常会采用SSI(Server side include)等技术将动态页面的或者页面片段进行缓存。

还有一种就是动态页面静态化。

2. 负载均衡系统

Ø 负载均衡策略

负载均衡策略有随机分配,平均分配,分布式一致性hash等。随机分配就是通过随机数选择一个服务器来服务。平均分配就是一次循环分配一次。分布式一致性hash算法,比较负载,把资源和节点映射到一个换上,然后通过一定的算法资源对应到节点上,使得添加和去掉服务器变得非常容易,减少对其它服务器的影响。很有名的一个算法,据说是P2P的基础。了解不是很深,就不详细说了,要露马脚了。

Ø 软件负载均衡

软件负载均衡可以采用很多方案,常见的几个方案有:

基于DNS的负载均衡,通过DNS正向区域的配置,将一个域名根据一定的策略解析到多个ip地址,实现负载均衡,这里需要DNS服务器的配合。
基于LVS的负载均衡。LVS可以将多个linux服务器做成一个虚拟的服务器,对外提供服务器,实现负载均衡。
基于Iptables的负载均衡。Iptables可以通过做nat,对外提供一个虚拟IP,对内映射到多个服务器实现负载均衡。基本上可以和硬件均衡方案一致了,这里的linux服务器相当于一台路由器。

Ø 硬件负载均衡

基于路由器的负载均衡,在路由器上配置nat实现负载均衡。对外网一个虚拟IP,内网映射几个内网IP。一些网络设备厂商也提供了一些负载均衡的设备,如F5,不过价格不菲哦。数据库的负载均衡数据库的负载均衡可以是数据库厂商提供的集群方案。

云计算

转载信息:

作者:周顺利
原文链接:http://blog.csdn.net/shatty/article/details/6629896
注:本文大多数观点和代码都是从网上或者开源代码中抄来的,为了疏理和组织这片文章,作者也费了不少心血,为了表示对我劳动的尊重,请转载时注明作者和出处。

| 1 分2 分3 分4 分5 分 (4.50- 6票) Loading ... Loading ... | 同时归档在:IO编程, 多线程编程 | 标签: , , , , , |

DRBD源码分析(二)——内核模块网络配置和启动

在上一篇里面分析到了基于netlink的connector,connector正是内核态与用户态配置命令交互的通道。用户通过调用用户态的工具,发送相应的命令参数,用户态工具将命令参数转换成相应的消息包,内核态解析消息后得到相应的指令,继续转换成函数调用,最后得以执行。

首先仔细看一下上一节提到的创建connector时注册的收数据的回调函数:

#ifdef KERNEL_HAS_CN_SKB_PARMS
STATIC void drbd_connector_callback(struct cn_msg *req, struct netlink_skb_parms *nsp)
{
#else
STATIC void drbd_connector_callback(void *data)
{
struct cn_msg *req = data;
#endif
struct drbd_nl_cfg_req *nlp = (struct drbd_nl_cfg_req *)req->data;
struct cn_handler_struct *cm;
struct cn_msg *cn_reply;
struct drbd_nl_cfg_reply *reply;
struct drbd_conf *mdev;
int retcode, rr;
int reply_size = sizeof(struct cn_msg)
+ sizeof(struct drbd_nl_cfg_reply)
+ sizeof(short int);

if (!try_module_get(THIS_MODULE)) {
printk(KERN_ERR "drbd: try_module_get() failed!\n");
return;
}

#ifdef KERNEL_HAS_CN_SKB_PARMS
if (!cap_raised(nsp->eff_cap, CAP_SYS_ADMIN)) {
retcode = ERR_PERM;
goto fail;
}
#endif

mdev = ensure_mdev(nlp);
if (!mdev) {
retcode = ERR_MINOR_INVALID;
goto fail;
}

trace_drbd_netlink(req, 1);

if (nlp->packet_type >= P_nl_after_last_packet) {
retcode = ERR_PACKET_NR;
goto fail;
}
printk("packet_type is %d\n", nlp->packet_type);
cm = cnd_table + nlp->packet_type;

/* This may happen if packet number is 0: */
if (cm->function == NULL) {
retcode = ERR_PACKET_NR;
goto fail;
}

reply_size += cm->reply_body_size;

/* allocation not in the IO path, cqueue thread context */
cn_reply = kmalloc(reply_size, GFP_KERNEL);
if (!cn_reply) {
retcode = ERR_NOMEM;
goto fail;
}
reply = (struct drbd_nl_cfg_reply *) cn_reply->data;

reply->packet_type =
cm->reply_body_size ? nlp->packet_type : P_nl_after_last_packet;
reply->minor = nlp->drbd_minor;
reply->ret_code = NO_ERROR; /* Might by modified by cm->function. */
/* reply->tag_list; might be modified by cm->function. */

rr = cm->function(mdev, nlp, reply);

cn_reply->id = req->id;
cn_reply->seq = req->seq;
cn_reply->ack = req->ack + 1;
cn_reply->len = sizeof(struct drbd_nl_cfg_reply) + rr;
cn_reply->flags = 0;

trace_drbd_netlink(cn_reply, 0);
rr = cn_netlink_send(cn_reply, CN_IDX_DRBD, GFP_KERNEL);
if (rr && rr != -ESRCH)
printk(KERN_INFO "drbd: cn_netlink_send()=%d\n", rr);

kfree(cn_reply);
module_put(THIS_MODULE);
return;
fail:
drbd_nl_send_reply(req, retcode);
module_put(THIS_MODULE);
}

值得注意的是:

rr=cm->function(mdev,nlp,reply);

这一句,这里相当于是一个多态,function绑定到哪一个方法由消息包中携带的包类型决定:


cm=cnd_table+nlp->packet_type;

系统在初始化时级生成了一个全局的静态函数表,类似P_primary的标识符是在编译时动态生成的宏。表示其所在的元素的下标,同时也月包类型相对应。

static struct cn_handler_struct cnd_table[] = {
[ P_primary ] = { &drbd_nl_primary, 0 },
[ P_secondary ] = { &drbd_nl_secondary, 0 },
[ P_disk_conf ] = { &drbd_nl_disk_conf, 0 },
[ P_detach ] = { &drbd_nl_detach, 0 },
[ P_net_conf ] = { &drbd_nl_net_conf, 0 },
[ P_disconnect ] = { &drbd_nl_disconnect, 0 },
[ P_resize ] = { &drbd_nl_resize, 0 },
[ P_syncer_conf ] = { &drbd_nl_syncer_conf, 0 },
[ P_invalidate ] = { &drbd_nl_invalidate, 0 },
[ P_invalidate_peer ] = { &drbd_nl_invalidate_peer, 0 },
[ P_pause_sync ] = { &drbd_nl_pause_sync, 0 },
[ P_resume_sync ] = { &drbd_nl_resume_sync, 0 },
[ P_suspend_io ] = { &drbd_nl_suspend_io, 0 },
[ P_resume_io ] = { &drbd_nl_resume_io, 0 },
[ P_outdate ] = { &drbd_nl_outdate, 0 },
[ P_get_config ] = { &drbd_nl_get_config,
sizeof(struct syncer_conf_tag_len_struct) +
sizeof(struct disk_conf_tag_len_struct) +
sizeof(struct net_conf_tag_len_struct) },
[ P_get_state ] = { &drbd_nl_get_state,
sizeof(struct get_state_tag_len_struct) +
sizeof(struct sync_progress_tag_len_struct) },
[ P_get_uuids ] = { &drbd_nl_get_uuids,
sizeof(struct get_uuids_tag_len_struct) },
[ P_get_timeout_flag ] = { &drbd_nl_get_timeout_flag,
sizeof(struct get_timeout_flag_tag_len_struct)},
[ P_start_ov ] = { &drbd_nl_start_ov, 0 },
[ P_new_c_uuid ] = { &drbd_nl_new_c_uuid, 0 },
};

比如,在一次完整的用户态与内核态的交互中,用户态会多次发出P_get_state消息,该消息的包类型码为17。

类似cn_handler_struct这样的函数表,在drbd的代码中随处可见,无论是内核态还是用户态,这样一致的风格,应该非常利于扩展和维护。看代码的人也会觉得非常轻松,不至于无章可循。

DRBD的配置信息、虚拟设备、网络通信端口、对端信息等都是通过drbdsetup或者drbdadm工具以netlink消息包发送到内核态的。

在收到5号消息包时,drbd_nl_net_conf会被调用。在该函数中,会启动worker内核线程,该线程监控一个等待队列,当有事件到来时,即取出处理:

int drbd_worker(struct drbd_thread* thi)
{
...
w = NULL;
spin_lock_irq(&mdev->data.work.q_lock);
ERR_IF(list_empty(&mdev->data.work.q))
{
/* something terribly wrong in our logic.
* we were able to down() the semaphore,
* but the list is empty... doh.
*
* what is the best thing to do now?
* try again from scratch, restarting the receiver,
* asender, whatnot? could break even more ugly,
* e.g. when we are primary, but no good local data.
*
* I'll try to get away just starting over this loop.
*/
spin_unlock_irq(&mdev->data.work.q_lock);
continue;
}
w = list_entry(mdev->data.work.q.next, struct drbd_work, list);
list_del_init(&w->list);
spin_unlock_irq(&mdev->data.work.q_lock);

if (!w->cb(mdev, w, mdev->state.conn < C_CONNECTED))
{
/* dev_warn(DEV, "worker: a callback failed! \n"); */
if (mdev->state.conn >= C_CONNECTED)
drbd_force_state(mdev, NS(conn, C_NETWORK_FAILURE));
}
...
}

启动了worker线程之后,几乎所有的内核态的事务都会交给这个线程来处理。

继续回到drbd_nl_net_conf方法中,在初始化完worker线程后,会继续执行如下语句:

retcode=_drbd_request_state(mdev,NS(conn,C_UNCONNECTED),CS_VERBOSE);

这里既是与对端协商确定当前谁是主节点。在该方法中会向等待队列中放入一个事务,该事务为启动一个receiver线程,receiver线程会使用配置文件中指定的端口和IP信息建立tcp socket监听,等待对端的链接。此时,如果对端一直未有连接过来,本端尝试与对端连接也一直无法建立,则会根据配置等待指定的超时时间,之后会将本段置为Standalone状态。这也就是我们常见的两台服务器同时重启时,会发现一端的启动过程卡在drbd的等待上面。

| 1 分2 分3 分4 分5 分 (4.83- 6票) Loading ... Loading ... | 同时归档在:DRBD | 标签: |

写过的真正意义上的第一个C++程序

博客的发布记录为:
By YANQUN | Published: 二月 24, 2008 | Edit
 
记得当时刚过完年回到学校,看了一个寒假的书,迫不及待的想实践一下,于是参照《Exceptional C++》上面反复拿出来举例的Complex类,自己重新写了一个,虽然不是独创的。首先规划好了想要实现哪些接口,然后一条一条地到《C++ Primer》中去找相应的注意事项和一般约定。整个代码几乎是自己独立写出的。后来在面试过程中,还重新将这份代码又写了一遍提交给考官,呵呵,当时给他的感觉估计还好,但是他哪知道我只会这几行代码 :-)
 
感觉现在写代码的风格几乎都是那个时候定型的。喜欢比较整洁的风格,看到乱七八糟的代码总有重构的冲动。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.75- 4票) Loading ... Loading ... | 同时归档在:生活札记, 软件技术 | 标签: , , |

DRBD源码分析(一)——内核模块初始化

本地安装的是drbd-8.3.5版本,下载相应的源码包。两个子目录涉及源代码,其中drbd目录为内核态的源码,user目录为用户态工具的源码。所有的业务都是在内核态完成,用户态只是提供工具安装、配置、维护内核模块的工作。

drbd架构图,在官方网站的主页上面就能看到,非常显眼,这是内核态的架构示意图:

wps_clip_image-31087

可以很清晰的看到,drbd在文件系统之下,直接操纵物理磁盘(块设备),在网络模型中,基于传输层之上建立虚拟设备。通过TCP/IP协议与远端设备交互。

drbd内核模块的名字为:

[root@Shentar /opt/drbd-8.3.5]# modprobe -all|grep drbd
/lib/modules/2.6.25-14.fc9.i686/kernel/drivers/block/drbd.ko
[root@Shentar /opt/drbd-8.3.5]#

首先找代码的入口,内核模块的初始化定义:module_init宏定义。在drbd_main.c文件中。


module_init(drbd_init)
module_exit(drbd_cleanup)

下面贴出初始化函数:drbd_init(void):

整个初始化分如下几个步骤:

int __init drbd_init(void)
{
int err;

if (sizeof(struct p_handshake) != 80)
{
printk(KERN_ERR
"drbd: never change the size or layout "
"of the HandShake packet.\n");
return -EINVAL;
}

if (1 > minor_count || minor_count > 255)
{
printk(KERN_ERR
"drbd: invalid minor_count (%d)\n", minor_count);
#ifdef MODULE
return -EINVAL;
#else
minor_count = 8;
#endif
}

err = drbd_nl_init();
if (err)
return err;

err = register_blkdev(DRBD_MAJOR, "drbd");
if (err)
{
printk(KERN_ERR
"drbd: unable to register block device major %d\n", DRBD_MAJOR);
return err;
}

register_reboot_notifier(&drbd_notifier);

/*
* allocate all necessary structs
*/
err = -ENOMEM;

init_waitqueue_head(&drbd_pp_wait);

drbd_proc = NULL; /* play safe for drbd_cleanup */
minor_table = kzalloc(sizeof(struct drbd_conf *) * minor_count, GFP_KERNEL);
if (!minor_table)
goto Enomem;

err = drbd_create_mempools();
if (err)
goto Enomem;

drbd_proc = proc_create("drbd", S_IFREG | S_IRUGO, NULL, &drbd_proc_fops);
if (!drbd_proc)
{
printk(KERN_ERR "drbd: unable to register proc file\n");
goto Enomem;
}

rwlock_init(&global_state_lock);

printk(KERN_INFO "drbd: initialized. "
"Version: " REL_VERSION " (api:%d/proto:%d-%d)\n",
API_VERSION, PRO_VERSION_MIN, PRO_VERSION_MAX);
printk(KERN_INFO "drbd: %s\n", drbd_buildtag());
printk(KERN_INFO "drbd: registered as block device major %d\n", DRBD_MAJOR);
printk(KERN_INFO "drbd: minor_table @ 0x%p\n", minor_table);

return 0; /* Success! */

Enomem : drbd_cleanup();
if (err == -ENOMEM)
/* currently always the case */
printk(KERN_ERR "drbd: ran out of memory\n");
else
printk(KERN_ERR "drbd: initialization failure\n");
return err;
}

  • 1、drbd_nl_init方法

初始化网络,在内核2.6.16之前的版本中,还没有内核连接器的封装,还是直接调用原始的netlink套接字,因此初始化时需要有一系列的初始化netlink的动作。新的内核版本中集成了connector的封装,相对来说网络初始化的过程就简单多了。在分析代码时,需要注意,drbd目录下也有一个connector.c,这是为老版本准备的。新版本中根本没有编译该文件,因此只需要知道cn_add_callback这个接口的作用,而不需要去看connector.c中该函数的定义。昨天误分析到connector.c中去了,发现cn_add_callback函数最终结束时会往自己生成的任务队列中注册一个任务,但是怎么也找不到之后谁来等待执行该任务,试图加日志查看该函数流程时,才发现原来并没有运行到该代码。这才发现上述connector封装的问题。

关于连接器,这里简要说明一下,连接器封装了内核态和用户态的通讯过程。提供了简单的几个接口:

int cn_add_callback(struct cb_id*, char*, void (*callback) (void*));
void cn_del_callback(struct cb_id*);
int cn_netlink_send(struct cn_msg*, u32, gfp_t);

int cn_queue_add_callback(struct cn_queue_dev* dev, char* name,
struct cb_id* id, void (*callback) (void*));
void cn_queue_del_callback(struct cn_queue_dev* dev, struct cb_id* id);

struct cn_queue_dev* cn_queue_alloc_dev(char* name, struct sock*);
void cn_queue_free_dev(struct cn_queue_dev* dev);

int cn_cb_equal(struct cb_id*, struct cb_id*);

void cn_queue_wrapper(void* data);

这里只分析cn_add_callback和cn_netlink_send两个,在内核创建连接器时,需要调用cn_add_callback方法,其中callback函数指针参数指定了连接器接收到数据时的回调函数,数据到达时将由该函数来处理。连接器既可以用于接收数据也可以用于发送数据。接收数据使用回调来处理。发送数据直接使用cn_netlink_send方法即可。该方法支持单播、广播和组播。一般单播和广播会用到。cn_add_callback方法无误返回,也就意味着网络初始化好了,比起之前版本中的复杂创建、绑定和监听套接字等流程简单多了。

  • 2、register_blkdev方法

wps_clip_image-6088

这个方法是内核系统调用,用于注册一个块设备,需要指定主设备号,如果指定的设备号为0,则会由系统自动分配一个。该方法调用之后,就可以在/proc/devices文件中看到drbd块设备。drbd设备的设备号在代码中写死,为147。需要注意的是,如果块设备号已被占用,会导致注册失败。

见左图。

 

 

 

 

  • 3、register_reboot_notifier注册块设备重启时的回调函数

目前注册了一个空函数,委婉的说以后会实现,其实没有任何需要做的事情:

reboot_callback

  • 4、init_waitqueue_head初始化一个等待队列

等待队列可以是生产者和消费者之间的共享队列,后面的业务分析中应该会遇到该结构,到时会仔细分析该队列中所存放的内容。应该与具体的读写数据业务有关。

  • 5、drbd_create_mempools创建内存池

这块还没有仔细分析,drbd中需要使用的内存池特别多,数据块的,接收缓冲区的,发送缓冲区的。

  • 6、proc_create创建/proc/drbd文件

内核允许模块在/proc目录下创建自己的虚拟文件和虚拟文件夹。并且指定该文件的操作回调函数。其中,drbd指定了open, read, write和close方法的回调函数即/proc/drbd的四个回调函数:

struct file_operations drbd_proc_fops =
{
.owner = THIS_MODULE, .open = drbd_proc_open, .read = seq_read,
.llseek = seq_lseek, .release = single_release,
};

在打开该文件时,内核会调用drbd_proc_open函数来呈现相应的内容。也可以说这里是drbd内核服务向用户态反馈信息的一个通道。所有用户态的工具也是基于这个来判断当前drbd的状态。

  • 7、rwlock_init初始化全局读写锁。

整个内核模块的初始化到这里就结束了,总结一下,主要涉及下面几个系统调用:cn_add_callback,cn_netlink_send,register_blkdev,register_reboot_notifier,init_waitqueue_head,mempool_create,create_proc_entry。随着linux 内核的不断壮大,驱动编程似乎也在越来越简单。

| 1 分2 分3 分4 分5 分 (4.90- 10票) Loading ... Loading ... | 同时归档在:DRBD | 标签: |

分布式存储知识学习清单(完善中)

分布式存储是云存储和云计算的基石。没有特别深入的存储基础知识,但是对分布式存储比较感兴趣。希望以不同的开源存储系统的架构特点和细节组成一条学习的主线,以点带面的掌握主流的架构、算法和适用场景。

1、DRBD

1)磁盘IO的截获和处理流程;
2)同步和异步IO复制流程
3)内核态与用户态交互流程
4)文件系统、VFS和块IO之间的关系

2、Ceph

1)对象接口
2)分布式存储的元数据与数据节点分离架构

3、VFS

1)内核知识点
2)本地文件系统

4、关系数据库

1)PostgreSQL、Sqlite,SQL语法,DB文件组织的数据结构

5、算法

1)PAXOS算法:Chubby、BigTable、GFS论文
2)NoSQL、Cassandra、Voldemort,节点间消息通讯模型,多副本一致性保障。
3)CAP定理相关

| 1 分2 分3 分4 分5 分 (4.80- 10票) Loading ... Loading ... | 同时归档在:Java, Linux内核, 算法数据结构 |

温习一下AIO编程,AIO编程简单实例

完成端口(AIO)是Windows下开发多并发网络连接、异步服务器程序的最常用方案。JDK 1.7版本引入了AIO的相关封装。这里把之前写过的一个AIO例子发出来温习一下。为下一步分析JDK的AIO做一些准备工作。

下面的例子是AIO与线程池结合的例子,每个连接在建立之后即调用一次receive方法,这里的receive是不阻塞主线程的继续运行接受其他连接的。可以把这个调用想象成一个事件注册的过程,告诉内核对象,我关心这样的读取数据事件,当数据过来时,先把它收下来,放到之前用参数指定的内存缓冲区中,然后通知一下我就可以了。子线程就在等待数据接收完成的完成端口上面等待,直到数据接收完成,处理数据。让繁杂的数据接收拷贝过程交给内核对象去完成。使得线程管理和编程更加简单。

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.80- 5票) Loading ... Loading ... | 同时归档在:IO编程 |

发布一个改良后的轻量级下载工具

一直都觉得迅雷等工具太重了,即占用网络带宽又消耗系统资源。而且在下载源的出口速度普遍超过家庭宽带的速度时,p2p已经起不到下载提速的作用,甚至还会在下载完成后占用上传带宽。因此一直想找到一个最精简的下载工具,axel是目前发现的比较合适的。以后试着用脚本写一个类似的工具。

axel是linux下的多线程下载工具,工具支持多线程并发下载,支持断点续传。这里基于axel-2.4的源码,在cygwin下编译了Windows版本。基于gnu的开源license,发布一个Windows的版本。

编译好的软件包见文末的下载地址。

其中,mydownload.bat为启动程序,在使用之前只需要修改其中的目录即可:

@cd /d "C:\Users\t\Desktop"
@set maxcons=8

:renew
@set /p url=请输入下载路径:
@call D:\software\axel-2.4\axel.exe -n %maxcons% -a "%url%"
@echo finished!
@echo;
@echo;
@goto renew
@pause

axel.exe文件的路径和下载后文件存放的路径。即以上粉红色部分。

下载地址:http://codefine.site/wp-content/uploads/2013/06/axel-2.4.zip

| 1 分2 分3 分4 分5 分 (4.50- 6票) Loading ... Loading ... | 归档目录:C/C++ |

system调用导致子进程socket句柄泄漏问题分析

关于fork和行缓冲的问题 中讨论了fork的一些特性,堆栈复制,确切的说是‘写时复制’。这篇将讨论资源的复制问题。

问题引出:A进程与B进程各自独立,都是服务器进程,常驻系统,互不相干。在某次重启A进程后,发现由于固定监听的端口被占用而无法启动。检查,发现是B进程占用了该端口,检查B进程代码,没有相关的打开该固定端口和打开随机端口的动作。问题百思不得其解。

最终,发现B进程不只是占用了该固定端口,还打开了很多本该只有A进程才会打开的句柄资源。很快联想到A是B的子进程,B是A fork之后在子进程中运行的。进一步分析,发现A进程有着类似于监控B进程的作用,在特定情况下,会调用B进程的监控脚本来重启B,调用时用的是system函数。

再来看system函数的实现,用fork产生一个子进程,在子进程中运行脚本,脚本启动B。B就这样降到了A的子孙辈,无论是第几代子孙,都会继承A的资源。

这样,当B重启之后,B也打开了只有A才会使用的端口,对B来说,它根本不使用这些资源,甚至不知道自己打开了哪些句柄,这非常不好。之后,某个时刻,当A重启时,A原来申请的资源会一一释放,但是已经被B继承的那份拷贝还处于打开状态,导致A启动时报端口冲突。

问题分析清楚,也就好解决了。解决的方案有:
1、重写system函数,再派生子进程后,运行脚本之前,将所有不需要的句柄关掉,一般的多进程服务端程序也都这么做。
2、发现java程序并没有打开父进程的资源,可以用java实现一个‘脚本调用器’,解决办法似乎不是特别优雅。
3、在申请资源的时候用fcntl将句柄设置为不被继承。

在分析方案的过程中也学习了vfork与fork的差别,vfork只是父子进程共享堆栈,但是句柄资源还是复制了。也分析了exec与fork的区别。都找不到完美的解决办法。

3方案解决当前问题最简单,但是容易留下坑。2方案总觉得很别扭。决定采用1。问题又来了,A进程本来就不是多进程的模式,因此它并没有集中管理资源,想要从代码中增加全局变量收集零散资源似乎很困难。想到了常用的lsof工具,这个工具不是可以列举任何进程的句柄吗?查阅其源代码,原来是读取proc虚拟文件系统下的数据来实现的。如法炮制,也用这个方法遍历本进程的fd目录,将得到的句柄一一记录,在关闭了proc目录后,将记录下来的句柄关闭,这时还会将已经关闭的proc目录的句柄又关闭一次,不过不会有什么问题。存在的问题是必须以root运行才能得到句柄列表。

奋笔疾书,写完了新的system函数,却发现脚本不能运行完成,总是在中间某个点就退出了。经过在脚本中反复打点,发现总是在同一行上面退出,这一行是一个shell函数调用,猜测,是不是新的system中指定的脚本解析器不支持函数?另外写测试程序,也不是这样的。继续找原因,原来这一行还使用了标准输入、输出、错误重定向。而标准输入输出已经在父进程中关闭了,重定向当然会有错误。保留0,1,2三个句柄后问题彻底解决。其实这三个句柄也是不能随意关闭的,一但句柄关闭后,系统会将句柄号分配给其他资源,这样如果代码中使用了重定向0,1,2,那后果会不堪设想。

| 1 分2 分3 分4 分5 分 (4.86- 7票) Loading ... Loading ... | 同时归档在:软件技术 | 标签: , , |

大整数乘法

很长时间都没写过代码了,试着写了这个常见的题目。整体思路:采用整形链表记录大整数的每一位,然后分别遍历乘数和被乘数的每一位,将每两个数字的乘积累加到结果的相应位上面。针对大整数类型,重载输入和输出流,重载乘法。

输出部分实现不是特别好。用STL的容器实现链表也许会简单的多。重载乘法的实现不合常理,本应该返回一个新的对象,为了简单起见,直接返回了新对象的指针;在计算乘法结果时使用了一个递归,理论上来说有可能深度过大,导致栈溢出;另外对于指针和应用的使用不规范。

具体代码:

阅读全文 »

| 1 分2 分3 分4 分5 分 (4.83- 6票) Loading ... Loading ... | 同时归档在:算法数据结构 |
返回顶部