青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

Onway

我是一只菜菜菜菜鳥(niǎo)...
posts - 61, comments - 56, trackbacks - 0, articles - 34

一,簡(jiǎn)介
一個(gè)歷史項(xiàng)目里面用了c# .net 2.0的FtpWebRequest進(jìn)行文件上傳;ftp server在各現(xiàn)場(chǎng)用的應(yīng)該都是Filezilla。
因業(yè)務(wù)發(fā)展,需要上傳大文件(500M以上吧),某現(xiàn)場(chǎng)就出現(xiàn)了上傳失敗的情況。

二,網(wǎng)絡(luò)問(wèn)題
最開(kāi)始的代碼里面并沒(méi)有記錄上傳失敗的具體原因,或者說(shuō)log記錄沒(méi)能準(zhǔn)確定位問(wèn)題。
代碼修改后還是沒(méi)能準(zhǔn)確定位問(wèn)題。
但從log判斷,似乎是網(wǎng)絡(luò)斷開(kāi)造成的。
這想到可能現(xiàn)場(chǎng)網(wǎng)絡(luò)不穩(wěn)定,有瞬斷情況。

三,斷點(diǎn)續(xù)傳
聽(tīng)過(guò)斷點(diǎn)續(xù)傳,在百度找了些代碼,修改一下封裝好嵌到項(xiàng)目里面。
當(dāng)時(shí)只在網(wǎng)絡(luò)暢通的情況下測(cè)試過(guò),代碼也沒(méi)還checkin,發(fā)現(xiàn)場(chǎng)用戶也試試。
反饋還是不行。
看log更加迷糊了,堆棧顯示在FtpWebRequest.GetRequestStream.Close里面拋出來(lái)的異常。
想不明白啊。

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

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

6,似乎只能傻逼了
下班路上想到,出現(xiàn)異常的時(shí)候,一個(gè)close也不調(diào)用,無(wú)論是否重新連接,因?yàn)榫W(wǎng)絡(luò)已經(jīng)不通了,server應(yīng)該還hold住一個(gè)連接,把文件鎖住了。
這應(yīng)該就是上面異常的情況,文件被鎖了,新連接就沒(méi)法操作這個(gè)文件,看server log,確實(shí)有這個(gè)cann't access file的記錄。
那很好,client出異常了,等一個(gè)足夠長(zhǎng)的時(shí)間,等到server將連接斷開(kāi)就好了,close也就不管了。
但想想這也太傻逼了啊,這得等到什么時(shí)候啊。

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

8,來(lái)都來(lái)了
這個(gè)abort做了什么鬼呢,想用wireshark抓個(gè)包看看,無(wú)奈不懂,十來(lái)分鐘連個(gè)filter都沒(méi)寫(xiě)好。
難道是50%的丟包不夠強(qiáng)悍,abort還是有數(shù)據(jù)逃出去了?
后來(lái)百度知道wireshark在windows下要做特殊處理才能抓取本地?cái)?shù)據(jù)包。
無(wú)奈增加本機(jī)路由后filezilla server連不上了,最后下了個(gè)手機(jī)ftp server。
發(fā)現(xiàn)abort也沒(méi)什么特殊的地方,只是通知ftp釋放控制連接和數(shù)據(jù)連接然后馬上返回,連接能不能斷掉就聽(tīng)天由命了。
100%丟包率的時(shí)候,filezilla還真有連接會(huì)鎖死文件。

posted @ 2015-07-11 15:38 Onway 閱讀(1299) | 評(píng)論 (0)編輯 收藏

1,三個(gè)部分
4字節(jié)的單精度浮點(diǎn)數(shù)32個(gè)位分3個(gè)部分:
1.1,從左往右第一位是符號(hào)位,0正1負(fù);
1.2,緊接的8個(gè)位是指數(shù)部分,不要糾結(jié)是原碼,反碼還是補(bǔ)碼,只是一個(gè)不帶符號(hào)位的二進(jìn)制數(shù),都一樣。取值區(qū)間是[0,255],0和255有特殊含義;取值在[1,254]的情況下,需要減去127才是真正的指數(shù)值,這時(shí)指數(shù)取值是[-126,127]。
1.3,剩余的23位是尾數(shù)部分,用于表示浮點(diǎn)數(shù)的小數(shù)部分;也是一個(gè)不帶符號(hào)位的二進(jìn)制數(shù)。

2,指數(shù)部分
2.1,當(dāng)指數(shù)部分是0,且尾數(shù)部分為全0的情況,這表示浮點(diǎn)數(shù)0;加上符號(hào)位表示正負(fù)0。
2.2,當(dāng)指數(shù)部分是0,且尾數(shù)部分不為0的情況,其實(shí)際指數(shù)是-126,二進(jìn)制表示的科學(xué)計(jì)數(shù)法的浮點(diǎn)數(shù)的整數(shù)部分按0解析。
2.3,當(dāng)指數(shù)部分是255,且尾數(shù)部分為全0的情況,表示一個(gè)無(wú)窮數(shù);加上符號(hào)位表示正反無(wú)窮。
2.4,當(dāng)指數(shù)部分是255,且尾數(shù)部分不為0的情況,表示不是一個(gè)有效數(shù)字,NaN。
2.5,當(dāng)指數(shù)部分取值為[1,254]的情況,需要減去127才是實(shí)際指數(shù)值,二進(jìn)制表示的科學(xué)計(jì)數(shù)法的浮點(diǎn)數(shù)的整數(shù)部分按1解析。

3,浮點(diǎn)書(shū)的規(guī)約形式與非規(guī)約形式
3.1,上述的第二種情況的浮點(diǎn)數(shù)稱為非規(guī)約浮點(diǎn)數(shù);上述的第五種情況的浮點(diǎn)數(shù)稱為規(guī)約浮點(diǎn)數(shù)。
3.2,最小的規(guī)約浮點(diǎn)數(shù)是指數(shù)部分是1(實(shí)際指數(shù)是-126),尾數(shù)部分為全0的時(shí)候,絕對(duì)值為1 * 2 ^ -126 ;
次小的規(guī)約浮點(diǎn)數(shù)是指數(shù)部分為1,尾數(shù)部分最低位為1其余位為0的時(shí)候,絕對(duì)值為1.000...1 * 2 ^ -126;
它們之間的絕對(duì)差值為(1.000...1 - 1) * 2 ^ -126 = 2 ^ -23 * 2 ^ -126 = 2 ^ -149;
而最小規(guī)約數(shù)與0的絕對(duì)差值是1 * 2 ^ -126 = 2 ^ -126。
在坐標(biāo)軸的表現(xiàn)是,兩個(gè)非0的規(guī)范浮點(diǎn)數(shù)的間隔很小,而最小規(guī)約浮點(diǎn)數(shù)與0的間隔很大,差距是23倍。
3.3,引入非規(guī)約形式的浮點(diǎn)數(shù),可以使得0與最小規(guī)約浮點(diǎn)數(shù)的間隔變得均勻起來(lái),并且間隔與兩個(gè)相鄰規(guī)約浮點(diǎn)數(shù)的間隔一致。
兩個(gè)非規(guī)約浮點(diǎn)數(shù)的間隔都是0.000...1 * 2 ^ -126 = 2 ^ -149。
3.4,最大的非規(guī)約數(shù)是0.111...111 * 2 ^ -126,最小的規(guī)約數(shù)是1.000..0 * 2 ^ -126;
最大的非規(guī)約總是小于最小的規(guī)約數(shù),也可以認(rèn)識(shí)近似相等。

4,浮點(diǎn)數(shù)舍入
4.1,四舍六入五成雙。
Math.Round()
4.2,向0(截?cái)啵┥崛?/span>
整型強(qiáng)制轉(zhuǎn)換
4.3,向負(fù)無(wú)窮大
Math.Floor()
4.4,向正無(wú)窮大
Math.Ceiling()

posted @ 2015-06-14 17:41 Onway 閱讀(650) | 評(píng)論 (0)編輯 收藏

python程序里面需要執(zhí)行一個(gè)系統(tǒng)命令程序,如果命令在限定時(shí)間之內(nèi)結(jié)束,則python程序讀取其輸出(如果有)并馬上返回,否則強(qiáng)行終止命令程序。
原本這個(gè)功能是用系統(tǒng)信號(hào)SIGALARM和python的異常解決的,但這不能用在多線程的環(huán)境里。然后考慮用threading.Timer進(jìn)行計(jì)時(shí),但這個(gè)計(jì)時(shí)是在一個(gè)單獨(dú)線程進(jìn)行的,如何將超時(shí)信息傳給主線程也是一個(gè)問(wèn)題。
百度一下,用select可以解決需求:
但select并不完美,當(dāng)命令程序輸出的內(nèi)容多于管道容量的時(shí)候,select就會(huì)返回,如果此時(shí)命令程序再進(jìn)入阻塞,則時(shí)間限制就不起作用了。

select.py:
import select
import subprocess

popen = subprocess.Popen("./test.sh", stdout=subprocess.PIPE)
fs = select.select([popen.stdout], [], [], 3)
if popen.stdout in fs[0]:
    output = popen.stdout.read()
    print len(output)
else:
    print "timeout"

test.sh:
#!/bin/bash

# a.txt contains 65536 characters

cat a.txt
sleep 10
cat a.txt

posted @ 2013-05-10 21:26 Onway 閱讀(2790) | 評(píng)論 (0)編輯 收藏

使用getrusage得到的資源統(tǒng)計(jì)的類型較多,測(cè)試代碼是僅針對(duì)ru_utime, ru_stime, ru_minflt三種類型的資源。
測(cè)試環(huán)境:Linux kubuntu 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 12:39:51 UTC 2013 i686 i686 i386 GNU/Linux
結(jié)論:父進(jìn)程fork得到的子進(jìn)程的資源使用被重置,子進(jìn)程使用execve之后的資源使用不變。
parent.c:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/time.h>
#include <sys/resource.h>

void
print_rusage(const char * where)
{
    struct rusage used;
    getrusage(RUSAGE_SELF, &used);

    printf("In %s:\n", where);
    printf("user cpu time: %ld(ms)\n",
            used.ru_utime.tv_sec * 1000 + used.ru_utime.tv_usec / 1000);
    printf("sys cpu time: %ld(ms)\n",
            used.ru_stime.tv_sec * 1000 + used.ru_stime.tv_usec / 1000);
    printf("soft page faults: %ld\n", used.ru_minflt);
    printf("\n");
}

void
consume_rusage()
{
    int i, j, k;
    char * s = NULL;

    /* about 3 seconds user cpu time */
    for (i = 0; i < 1000; ++i)
        for (j = 0; j < 1000; ++j)
            for (k = 0; k < 1000; ++k)
                i / (j + 1) * k;
    
    /* 1000 soft page faults */
    k = 4096 * 1000;
    s = (char *)malloc(k);
    for (i = 0; i < k; ++i)
        s[i] = 'a';
}

int
main(int argc, char *argv[])
{
    consume_rusage();
    print_rusage("parent process");

    if (fork() == 0) {
        print_rusage("child process, after fork");
        printf("consuming resource \n\n");
        consume_rusage();
        print_rusage("child process, before execve");
        printf("excl child program now \n\n");
        execl("./child", "./child", (void *)0);
    }

    wait(NULL);
    return 0;
}

child.c:
#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>

void
print_rusage(const char * where)
{
    struct rusage used;
    getrusage(RUSAGE_SELF, &used);

    printf("In %s:\n", where);
    printf("user cpu time: %ld(ms)\n",
            used.ru_utime.tv_sec * 1000 + used.ru_utime.tv_usec / 1000);
    printf("sys cpu time: %ld(ms)\n",
            used.ru_stime.tv_sec * 1000 + used.ru_stime.tv_usec / 1000);
    printf("soft page faults: %ld\n", used.ru_minflt);
    printf("\n");
}

int
main(int argc, char *argv[])
{
    print_rusage("child program");
    return 0;
}   

好久沒(méi)寫(xiě)博客了,密碼都快忘記了。寫(xiě)給自己的記憶。

posted @ 2013-05-10 20:21 Onway 閱讀(2567) | 評(píng)論 (2)編輯 收藏

     摘要: 更新說(shuō)明:
a,去掉了本地單詞本功能
b,增加了simple選項(xiàng)查詞
c,detail選項(xiàng)查詞更新到有道詞典的5.1.38.3211版本
d,收錄skyhacker的pyfanyi(那是完全不一樣的界面風(fēng)格)
下載:
https://sourceforge.net/projects/eyoudao/files/  閱讀全文

posted @ 2012-10-22 13:52 Onway 閱讀(2712) | 評(píng)論 (9)編輯 收藏








我以為自己已經(jīng)上傳過(guò)0.1.0的了,原來(lái)沒(méi)有。

在原來(lái)那篇“OnlineJudge監(jiān)測(cè)程序”的基礎(chǔ)上,添加了后臺(tái)守護(hù)進(jìn)程和單機(jī)測(cè)試網(wǎng)頁(yè)。

信號(hào)處理和系統(tǒng)調(diào)用規(guī)則,依然不完善。
依然沒(méi)有使用chroot限制根目錄,頭文件,動(dòng)態(tài)庫(kù)這些內(nèi)容還是不會(huì)限制。
java程序的內(nèi)存統(tǒng)計(jì),依然包含了虛擬機(jī)內(nèi)存。

在SourceForge搗鼓了好幾天了,還是不太熟悉。
下載地址:http://sourceforge.net/projects/anoj/files/
安裝包里有依賴,安裝等說(shuō)明。

純粹學(xué)習(xí)吧,跟HDOJ和POJ比,還差遠(yuǎn)著呢。
如有建議,博客留言或聯(lián)系aluohuai@126.com

posted @ 2012-09-18 11:44 Onway 閱讀(1179) | 評(píng)論 (0)編輯 收藏

今年四月底為一份實(shí)習(xí)參與了一個(gè)在線挑戰(zhàn),選題是linux平臺(tái)的一個(gè)http服務(wù)器,一個(gè)星期多點(diǎn)完成交上去,然后就沒(méi)然后了。
昨晚拿出來(lái)運(yùn)行一下,打開(kāi)幾個(gè)源碼文件,看著感覺(jué)是挺不懂事的。
無(wú)論是代碼風(fēng)格,程序結(jié)構(gòu),實(shí)現(xiàn)技術(shù),還是標(biāo)準(zhǔn)支持,安全性什么都是慘不忍睹的。
但做這個(gè)東西的時(shí)候感覺(jué)是煞有介事的,也用到了線程技術(shù),實(shí)現(xiàn)了CGI,也做了文檔什么的,也算是系統(tǒng)編程的開(kāi)始吧,因此寫(xiě)文一篇緬懷一下。

昨晚想到,有沒(méi)必要做一個(gè)本地瀏覽器接口程序?其實(shí)也就是一個(gè)監(jiān)聽(tīng)localhost的http服務(wù)器程序。
一些簡(jiǎn)單的單機(jī)交互程序,跑命令行不方便,雖然用圖形庫(kù)寫(xiě)個(gè)界面也是不難的事,但為了一個(gè)界面幾個(gè)按鈕去學(xué)個(gè)圖形庫(kù)就比較糾結(jié)了。
想法是這樣簡(jiǎn)單的界面可以用瀏覽器做,服務(wù)程序作為本地程序和瀏覽器之間的橋梁。
當(dāng)然如果覺(jué)得裝個(gè)apache更容易的話,那是無(wú)話說(shuō)了。
只是簡(jiǎn)單記錄一下想法,具體還需更多的需求分析和論證。

posted @ 2012-08-24 15:25 Onway 閱讀(263) | 評(píng)論 (0)編輯 收藏

     摘要: 3,運(yùn)行監(jiān)測(cè)程序:
./a.out -t time -m memory -f fsize --basedir a_temp_working_directory --datadir input_answer_files_directory \
--who user_and_group_ID --magic a_random_string --end java Main
解釋:
-t,時(shí)間限制,單位ms
-m,內(nèi)存限制,單位kb
-f,輸出限制,單位kb
--basedir,工作目錄
--datadir,存放輸入和答案文件的目錄,必須包含了ojdlck生成的data.conf文件
--who,運(yùn)行用戶程序的用戶ID和組ID,建議為系統(tǒng)的nobody用戶
--magic,用于在工作目錄產(chǎn)生輸出的文件名
--end,標(biāo)志所有的參數(shù)輸入完畢,接下來(lái)的參數(shù)都會(huì)視為用戶程序及其參數(shù)
例如:
./a.out -t 1000 -m 65536 -f 4096 --basedir /tmp --dat  閱讀全文

posted @ 2012-08-20 00:35 Onway 閱讀(2003) | 評(píng)論 (1)編輯 收藏


更新說(shuō)明:
    a,result.xsl在<body>之后加入了兩個(gè)html子元素。
    b,classify.txt分類支持空格
    c,選擇單詞分類不再使用zenity,而是直接在顯示的網(wǎng)頁(yè)中添加。
    d,單詞本復(fù)習(xí)支持短語(yǔ),增加了兩個(gè)模式,背誦模式是將選中的單詞批量下載到一個(gè)文件,復(fù)習(xí)模式是顯示單詞和釋義,不記入數(shù)據(jù)庫(kù)。
    e,改變了安裝方式,不再?gòu)膍akefile文件編譯,而是預(yù)先拷貝預(yù)先的編譯好的可執(zhí)行文件。(檢測(cè)了ubuntu,fedora,centos三個(gè)系統(tǒng),xslt程序使用的動(dòng)態(tài)庫(kù)都能在系統(tǒng)里找到)
下載:
/Files/Onway/eyoudao-1.2.tar.gz.rar

posted @ 2012-06-08 11:11 Onway 閱讀(2420) | 評(píng)論 (14)編輯 收藏

     摘要:
摘自《c專家編程》,代碼和答案都是基于gcc 4.6.1和32位linux系統(tǒng)。
某些解釋不夠全面和正確,如果是錯(cuò)誤,請(qǐng)指正。

1,解釋該聲明的含義:
char * const *(*next)();  閱讀全文

posted @ 2012-05-28 11:52 Onway 閱讀(396) | 評(píng)論 (0)編輯 收藏

僅列出標(biāo)題
共6頁(yè): 1 2 3 4 5 6 
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            午夜日韩在线| 香蕉国产精品偷在线观看不卡| 欧美日韩二区三区| 欧美精品在线免费| 欧美日韩亚洲高清一区二区| 欧美激情一区二区三区在线视频观看 | 一区二区三区精密机械公司| 99成人在线| 亚洲在线观看视频网站| 亚洲尤物视频网| 久久精品国产免费看久久精品| 久热成人在线视频| 日韩视频免费在线| 久久成人18免费网站| 欧美va亚洲va香蕉在线| 国产精品久久久久久久app| 一区二区视频免费完整版观看| 亚洲精品在线免费观看视频| 亚洲一区二区动漫| 久久午夜羞羞影院免费观看| 亚洲看片网站| 久久精品麻豆| 国产精品久久久久久久久久三级| 加勒比av一区二区| 一区二区欧美视频| 久久综合狠狠综合久久综合88| 亚洲日本成人网| 午夜视黄欧洲亚洲| 欧美日韩一区二区三区| 国产一区二区三区精品久久久| 亚洲精品一区在线观看香蕉| 久久精品一区二区三区四区 | 亚洲国产精品一区二区尤物区| 99视频一区| 欧美福利电影网| 欧美电影美腿模特1979在线看| 亚洲在线观看免费视频| 久久婷婷成人综合色| 国产精品久久网站| 日韩图片一区| 欧美激情第9页| 久久九九免费视频| 国产一区二区按摩在线观看| 亚洲一区二区三区免费视频| 亚洲国产成人精品久久久国产成人一区| 亚洲欧美激情一区二区| 欧美女人交a| 亚洲精品九九| 欧美国产一区视频在线观看| 欧美在线999| 国产日韩精品久久| 欧美影院视频| 欧美一级淫片aaaaaaa视频| 国产精品高清免费在线观看| 亚洲视频在线观看三级| 亚洲精品社区| 欧美日韩精品在线视频| 一本色道久久综合亚洲精品不| 亚洲福利视频三区| 免费欧美电影| 亚洲精品视频免费观看| 亚洲黄色免费| 欧美精品性视频| 艳妇臀荡乳欲伦亚洲一区| 亚洲精品一区在线| 欧美日韩免费区域视频在线观看| 99精品欧美一区二区三区| 91久久在线| 欧美午夜宅男影院| 欧美一级在线视频| 欧美在线一区二区三区| 在线电影国产精品| 欧美高清视频一区| 欧美日韩91| 小处雏高清一区二区三区| 午夜精品一区二区三区电影天堂| 国产日韩一区欧美| 免费不卡在线视频| 欧美激情精品久久久久久蜜臀| 亚洲毛片视频| 亚洲专区在线| 亚洲电影中文字幕| 日韩视频在线你懂得| 国产精品视频免费观看| 久久美女艺术照精彩视频福利播放| 欧美一区成人| 亚洲日本一区二区| 亚洲伊人观看| 亚洲欧洲一区二区天堂久久| 一级日韩一区在线观看| 国产真实乱偷精品视频免| 欧美黑人在线观看| 国产精品视频大全| 欧美国产第二页| 国产精品国产三级国产专播精品人| 久久精品中文| 欧美日韩高清在线播放| 午夜久久黄色| 一区二区三区国产精华| 欧美一级电影久久| 亚洲免费播放| 久久gogo国模裸体人体| 一区二区三区鲁丝不卡| 久久一区二区三区四区五区| 亚洲天堂av图片| 久久精品国产成人| 亚洲一区二区三区精品动漫| 久久九九有精品国产23| 亚洲性感美女99在线| 久久综合久色欧美综合狠狠| 亚洲一区亚洲二区| 久热精品视频在线免费观看| 亚洲欧美区自拍先锋| 蜜桃久久av| 久久久免费av| 国产欧美精品一区aⅴ影院| 亚洲精选在线| 亚洲精品美女在线观看| 久久久精品一品道一区| 欧美一区二区高清| 欧美视频免费看| 亚洲精品1区2区| 亚洲国产一区在线| 免费日韩av| 欧美激情精品久久久久久变态| 国产亚洲欧美日韩一区二区| 99精品欧美一区二区三区综合在线| 亚洲激情在线观看视频免费| 久久免费精品日本久久中文字幕| 欧美一区二区三区视频在线观看| 欧美日韩小视频| 亚洲另类视频| 中文网丁香综合网| 国产精品久久久久天堂| 亚洲图片激情小说| 亚洲欧美久久久| 国产精品亚洲一区| 新67194成人永久网站| 香蕉国产精品偷在线观看不卡 | 欧美激情1区2区3区| 欧美91大片| 亚洲国产精品小视频| 久久综合九色99| 亚洲高清毛片| 亚洲伦理在线观看| 欧美区在线观看| 一区二区三区产品免费精品久久75| 99精品免费视频| 欧美日精品一区视频| 亚洲一级网站| 久久国产精品99久久久久久老狼 | 一区二区三区中文在线观看| 久久精品视频va| 欧美国产欧美亚洲国产日韩mv天天看完整 | 新片速递亚洲合集欧美合集| 久久久久国产精品一区| 欧美国产激情| 激情欧美一区| 久久成人18免费观看| 欧美电影免费观看高清| 9人人澡人人爽人人精品| 欧美日韩精品久久| 亚洲在线黄色| 欧美高清视频在线播放| 亚洲一区二区免费视频| 国产精品专区第二| 久久免费偷拍视频| 亚洲精品网站在线播放gif| 久久超碰97中文字幕| 亚洲电影自拍| 国产精品国产三级国产专播精品人 | 亚洲午夜精品久久久久久浪潮 | 亚洲自拍啪啪| 欧美福利小视频| 午夜精品理论片| 亚洲激情影视| 国产亚洲精品久久飘花| 欧美另类videos死尸| 欧美一区二区视频在线观看| 亚洲欧洲一区二区三区| 久久精品人人爽| 亚洲无限av看| 亚洲电影免费| 国产午夜精品在线观看| 欧美精品午夜| 老司机精品福利视频| 亚洲免费视频中文字幕| 91久久久久久| 欧美电影在线观看完整版| 欧美一级播放| 国产精品99久久99久久久二8| 在线播放中文一区| 国产免费成人| 国产精品久久久一本精品| 欧美顶级艳妇交换群宴| 久久精品女人的天堂av| 亚洲一区二区三区乱码aⅴ蜜桃女| 亚洲国产精品久久久久| 蜜臀久久久99精品久久久久久| 欧美一区二区高清|