逐步实现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)目标实体 ...


逐步实现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的处理 ...


逐步实现TCP服务端Step04-9:IOCP

IOCP是Windows平台特有的机制,在Windows平台上,它与epoll在Linux上的地位相当。二者常放在一起讨论,不过,它俩完全不是一类东西。

selectpollepoll系列,属于I/O多路复用机制。通过这种机制,就可在单一流程(单线程)中一次性找出,当前I/O已就绪的文件描述符。这大大降低了,程序因不知道哪些I/O已就绪,而无休止地轮询(调用recv/send等)所有文件描述符所产生的大量无用功。当然,多路复用是用在单线程处理多路I/O的场景中,若一路I/O独占一个线程的话,就没必要轮询了,线程直接阻塞在I/O上就行了。

IOCP是配合Overlapped I/O来使用的,这种所谓的重叠I/O是Windows平台上的异步I/O机制。说到同步、异步的概念,在不同场合下有不同解释。单说异步I/O的话 ...