Cloud Service Design Specification
一、目的
为Cloud Service程序进行软件结构和接口的设计。
二、总体设计
l 需求（CS的要实现的目标）
实现一个模拟的cloud service(CS)。能够通过Metro Style的客户端(MSC)对服务器上的图片和视频进行上传、下载、删除。同时，CS还能通过WNS 将notification 推送到MSC中，以便在MSC的Tile、Badge、Toast上动态的显示。推送的通知有3种level：
Simple：通知图片及Video的数量变化。
Normal：在简单版基础上，增加通知图片及Video的变化细节：新增、删除的图片/Video名。
Advanced：在中等版基础上，对于新增的图片，通知thumbnail。
CS端以Metro UI的方式呈现，将UI最小化后，CS仍会在后台运行。CS和MSC间支持多客户端连接。同时支持缓存机制，在CS没有更新时，MSC预览内容将读取前一次请求后保存在本地的缓存内容，而不需要再次访问CS。
l 总体结构（CS的结构介绍）
MSC需要先请求WNS的channel以便接收CS的notification推送。
CS和MSC间通过socket进行通信，传输的内容封装在预定义的结构体（协议）中。CS端支持多客户端连接，并且一直运行监听线程负责分配新线程满足多客户端连接的请求。当收到一个新的连接请求时，为新的连接分配一个新线程，将连接的上下文传给新线程，之后便继续监听其他的连接。
当一个新线程和MSC建立起连接后，SC端负责解析协议获取数据，比如用户名、密码、请求操作、附加参数等。在解析完协议后，如果是第一次请求，会进行账号验证。如果通过就会进行其他的操作，比如：
Preview：MSC需要浏览CS上的文件。
Upload：MSC需要向CS上上传文件。
Delete：MSC需要删除CS上的文件。
Download：MSC需要下载CS上的文件。
各操作需要的具体参数在下文“协议设计”中会详细介绍。
在完成相应的操作后，CS会发送相应的notification到WNS上。
总体的结构见图2-1
图2-1 CS-MSC 总体结构图
l 处理流程
下面是几个比较重要的过程和操作的执行过程：
n 当一个新的client端连接了监听线程后，监听线程会判断是否超过了最大连接数。如果超过了就返回busyERR (定义的宏) 给client端，并断开连接。如果没有超过就分配一个新线程并将socket连接的上下文传递给新线程，这样新的线程就和client端建立的连接，监听线程就继续监听其他的连接请求。具体的流程如图2-2：
图2-2 监听进程流程图
n 当新的线程和client端建立起了连接后，新线程首先需要解析协议，从传递来的数据中解析出必要的数据。如username、passwd、action、filename等。如果client端是首次发送请求，则需要验证账户，如果账户错误，则将错误类型返回给client。验证完账户，线程根据action的值执行相应的操作。再执行完后会发送notification给WNS。具体的流程如图2-3：
图2-3 新线程执行流程图
n Preview操作：Client请求查看CS上的文件，就会执行preview操作。Preview的操作也会将所有文件名、图片和视频的预览图发送给client。目前打算的方式是将文件的数据保存在一个结构体中，然后传输整个结构体给client，而不是采用循环的方式发送一个个文件。发送完后回给client端一个返回值。具体的流程如图2-4：
图2-4 preview操作流程图
n Delete操作：client发送delete请求就会执行delete操作，支持采用循环的方式一次删除多个文件。具体的流程如图2-5：
图2-5 delete操作流程图
n Upload操作：client发送upload请求就会执行upload操作，支持采用循环的方式一次上传多个文件。具体的流程如图2-6：
图2-6 upload操作流程图
三、软件设计
l 模块（CS的主要模块）
UI模块
Server模块
l 协议设计（CS和MSC通信时传输的数据格式）
n 宏定义：
#define OK 0
#define uploadERR 100
#define deleteERR 101
#define downloadERR 102
#define nouserERR 103
#define passwdERR 104
#define busyERR 105
#define fexistERR 106
n 枚举：
reqAction：请求操作的枚举
enmu reqAction {
PREVIEW = 0,
UPLOAD,
DELETE,
// DOWNLOAD
}
n 结构体：
FileInfo：文件管理结构体, 会根据此结构的格式在CS和MSC端都保存一份FILE.XML或FILE.TXT
struct FileInfo {
int ID; //文件的ID，
string FilePath; //文件完整路径
string Name; //文件名
int FileType; //文件类型 PIC=0，VID=1，DIR=2
}
Login: MSC向CS发送的登录数据
struct M2C_Login{
string username; //MSC端的username
string password; //MSC端的password
}
M2C： MSC向CS发送的操作数据
struct M2C_action {
string username; //MSC端的username，每次操作之前还是根据此数据判断一下操作目录有没有错确保安全，同时为项目开始没有login功能时使用。
int action; //MSC端请求的操作,值是枚举类型reqAction中定义的成员
string dirPath; // 请求的完整的操作目录路径，除非赋值，默认值是用户的home目录，类似于linux中/home/david这种
int[] ID; //和struct FileInfo中的ID相对应，且ID数组中的每一项和另一个成员fileName数组中的文件相对应
string[] fileName; // 请求操作的文件名的数组，用于upload，delete，download
int fileNum; //请求操作的文件数，用于upload，delete，download；如果和fileName中的string数量不匹配，以fileName为准（可能此参数是鸡肋）
string otherS; //待拓展
int otherI; //待拓展
}
M2C： MSC向CS发送的upload数据
struct M2C_upload {
string dirPath; // 请求的完整的操作目录路径，除非赋值，默认值是用户的home目录，类似于linux中/home/david这种
string[] fileName; // 请求操作的文件名的数组，用于upload，delete，download
int fileNum; //请求操作的文件数，用于upload，delete，download；如果和fileName中的string数量不匹配，以fileName为准
}
C2M： CS向MSC发送的数据
struct C2M {
int retVal; //操作或登录的返回值
int fileNum; //得到操作的文件数，如果是preview的话，此值等于文件总数
}
previewData：CS向MSC发送的preview数据
struct previewData {
string path; //preview的完整路径
int[] ID; //所有preview文件的ID
String[] fileName; //所有preview文件的完整路径名
string[] pic; //包含所有pic数据
string[] videoThumb; //包含所有video预览图数据
string[] dir; //包含的完整目录名
}
/* CS向WNS发送数据的格式有待参考介绍WNS的webpage */
C2W：CS向WNS发送的数据
struct C2W {
int newPicNum; //新pic个数
int newVideoNum; //新video个数
string[] newPicDes; //新pic描述
string[] newVideoDes; //新video描述
}
l 数据结构设计（软件中可能需要定义的比较重要的数据或结构体）
四、接口设计
类（CS中定义的比较重要的类）
类图（以图的方式表现各个类之间的继承关系）
方法描述（类中的方法和参数的介绍）
五、讨论的问题（暂列第五点，以后添加至文档中）
文件管理：
在CS的根目录下，直接存放每个以用户名命名的目录。用户的文件都存放在自己的目录中。目录支持子目录。所以CS和MSC之间传输协议中的path都要使用完整路径。
参考了QQ空间和百度空间存放文件的方法，暂时打算使用结构体FileInfo和FILE.TXT管理文件，给用户上传的文件按顺序分配ID（不能重复，类似于linux中的FD），并将信息写入FILE.TXT中。在CS和MSC传递的协议中包含了ID和FileName的数组信息，这样就能保证了CS和MSC两端的FILE.TXT保持同步。
短连接：
使用短连接，完成一次数据交换断开连接。MSC在打开时使用Login结构体想向CS请求登录，登陆上之后以后的再链接并传输请求就不用验证密码。
连接分3种action：
1.preview： MSC向SC使用struct MSC_action发送请求。结构体中包含了请求的完整路径，MSC端根据请求的完整路径名将信息填充至结构体previewData中返回给MSC。待MSC UI显示完毕后返回一个ACK，CS接收到ACK后断开连接。
2.upload：MSC向SC使用struct MSC_action发送请求。CS解析后返回结构体C2M，MSC再向CS使用结构体M2C_upload传递文件信息。并将更新信息写入FILE.TXT
3.delete：MSC向SC使用struct MSC_action发送请求。CS解析后根据ID删除文件。
并将文件信息从FILE.TXT中删除。
Channel list管理：待填充。
浙公网安备 33010602011771号