逐步实现TCP服务端Step05-2:查询数据库

这是一个服务间协作的实例,client向mainsvrd请求服务,mainsvrd根据需要向dbsvrd发起查询请求,dbsvrd查询MySQL数据库,将结果返回给mainsvrd。最后,mainsvrd完成相关业务,将结果返回给客户。

proxy的具体实现,见antframe中的proxy工程。proxy的作用是将消息转发给指定实体。每个实体由类型和ID来标识,proxy必须要掌握所有连入自己的实体的基本信息,如:实体类型,ID,IP等等。这些信息可以在连接建立后,由实体告知proxy,这就意味着proxy要完全依赖于各实体。为保险起见,在配置文件中给出各实体的基本信息,以此信息为准 ...


封装MySQL的C语言API

为方便使用,对MySQL提供的C语言API进行包装。考虑到在实际使用时,会对多个数据库服务器进行访问,将访问句柄组织成链表进行管理。

封装后的函数有如下几个,函数名均已MY作为前缀:
其中的重要参数,MySQLConnLink是一个链表,其元素为MySQLConnection,该结构中包含了一个数据库连接相关的信息。如:数据库的账号,密码,数据库名字等 ...


逐步实现TCP服务端Step05-1:实现Proxy

Proxy的基本功能是将收到的消息原封不动地转发给单个或多个目标实体。可用“类型+ID”的方式来标识一个实体。这样,源实体只要提供目标实体的类型、ID以及转发方式,Proxy就可完成转发工作。

转发方式可细分为如下几种:

  • 一对一(P2P):一个源实体对应一个目标实体。此种情况,源实体需要提供目标实体的实体类型和实体ID。

  • 一对多(P2G):一个源实体对应一组(Group)目标实体 ...


启动Wireshark时报错"dyld: Symbol not found: ..."

在OSX上启动Wireshark失败,产生一系列"dyld: Symbol not found: ... "提示:

dyld: Symbol not found: __cg_jpeg_resync_to_restart
 Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions ...


逐步实现TCP服务端Step05:分布协作

迄今为止讨论的都是使用单个服务程序对外提供服务的情况。虽然netio和s是两个进程,但它俩其实是分管了一个服务程序的通信和业务逻辑两个部分,这里把它们视为一体。

假设s在处理业务的时候需要访问数据库,等从数据库提出数据后,又要进行复杂的数学运算。此种情况,只有单个线程的s势必会在某些环节因耗时过多,而影响到其他客户的服务受理。

若继续坚持单线程的路线,就必须对s进行拆分。就像当初从s中拆分出netio一样。假设用于访问数据库的进程叫做dbsvr,用于计算的服务叫做calsvr ...


逐步实现TCP服务端Step04-10:小结

整个Step04阶段所做的工作是让后台系统能支持多客户并发。我们的基本设定是,负责网络通信的netio进程,以及负责业务处理的s进程都是单线程结构。要在这个大前提下对系统进行改造。

首先,不论何种结构,总要对多个客户的信息进行维护。对于netio来说,就是围绕socket的一些数据。我们设定了SocketInfo结构去整合它们,每个客户对应一个SocketInfo结构,用一个list去管理。对于s来说,每一个cilent,就是业务的“用户”,这些用户分别有自己的User对象。我们假设了client的socket值,就是它在业务层面的用户ID,这样,s的每个User对象就有了一个用户ID,基于这个ID可以hash到User对象。同时,User对象中会记录client的SocketInfo结构在list中的索引值,这么一来,就能将netio维护的SocketInfo与s所维护的User对象对应起来。

再说netio对list的处理 ...