内置消息简析
在 MTProtoKit 中，有很多内置的消息，除了这些消息之外，还有和解析这些消息相关的类，比如 MTBufferReader 和 MTInternalMessageParser，这些都是用来对这些内置消息进行解析用的；除了内置消息，还应该有很多业务相关性的消息，而这些消息都不在 MTProtoKit 考虑之中，MTProtoKit 将其它消息的序列化由 MTSerialization 协议委托给了使用者（Serialization）去实现，这样做还是很合理的，因为 MTProto 是一个非常动态的协议，扩展性非常强。
内置消息其实就像编程语言给我们提供的标准库一样，它是框架，也是基础，下面简单选取一些消息做个介绍：
- MTBadMsgNotificationMessage：服务端未能正确解析客户端消息时，会返回该消息，并附带错误码。
-
MTBadServerSaltNotificationMessage：服务端对
Salt验证失败时，会返回该消息。 - MTDestroySessionResponseOkMessage：客户端请求销毁当前会话，服务端返回销毁成功的响应。
- MTDestroySessionResponseNoneMessage：客户端请求销毁当前会话，服务端返回未找到该会话的响应。
-
MTDropRpcResultUnknownMessage：客户端请求服务端取消某次
RPC请求，服务端返回未知状态的响应。 -
MTDropRpcResultDroppedRunningMessage：客户端请求服务端取消某次
RPC请求，服务端返回正在处理的响应。 -
MTDropRpcResultDroppedMessage：客户端请求服务端取消某次
RPC请求，服务端返回处理完成的响应。 -
MTFutureSaltsMessage：客户端请求服务端
Salt，服务端的响应消息。 - MTMsgsStateReqMessage：当消息处理的任何一方（服务器或客户端）长时间未收到发出消息的响应，则可以通过该请求来查询消息处理状态。
- MTMsgsStateInfoMessage：消息处理状态响应。
- MTMsgAllInfoMessage：自发性的通知另一方，消息处理的状态。
- MTMsgContainerMessage：消息容器，用于多个消息同时打包发送。
- MTMsgDetailedResponseInfoMessage：当收到重复的消息请求时，且响应内容过大，服务端会返回该条响应，用于描述响应内容。
- MTMsgResendReqMessage：客户端请求消息响应重传，旨在处理重复请求时，明确的让服务端返回响应内容。
- MTMsgsAckMessage：消息回执。
- MTNewSessionCreatedMessage：服务端通知客户端，一个新的会话被创建。
-
MTRpcResultMessage：
RPC请求响应消息。 -
MTRpcError：
RPC请求错误响应。
全局上下文
什么是上下文呢？
上下文就是在某个特定的场景里，用于记录该场景特定状态的一种抽象。
所谓的全局上下文，也就是 MTContext 类，这是一个使用相当频繁的类，它的主要意图是用来给 MTProtoKit 中，其它类提供一个公共的运行上下文，也相当于是整个 MTProtoKit 的入口点。所以，一些公共的状态和方法都会被提升到这个类中，它大体记录了以下信息：
1.客户端运行环境，即 MTApiEnvironment。
2.非内置消息的序列化器实现，即 MTSerialization 协议（Serialization）的实现。
3.客户端时间，并允许设定偏差来校准。
4.当前用户的授权相关信息和操作。
5.数据中心的相关信息和操作。
6.传输格式（MTTransportScheme）的相关信息和操作。
其他细节
现在，我们再来看看一些比较有意思的细节处理；首先是 MTBuffer 类中，字节对齐的算法实现：
static inline int roundUp(int numToRound, int multiple)
{
return multiple == 0 ? numToRound : ((numToRound % multiple) == 0 ? numToRound : (numToRound + multiple - (numToRound % multiple)));
}
很简单的算法，但很有意思，使用 roundUp(17, 4)，则会得到 17 按照 4 向上对齐的结果，也就是 20。
MTBuffer 中，还有一个方法，也就是追加 TL 字节，我们来看一下：
- (void)appendTLBytes:(NSData *)bytes
{
int32_t length = (int32_t)bytes.length;
if (bytes == nil || length == 0)
{
[self appendInt32:0];
return;
}
int paddingBytes = 0;
if (length >= 254)
{
uint8_t tmp = 254;
[self appendBytes:&tmp length:1];
[self appendBytes:(const uint8_t *)&length length:3];
paddingBytes = roundUp(length, 4) - length;
}
else
{
[self appendBytes:(const uint8_t *)&length length:1];
paddingBytes = roundUp(length + 1, 4) - (length + 1);
}
[self appendBytes:bytes.bytes length:length];
uint8_t tmp = 0;
for (int i = 0; i < paddingBytes; i++)
[self appendBytes:&tmp length:1];
}
当这个块的长度小于 254 时，第一个字节就是用来标识内容的长度；而当这个块的长度大于或等于 254 时，第一个字节只是一个标志，后面 3 个字节才是真正的长度，所以，每个块的最大长度是 24 位值，而不是 32 位；这样做，长度值所占用的字节就可以被压缩了。
再来看一个 MTInternalMessageParser 中的 decompressGZip 方法，因为消息是可以放置在 gzip 容器中进行传输的，所以客户端需要解压字节流：
+ (NSData *)decompressGZip:(NSData *)data
{
const int kMemoryChunkSize = 1024;
NSUInteger length = [data length];
int windowBits = 15 + 32; //Default + gzip header instead of zlib header
int retCode;
unsigned char output[kMemoryChunkSize];
uInt gotBack;
NSMutableData *result;
z_stream stream;
if ((length == 0) || (length > UINT_MAX)) //FIXME: Support 64 bit inputs
return nil;
bzero(&stream, sizeof(z_stream));
stream.avail_in = (uInt)length;
stream.next_in = (unsigned char*)[data bytes];
retCode = inflateInit2(&stream, windowBits);
if(retCode != Z_OK)
{
NSLog(@"%s: inflateInit2() failed with error %i", __PRETTY_FUNCTION__, retCode);
return nil;
}
result = [NSMutableData dataWithCapacity:(length * 4)];
do
{
stream.avail_out = kMemoryChunkSize;
stream.next_out = output;
retCode = inflate(&stream, Z_NO_FLUSH);
if ((retCode != Z_OK) && (retCode != Z_STREAM_END))
{
NSLog(@"%s: inflate() failed with error %i", __PRETTY_FUNCTION__, retCode);
inflateEnd(&stream);
return nil;
}
gotBack = kMemoryChunkSize - stream.avail_out;
if (gotBack > 0)
[result appendBytes:output length:gotBack];
} while( retCode == Z_OK);
inflateEnd(&stream);
return (retCode == Z_STREAM_END ? result : nil);
}
