• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Onway

            我是一只菜菜菜菜鳥...
            posts - 61, comments - 56, trackbacks - 0, articles - 34

            FtpWebRequest

            Posted on 2015-07-11 15:38 Onway 閱讀(1277) 評論(0)  編輯 收藏 引用 所屬分類: 碼兒快跑
            一,簡介
            一個歷史項目里面用了c# .net 2.0的FtpWebRequest進行文件上傳;ftp server在各現場用的應該都是Filezilla。
            因業(yè)務發(fā)展,需要上傳大文件(500M以上吧),某現場就出現了上傳失敗的情況。

            二,網絡問題
            最開始的代碼里面并沒有記錄上傳失敗的具體原因,或者說log記錄沒能準確定位問題。
            代碼修改后還是沒能準確定位問題。
            但從log判斷,似乎是網絡斷開造成的。
            這想到可能現場網絡不穩(wěn)定,有瞬斷情況。

            三,斷點續(xù)傳
            聽過斷點續(xù)傳,在百度找了些代碼,修改一下封裝好嵌到項目里面。
            當時只在網絡暢通的情況下測試過,代碼也沒還checkin,發(fā)現場用戶也試試。
            反饋還是不行。
            看log更加迷糊了,堆棧顯示在FtpWebRequest.GetRequestStream.Close里面拋出來的異常。
            想不明白啊。

            四,重現爛網絡
            去過現場出差的同事反應,現場的網絡真的好爛。
            這想到怎么去模擬一個爛網絡出來。
            找到一個程序叫clumsy,http://jagt.github.io/clumsy/
            設置延時50ms,50%的丟包率,丫的那個異常堆棧重現出來了。
            異常信息如下:
            這應該說的,連接已經斷開了,再關的話就報錯了。
            程序調試進去發(fā)現,最早引發(fā)異常的是FtpWebRequest.GetRequestStream.Write,程序里面是有catch,但只是記錄了失敗的位置偏移以便下次重傳,也沒有去記錄失敗原因。
            當時close的調用是放在finally塊里面的,這個close引發(fā)的異常導致續(xù)傳沒能繼續(xù)執(zhí)行,log記錄的堆棧也就是從這里開始。

            五,重現了也沒個屁用啊
            既然close不掉,那就直接跳到FtpWebRequest.GetResponse.Close好了。
            還真不報異常了,GetResponse就直接阻塞了,一直塞到ftp server都超時斷開了,還沒返回。
            看了一下msdn,說好的FtpWebRequest.Timeout咋的沒生效呢?FtpWebRequest.ReadWriteTimeout可是好好的呢。
            google+stackoverflow也沒找到解決,倒是找到一些吐槽FtpWebRequest和Ftp庫推薦的。
            莫非還真得換庫或者直接調些ftp命令?
            同時stackoverflow發(fā)了第一個問題,我只想知道為什么不超時也不返回,因為我連GetResponse.Close都不調用就直接開始下一次重傳的話,會報另一個異常如下:
            不造是否英語太爛,或者是問題沒到點子上,問題沉了。

            6,似乎只能傻逼了
            下班路上想到,出現異常的時候,一個close也不調用,無論是否重新連接,因為網絡已經不通了,server應該還hold住一個連接,把文件鎖住了。
            這應該就是上面異常的情況,文件被鎖了,新連接就沒法操作這個文件,看server log,確實有這個cann't access file的記錄。
            那很好,client出異常了,等一個足夠長的時間,等到server將連接斷開就好了,close也就不管了。
            但想想這也太傻逼了啊,這得等到什么時候啊。

            7,也算徹底解決了,反正可以交貨了
            試了一下filezilla client,有斷點續(xù)傳功能,發(fā)現網絡異常斷開,開始續(xù)傳連接開始之前,server那個連接總會很快斷開。
            這又是怎么解析呢,不是說網絡都不通了,server那個連接是怎么放掉的呢?
            google一下,stackoverflow上看到FtpWebRequest有個Abort函數,說是斷開一個異步請求。
            一試,我同步連接也能斷開啊,網絡異常,啥都不close,直接abort,server那個連接就斷了,很快也就可以重傳了呢。

            8,來都來了
            這個abort做了什么鬼呢,想用wireshark抓個包看看,無奈不懂,十來分鐘連個filter都沒寫好。
            難道是50%的丟包不夠強悍,abort還是有數據逃出去了?
            后來百度知道wireshark在windows下要做特殊處理才能抓取本地數據包。
            無奈增加本機路由后filezilla server連不上了,最后下了個手機ftp server。
            發(fā)現abort也沒什么特殊的地方,只是通知ftp釋放控制連接和數據連接然后馬上返回,連接能不能斷掉就聽天由命了。
            100%丟包率的時候,filezilla還真有連接會鎖死文件。
            日韩欧美亚洲综合久久影院d3| 久久性精品| 91视频国产91久久久| 精品一区二区久久久久久久网站| 2021精品国产综合久久| 91精品观看91久久久久久| 性做久久久久久久久老女人| 一本色道久久综合狠狠躁| 99国产精品久久久久久久成人热| 久久精品无码免费不卡| 久久天天躁狠狠躁夜夜躁2014| 久久综合综合久久狠狠狠97色88| 久久精品国产亚洲av瑜伽| 日韩乱码人妻无码中文字幕久久 | 久久久久无码精品| 久久久久久久久久久| 精品久久久久久无码人妻热| 精产国品久久一二三产区区别| 久久精品视频网| 伊人久久综合无码成人网| 久久精品无码一区二区app| 97久久精品无码一区二区 | 亚洲AV无码久久| 久久夜色撩人精品国产| 一级做a爰片久久毛片人呢| 色综合久久中文字幕无码| 日韩欧美亚洲国产精品字幕久久久 | 久久96国产精品久久久| av色综合久久天堂av色综合在| 久久www免费人成精品香蕉| 久久久久成人精品无码中文字幕 | 精品熟女少妇AV免费久久 | 亚洲国产成人久久综合一| 亚洲精品无码久久一线| 日本精品一区二区久久久| 国产高清国内精品福利99久久| 97精品久久天干天天天按摩| 精品人妻久久久久久888| 久久亚洲国产成人精品性色| 人妻丰满AV无码久久不卡 | 一本一道久久a久久精品综合|