转载地址http://mogu.io/mat-tt-network-01-23](http://mogu.io/mat-tt-network-01-23)
mac TeamTalk，底层通信，主要在这里！
概述
为了增加程序的可扩展性，以及降低后期维护的成本，在MAC TT的开发后期，我决定重构TT的网络层。
重构之后的网络层实例化了网络请求，这样有一个好处就是方便维护网络请求的生命周期。每一个网络请求都把自己的数据打包和解包封装起来。换一种说法就是每个网络请求都是相互独立的。相对于之前把数据打包放在一个PackManager中，把解包的操作分发到UserModule和MessageModule等module中的做法更加解耦，后期想添加一种新的网络请求时可以做到对原先的代码原封不动，
新的网络层通过block将发包和收包绑到了一块儿。这样一来开发者在函数的生命周期中就可以对收到的包做相应的处理，而不需要用通知在程序的某个阴暗角落做不为人知的处理。因为在整个程序中我们有很多中的网络请求，如果用通知的话，我们至少要添加相同种类的通知，在很大程度上增加了程序的复杂度以及维护成本，完成这一优化更多的是依靠block的特性。
新的网络层框架保证了数据包的一致性，协议头中有seqNo，用于保证数据包的一致性。原先的网络层只管发送数据包，缺少了对返回数据包协议头的校验。假设这样一个场景A发送了两个获取用户信息的数据包a1和a2，这时服务器端会返回两个数据包b1和b2。原先的网络层这时是没法知道哪个数据包对应的是哪个数据包的。新的网络层协议将seqNo作为请求生命周期维护的标识符组成部分，在收到数据包的时候对数据包协议头解析，根据协议头中的seqNo以及其他部分找到维护列表中的相应的请求，这样就做到了一一对应。
新的网络层分为协议、SuperAPI、APISchedule三部分组成，接下来将逐篇展开
协议 - APIScheduleProtocol
APIScheduleProtocol定义了每个网络请求中不同的部分以及每个网络请求需要实现的接口。APIScheduleProtocol协议是作为一个可扩展性的基石，后续的所有网络请求类都需要实现这个协议。APIScheduleProtocol协议定义了以下几个接口：
-(int)requestTimeOutTimeInterval; 返回请求超时时间
-(int)requestServiceID; 返回请求的ServiceID，用于请求生命周期的维护
-(int)responseServiceID; 返回返回数据包的ServiceID，用于请求的维护校验
-(int)requestCommendID; 返回请求的CommandID，用于请求生命周期的维护
-(int)responseCommendID; 返回返回数据包的CommandID，用于请求的维护校验
-(Analysis)analysisReturnData; 返回数据解包的block，在收到数据并通过协议头的解析找到相应的请求实体的时候，就会调用这个block，Analysis的定义如下：
typedef id(^Analysis)(NSData* data);
-(Package)packageRequestObject;返回数据打包的block，在发送请求之前调用这个block去对相应的数据打包成符合服务器端协议的数据包。Package的定义如下：
typedef NSMutableData*(^Package)(id object,uint16_t seqNO);
创建新类型的请求的时候，只要实现这个协议中的接口就可以了，开发者完全不用关系是怎么发送怎么维护的。如果你认真看了，或者我说的够明白，这里你也许会问，我实现了这个协议之后我怎么去发起请求呢，我怎么去维护呢？我们马上来讲SuperAPI！！！
SuperAPI
一个请求实体在实现了APIScheduleProtocol协议之后已经完成了绝大部分他应该做的东西了，但还差最关键的一步：发送请求的接口。在这个接口中我们需要完成请求的维护注册、数据打包、发送，这个每个请求都需要的操作。所以就有了SuperAPI。SuperAPI定义了发送请求的唯一接口。
- (void)requestWithObject:(id)object Completion:(RequestCompletion)completion;
所有的请求都需要调用这个接口去和服务器端交互，在某种程度上来说也降低了程序的复杂度。接口中有两个参数：
object ： 这是请求时带的除去协议头中数据之外的数据（协议头中的数据在APIScheduleProtocol中已经定义好了接口）。比如你要获取某个用户的信息，这时候object就是用户的ID。
completion : 这是在客户端收到数据并解析后确认分发给自己，自己解析完之后调用的block（这些逻辑操作都是定义在APISchedule中的）。RequestCompletion 定义如下：
typedef void(^RequestCompletion)(id response,NSError* error);
假如 error为nil，则说明是请求成功反之则是失败。completion block 使用户在调用此接口的函数中可以对返回的数据做相应的处理。避免了大量使用通知的情况。简化了开发者的程序逻辑和复杂度。
这个接口不需要子类去重载，因为所有的接口发送请求的逻辑都是一样的。以下是接口实现：
- (void)requestWithObject:(id)object Completion:(RequestCompletion)completion
{
//seqNo
theSeqNo ++;
_seqNo = theSeqNo;
//注册接口
BOOL registerAPI = [[DDAPISchedule instance] registerApi:(id<DDAPIScheduleProtocol>)self];
if (!registerAPI)
{
return;
}
//注册请求超时
if ([(id<DDAPIScheduleProtocol>)self requestTimeOutTimeInterval] > 0)
{
[[DDAPISchedule instance] registerTimeoutApi:(id<DDAPIScheduleProtocol>)self];
}
//保存完成块
self.completion = completion;
//数据打包
Package package = [(id<DDAPIScheduleProtocol>)self packageRequestObject];
NSMutableData* requestData = package(object,_seqNo);
//发送
if (requestData)
{
[[DDAPISchedule instance] sendData:requestData];
}
}
代码不多主要的请求生命周期的维护是在APISchedule中去实现的。（这个接口的实现主要是借助设计模式中的模板模式）。
APISchedule
今天先到这里，APISchedule 部分会在Mac TeamTalk 网络层（2）出现；预告在Mac TeamTalk 网络层（3）中还会出现对于这一框架的扩展哦！
