model

const (
	TOKEN_TYPE_APNS         = 1
	TOKEN_TYPE_GCM          = 2
	TOKEN_TYPE_MPNS         = 3
	TOKEN_TYPE_SIMPLE_PUSH  = 4
	TOKEN_TYPE_UBUNTU_PHONE = 5
	TOKEN_TYPE_BLACKBERRY   = 6
	// Android里使用
	TOKEN_TYPE_INTERNAL_PUSH = 7
)

const (
	MESSAGE_TYPE_UNKNOWN         = 0
	MESSAGE_TYPE_MESSAGE         = 1
	MESSAGE_TYPE_MESSAGE_SERVICE = 2
)

const (
	MESSAGE_BOX_TYPE_INCOMING = 0
	MESSAGE_BOX_TYPE_OUTGOING = 1
)

const (
	ONLINE_TIMEOUT       = 15 // 15秒
	CHECK_ONLINE_TIMEOUT = 17 // 17秒, 15+2秒的误差

)

- 简单设计思路(@benqi)

• IM里，在线状态是一种Weak状态，不需要非常的精确，在线状态只需要达到最终一致性要求即可 故可以将在线状态存储在redis里
• 以一种租约机制设置用户状态的在线状态 > 一旦收到account_status，如果不存在，则设置为在线，并为这个key设置一个过期时间 如果key存在，则延长过期时间
• 回到我们的应用场景，一个客户端对应于一个AuthKeyId，以如下结构存储 > key(online_user_id) --> hash { [auth_key_id]_[session_id] : {time, server_id, net_lib_session_id} } > - key为用户Id > - value为hash结构，实际存储值通过连接符'_'拼装 > - hash里的field为<auth_key_id, session_id>二元组 > - field的value为<time, server_id, net_lib_session_id>三元组
• why？？ > telegram最大的一个特色是允许多端漫游，由auth_key_id标识一个客户端设备，连接到服务端以后，由auth_key_id+session_id对应于 > telegram实例（https://core.telegram.org/mtproto/description），一个用户可能会有多个由auth_key_id，而且每个由auth_key_id > 也可能会有多个session_id，所以以<auth_key_id, session_id>二元组做为字段唯一标识客户端实例已经上线，但这样会存在如下问题： > - hash没有指定某一个field设置过期时间，会导致已经下线的客户端还存在field里，故field的value里要缓存一个time时间，由业务层通过 > 过期时间来判断是否已经失效
• 运维需要注意的地方
• 各服务器要对时，服务器时间误差不能太大
• ......

auth_key_id ->