摘要: 基于Lua 5.1实现的远程调试器,脚本运行在服务端,客户端登录后可以远程管理脚本,可以调试脚本,单步跟进、变量查看。
界面基于wxWidgets实现,网络通讯接口采用CORBA/TAO。
阅读全文
posted @
2011-02-28 16:23 风雷九州 阅读(1938) |
评论 (2) |
编辑 收藏
摘要: 在C++中要进行并发处理,不可避免要使用多线程,在传统的教科书中,大家都是采用最原始的多线程技术,应用逻辑和线程并发策略紧密绑定。
在一个典型的服务器程序中,客户端的请求往往包含了很多不同的逻辑命令,如在一个线程处理函数中,需要根据客户端的命令代码处理不同的业务逻辑:
int thrad_main(int cmd_id,char *data){
switch(cmd_id)
{
case 1:
...
break;
case 2:
...
break;
}
}
如此这般,业务处理逻辑和线程逻辑紧密耦合,这是一种很“丑陋”的代码。
如何通过一种优雅的方法,分离并发逻辑和业务逻辑,通过通用的并发框架,业务逻辑设计者只需要关心自己的逻辑代码,交给“线程池”去处理即可,而不需要去关心如何创建线程,等待线程结果这些琐碎的“小事”?
阅读全文
posted @
2011-02-28 15:46 风雷九州 阅读(4238) |
评论 (3) |
编辑 收藏
摘要: 平台服务和脚本服务接口对后端PostgreSQL数据库的使用目前采用短暂连接方式,造成多次调用服务时频繁连接和断开数据库,效率很低。
如果共享数据库连接,则会造成多线程访问数据库时的事务冲突,故必须采用连接池来管理对数据库的并发访问,某一线程连接到数据库使用完毕后,不断开数据库连接,而是把连接归还给连接池。
另一线程访问数据库时会首先向连接池申请已经存在的连接,如果连接池中没有空闲连接,或者申请到得连接已经超时失效,再建立新的连接,使用完毕后同样归还到连接池。
这样连接池中的连接数会随着线程压力的增加逐渐增长,直到所有的线程同时工作,达到最多连接数。
由于一个线程可能同时申请多个连接,故连接数可能会大于线程数。连接池在程序结束时销毁全部连接,或者线程在申请到的某一连接失效时销毁该连接。
阅读全文
posted @
2011-02-28 13:57 风雷九州 阅读(5655) |
评论 (0) |
编辑 收藏
摘要: 在C/S结构的C++网络程序中,直接采用Socket API进行开发效率是很低的,所以大家发明了各种各样的网络框架,如Boost.Aiso和ACE,简化了网络通信开发的难度。
但是这种基于数据包收发的模式还是不太方便,于是又出现了RPC、DCOM、CORBA等远程接口调用的标准。客户端只需要像调用本地函数一样调用远程接口,框架会自动处理数据包收发,请求和应答等底层细节。
虽然现在Web技术的发展如火如荼,大有取代C/S架构应用之势,但是,直接运行于操作系统平台上的C++原生应用还是有它存在的意义,最主要的方面就是接近系统底层,对操作系统资源和底层设备的控制等,其他任何虚拟机上的中间语言是无法望其项背的。
CORBA是一个为简化跨平台应用而提出的规范,它独立于网络协议、编程语言和软硬件平台,支持异构的分布式计算环境和不同编程语言间的对象重用。
阅读全文
posted @
2011-02-16 19:54 风雷九州 阅读(3842) |
评论 (0) |
编辑 收藏
摘要: 最近开发了一个基于ACE实现的C++ Service框架,每一个服务实现为一个插件,
客户端通过远程调用接口即可访问服务对象提供的服务,客户端接口的包装如下所示:
。。。
一个网络应用一般包括两部分,位于服务端的“服务对象”和位于客户端的“调用代理”,上面这个类属于客户端代理对象。
两端之间遵从的协议就是请求“LoginRequest”和响应“LoginResult ”。
阅读全文
posted @
2009-07-22 13:16 风雷九州 阅读(2898) |
评论 (5) |
编辑 收藏
不知不觉,已经工作了2年了,虽然只是一个普普通通的C++程序员,但这两年也经历了许多喜怒哀乐愁。
IT圈的发展日新月异,新语言新技术层出不穷,当大家都热衷于.NET、Java、Web,追赶着开发潮流,我却依然在摆弄着C++,很明显C++不适合做应用系统的开发,尤其是报表和用户界面上,做的非常累人,很不想做下去了。
所以我一直在研究C++在服务器系统的开发,这方面应该是比较有潜力的,最近研究了一些boost,这些c++中的新鲜血液让我感觉很震撼,虽然一些技术在别的新型语言中并不算什么,但是对于c++来说仍然是划时代的进步。
posted @
2009-07-22 10:29 风雷九州 阅读(363) |
评论 (1) |
编辑 收藏