• <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還真有連接會鎖死文件。
            久久久久国色AV免费看图片| 久久这里有精品| 天天综合久久一二三区| 久久w5ww成w人免费| 热久久视久久精品18| 亚洲国产成人久久综合区| 久久WWW免费人成—看片| 天天久久狠狠色综合| 青青青青久久精品国产| 国产69精品久久久久777| 国产精品久久久久久福利漫画 | 国产午夜福利精品久久2021| 久久久久av无码免费网| 一级a性色生活片久久无| 亚洲精品WWW久久久久久| 久久久久久青草大香综合精品| 国产AV影片久久久久久| 久久久国产精华液| 一本色道久久88综合日韩精品 | 亚洲伊人久久精品影院| 亚洲精品无码久久毛片| 色天使久久综合网天天| 97久久婷婷五月综合色d啪蜜芽| 亚洲香蕉网久久综合影视| 久久久精品2019免费观看| 狠狠色丁香婷婷久久综合不卡| 精品久久一区二区三区| 精品久久久久久久久久中文字幕| 狠狠精品久久久无码中文字幕| 久久av高潮av无码av喷吹| 亚洲精品无码久久不卡| 久久久亚洲欧洲日产国码二区| 久久国产乱子精品免费女| 国产精品久久久99| 久久热这里只有精品在线观看| 日韩精品久久久肉伦网站 | 精品水蜜桃久久久久久久| 亚洲国产综合久久天堂| 成人综合伊人五月婷久久| 久久精品成人免费观看97| 精品综合久久久久久98|