一 前言
本文是《JDFS:一款分布式文件管理實(shí)用程序》系列博客的第二篇，在上一篇博客中，筆者向讀者展示了JDFS的核心功能部分，包括：服務(wù)端與客戶端部分的上傳、下載功能的實(shí)現(xiàn)，epoll的運(yùn)用，線程池的運(yùn)用等。當(dāng)然目前JDFS還僅僅支持上傳、下載功能，還不具備分布式文件管理的功能，這些都會(huì)在后續(xù)的開發(fā)過(guò)程中加進(jìn)來(lái)。在寫博客的過(guò)程中，筆者發(fā)現(xiàn)最好是每完成一個(gè)小的功能就及時(shí)用博客記錄下來(lái)，如果等功能全部實(shí)現(xiàn)完成后再寫博客的話，一方面由于功能點(diǎn)比較多，博客寫起來(lái)會(huì)比較費(fèi)力；另一方面由于時(shí)間間隔太長(zhǎng)，有些有價(jià)值的細(xì)節(jié)恐怕會(huì)忘記。所以最好是增量式寫博客，每實(shí)現(xiàn)一個(gè)關(guān)鍵點(diǎn)的功能，及時(shí)用博客記錄下來(lái)。本文是在該系列博客第一篇的基礎(chǔ)上做了部分更新升級(jí)以及解決一些小bug.當(dāng)然主要針對(duì)的是上傳部分的功能。如果讀者對(duì)這篇博客的背景不是太了解的話，請(qǐng)先移步筆者的上一篇博客：點(diǎn)擊我 。
根據(jù)上一篇博客我們知道，JDFS的服務(wù)端主程序在epoll里面先recv客戶端的數(shù)據(jù)，然后解析頭部，根據(jù)請(qǐng)求類型，把作業(yè)交給線程池來(lái)執(zhí)行。對(duì)于查詢、下載部分的功能這是沒有問(wèn)題的，因?yàn)椴樵儭⑾螺d部分客服端只是發(fā)送一個(gè)頭部過(guò)來(lái)，服務(wù)端接收后解析的過(guò)程不會(huì)太占用多少時(shí)間。而如果是上傳功能的話，服務(wù)端recv到的數(shù)據(jù)不僅包含頭部而且包含客服端期望上傳的文件實(shí)體的數(shù)據(jù)，而筆者的本意是讓線程池來(lái)接收數(shù)據(jù)的，所以這個(gè)代碼的實(shí)現(xiàn)與筆者的期望是矛盾的。本文首先就會(huì)對(duì)這一點(diǎn)進(jìn)行更新改進(jìn)，使得查詢、上傳、下載都可以并行的被線程池來(lái)執(zhí)行。
另外在上一篇博客中，上傳部分的功能代碼比較粗糙，這次也進(jìn)行了一些更新改進(jìn)。在筆者測(cè)試上傳功能的時(shí)候，發(fā)現(xiàn)了一些偶爾出現(xiàn)而且不容易重現(xiàn)的bug,而下載功能目前為止在筆者的測(cè)試過(guò)程當(dāng)中還沒有遇到過(guò)bug。所以從代碼實(shí)現(xiàn)以及測(cè)試的過(guò)程來(lái)看，上傳部分的功能要比下載部分復(fù)雜、更難調(diào)試。具體代碼實(shí)現(xiàn)請(qǐng)移步筆者的github鏈接：點(diǎn)擊我。
PS: 本篇博客是博客園用戶“cs小學(xué)生”的原創(chuàng)作品，轉(zhuǎn)載請(qǐng)注明原作者和原文鏈接，謝謝。
二 上傳功能演示
在上一篇博客中，筆者展示了上傳功能的截圖，但那個(gè)只有一個(gè)客戶端在向服務(wù)端上傳文件，在這里再補(bǔ)充一個(gè)同時(shí)有兩個(gè)客服端向服務(wù)端上傳文件的截圖。
在此次的上傳中(使用shell腳本來(lái)提交)，兩個(gè)客服端分別同時(shí)向服務(wù)端上傳不同的文件：CRLS-en.pdf和CRLS-e.pdf. 圖左半邊是服務(wù)端打印的一些信息，我們可以清晰的看到服務(wù)端交叉的接收CRLS-e.pdf和CRLS-en.pdf。圖右半邊是客服端打印的一些消息，我們也可以清晰的看到客服端也是交叉上傳兩個(gè)文件。服務(wù)端最后三次接收是：CRLS-e.pdf、CRLS-en.pdf、CRLS-en.pdf，客服端最后三次上傳的是CRLS-en.pdf、CRLS-e.pdf、CRLS-en.pdf，可見客服端上傳和服務(wù)端接收的文件的次序并不是一致的。但是從圖中我們也可以很容易的發(fā)現(xiàn):對(duì)于同一個(gè)文件，服務(wù)端接收的次序和客服端發(fā)送的次序是一致的。
下圖是服務(wù)端接收完成后的截圖：
