• <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>

            2012年8月28日

            關(guān)于微信和QQ的一點思考

            微信要打敗qq,如果僅僅局限于陌生人交友,是肯定不行的。所以現(xiàn)在微信會兼顧陌生人交友和熟人交友。因為陌生人交友的模式是調(diào)動大家獵奇、嘗試新鮮的欲望,如果大家都想去“約炮”,但是又經(jīng)常約不到,就會漸漸失去對它的好奇和新鮮刺激感,那么微信的發(fā)展就會遇到瓶頸。qq最大的優(yōu)勢在于它的用戶關(guān)系鏈,用戶關(guān)系鏈是強聯(lián)系的,用戶很難從它轉(zhuǎn)到別處,當(dāng)然現(xiàn)在微信的快速發(fā)展也是離不開qq的支持的,比如從qq導(dǎo)入好友到微信。所以qq被微信取代的可能性還不是很大,應(yīng)該是互補的,兩強并立。微信的火并不一定在于它的功能強大,或者創(chuàng)新(如搖一搖、漂流瓶),火的本質(zhì)原因在于用戶的“約炮”需求,這也是陌陌能異軍突起的原因,而相比之下,米聊就后勁不足,因為它沒有抓住這個本質(zhì)需求。

            由于一開始大部分人的的“約炮”需求無法得到滿足,繼而對于陌生人交友工具的使用會由原來的原始“約炮”需求,進化為“結(jié)識新朋友”的需求,現(xiàn)代大部分人都花費大量時間在互聯(lián)網(wǎng)上,與人接觸的時間會比較少,剩男剩女、宅男宅女很多,這部分需求會比較大,也比較不那么原始。相信不久后會是這部分需求來主導(dǎo)陌生人交友工具的發(fā)展。

            posted @ 2012-08-28 18:24 MrRightLeft 閱讀(2663) | 評論 (8)編輯 收藏

            2012年7月17日

            redis源碼剖析-main流程

            一、redis運行流程
            以下是redis main函數(shù)的運行流程


            posted @ 2012-07-17 13:28 MrRightLeft 閱讀(1145) | 評論 (0)編輯 收藏

            2012年7月15日

            socket accept()返回的socket描述符的端口和listen描述符端口是一樣的嗎?

            as you know,一個socket是由一個五元組來唯一標示的,即(協(xié)議,server_ip, server_port, client_ip, client_port)。只要該五元組中任何一個值不同,則其代表的socket就不同。這里忽略協(xié)議的區(qū)別,在同一協(xié)議的基礎(chǔ)上,服務(wù)器端的listen socket的端口可以看成(server_ip, server_port, ***, ***),其中***是通配符,它跟任何一個client_ip, client_port值都不同,可以簡單看成是(0,0)對,當(dāng)然實現(xiàn)不是這樣的。這樣在服務(wù)器端accept之后,返回的連接socket的四元組就是(server_ip, server_port, client_ip, client_port),這里的client_ip,client_port因連接的客戶端的不同而不同。所以accept返回的socket和listen socket是不同的,不同之處就在于四元組中的客戶端ip和port,而服務(wù)器端的server_ip和server_port還是相同的,也就是accpet()函數(shù)返回的新的socket描述符的端口和listen端口是一樣的。可以使用getsockname()函數(shù)來查看它們之間的不同。

            posted @ 2012-07-15 21:01 MrRightLeft 閱讀(3900) | 評論 (2)編輯 收藏

            2012年7月13日

            同步io與異步io

            詳見《unix網(wǎng)絡(luò)編程 第1卷:套接口API》 p136
            阻塞io模型、非阻塞io模型、I/O復(fù)用模型和信號驅(qū)動I/O模型都是同步io模型,因為其中真正的io操作將阻塞進程。只有異步I/O模型才是異步的

            posted @ 2012-07-13 15:45 MrRightLeft 閱讀(356) | 評論 (0)編輯 收藏

            socket close_on_exec

            socket close_on_exec

            父進程fork子進程后,子進程會復(fù)制父進程的socket描述符。如果想讓子進程在exec時,釋放掉所擁有的父進程的socket描述符,可以設(shè)置父進程的socket close_on_exec特性。
             if( fcntl(iSockFd, F_GETFD, arg) < 0 )   /* 這個很重要,要不下面設(shè)置不成功 */
             {
                  exit(-1);
             }
             
             arg |= FD_CLOEXEC;
             
             if( fcntl(iSockFd, F_SETFD, 1) < 0 )
             {
                  exit(-1);
             }

            posted @ 2012-07-13 15:08 MrRightLeft 閱讀(696) | 評論 (0)編輯 收藏

            2012年7月12日

            SO_REUSEADDR

            SO_REUSEADDR

            編寫 TCP/SOCK_STREAM 服務(wù)程序時,SO_REUSEADDR到底什么意思?這個套接字選項通知內(nèi)核,如果端口忙,但TCP狀態(tài)位于 TIME_WAIT ,可以重用端口。如果端口忙,而TCP狀態(tài)位于其他狀態(tài),重用端口時依舊得到一個錯誤信息, 指明"地址已經(jīng)使用中"。如果你的服務(wù)程序停止后想立即重啟,而新套接字依舊使用同一端口,此時SO_REUSEADDR 選項非常有用。必須意識到,此時任何非期望數(shù)據(jù)到達,都可能導(dǎo)致服務(wù)程序反應(yīng)混亂,不過這只是一種可能,事實上很不可能。 

            posted @ 2012-07-12 17:16 MrRightLeft 閱讀(530) | 評論 (0)編輯 收藏

            linux 文件操作之close

            #include <iostream>
            #include 
            <fcntl.h>
            using namespace std;

            int main()
            {
                
            int fd = open("demo.txt", O_RDWR, 0);
                close(fd);
                
            int fd1 = open("demo1.txt", O_RDWR, 0);
                
            char *szMsg = "hello";
                
            int size = write(fd, szMsg, strlen(szMsg)+1);
                
            if (-1 == size)
                
            {
                     cerr 
            << "error!" << endl;
                }

                close(fd1);
                
            return 0;
            }
            猜一下上面程序的執(zhí)行結(jié)果。
            在write時,fd和fd1的值是一樣的,write fd時,實際就是write fd1。
            為了避免自己在程序中誤操作,可以在close(fd)之后,加上fd = -1;

            posted @ 2012-07-12 16:13 MrRightLeft 閱讀(1057) | 評論 (0)編輯 收藏

            2012年7月3日

            redis源碼剖析-字符串

            redis源碼剖析-字符串

            redis實現(xiàn)了自己的字符串結(jié)構(gòu)。在文件sds.h/dsd.c中定義。redis中的字符串叫sds(simple dynamic string)。
            sds實質(zhì)是char*:
            typedef char *sds;
            sds通過sdsnewlen()函數(shù)來創(chuàng)建,sds sdsnewlen(const void *init, size_t initlen)。該函數(shù)內(nèi)部會創(chuàng)建一個sdshdr的結(jié)構(gòu),返回值sds,即char *,該結(jié)構(gòu)定義如下:
            struct sdshdr
            {
                    int len;
                    int free;
                    char buf[];
            };
            其中l(wèi)en存儲當(dāng)前字符串的長度,free存儲該結(jié)構(gòu)體剩余可存儲字節(jié)數(shù),buf存儲字符串值。sdsnewlen()函數(shù)在創(chuàng)建sdshdr后,會返回buf的地址(sdshdr->buf)。
            sdsnewlen()函數(shù)創(chuàng)建了字符串,并返回字符串地址sds,要使用sdshdr中的len和free,則需要獲取sdshdr結(jié)構(gòu)體的地址。如何根據(jù)獲得的sds得到sdshdr結(jié)構(gòu)體的地址呢?
            redis中參考了linux內(nèi)核關(guān)于通用list(list_head)的實現(xiàn)機制,實現(xiàn)方法如下:
            struct sdshdr *sh =  (void*) (sds-(sizeof(struct sdshdr)));
            sds是返回的字符串地址,即sdshdr->buf,用sds的地址減去其在結(jié)構(gòu)體中的偏移,即可得到sdshdr的地址。由于buf在sdshdr結(jié)構(gòu)體的最后,所以其偏移就是sizeof(len)+sizeof(free),該偏移恰好是sizeof(struct sdshdr)。
            如果buf在sdshdr中的位置是任意的,如何根據(jù)buf的地址獲取sdshdr的地址呢?實現(xiàn)如下:
            假設(shè)現(xiàn)在sdshdr聲明如下:
            struct sdshdr
            {
                    int len;
                    char buf[];
                    int free;       
            };
            則sdshdr地址如下獲取:
            int offset_buf = (int)((struct sdshdr *)0)->buf;      
            struct sdshdr *sh =(struct sdshdr *)( (int)sdsbuf - offset_buf);  
            其中sdsbuf是調(diào)用sdsnewlen()返回的buf地址。即 sds sdsbuf = sdsnewlen(...);
            ((struct sdshdr *)0)->buf 表示當(dāng)結(jié)構(gòu)體sdshdr在地址0時,buf相對于sdshdr首地址的偏移。

            posted @ 2012-07-03 00:59 MrRightLeft 閱讀(1446) | 評論 (0)編輯 收藏

            2012年6月20日

            64位網(wǎng)絡(luò)字節(jié)序與主機字節(jié)序轉(zhuǎn)換

             64位網(wǎng)絡(luò)字節(jié)序與主機字節(jié)序轉(zhuǎn)換

            unsigned long long ntohll(unsigned long long val)
            {
                
            if (__BYTE_ORDER == __LITTLE_ENDIAN)
                
            {
                    
            return (((unsigned long long )htonl((int)((val << 32>> 32))) << 32| (unsigned int)htonl((int)(val >> 32));
                }

                
            else if (__BYTE_ORDER == __BIG_ENDIAN)
                
            {
                    
            return val;
                }

            }


            unsigned 
            long long htonll(unsigned long long val)
            {
                
            if (__BYTE_ORDER == __LITTLE_ENDIAN)
                
            {
                    
            return (((unsigned long long )htonl((int)((val << 32>> 32))) << 32| (unsigned int)htonl((int)(val >> 32));
                }

                
            else if (__BYTE_ORDER == __BIG_ENDIAN)
                
            {
                    
            return val;
                }

            }

             

            posted @ 2012-06-20 16:50 MrRightLeft 閱讀(6645) | 評論 (1)編輯 收藏

            2012年6月14日

            如何定義變長的TLV結(jié)構(gòu)體?

            如何定義變長的TLV結(jié)構(gòu)體?

            TLV是一種常用的用于通信的結(jié)構(gòu)體格式。T表示tag,L表示length,V表示value。其中T和L是固定大小的,V是可變大小,L表示的是V的長度。通常用于結(jié)構(gòu)化網(wǎng)絡(luò)通信中的數(shù)據(jù)流。如0x3 3 'aa\0',0x3 5 'aaaa\0',其中0x3表示tag的值,3 or 5表示的是后面的字符串的長度。由于V是可變長度的,所以在定義TLV結(jié)構(gòu)時,需要將V定義成為可變大小。可定義如下:
            struct TLV
            {
                uint8_t tag;
                uint16_t len;
                char value[0];
            }__attribute__((packed));

            注意value分配的是0大小,最后一個成員為可變長的數(shù)組,對于TLV(Type-Length-Value)形式的結(jié)構(gòu),或者其他需要變長度的結(jié)構(gòu)體,用這種方式定義最好。使用起來非常方便,創(chuàng)建時,malloc一段結(jié)構(gòu)體大小加上可變長數(shù)據(jù)長度的空間給它,可變長部分可按數(shù)組的方式訪問,釋放時,直接把整個結(jié)構(gòu)體free掉就可以了。__attribute__(packed)用來強制不對struct TLV進行4字節(jié)對齊,目的是為了獲取真實的TLV的空間使用情況。
            int main()
            {
                char *szMsg = "aaaaaaaaa";
                cout << sizeof(TLV) << endl; //the size of TLV
                uint16_t len = strlen(szMsg) + 1;
                struct TLV *pTLV;
                pTLV = (struct TLV*)malloc(sizeof(struct TLV) + sizeof(char)*len);
                pTLV->tag = 0x2;
                pTLV->len = len;
                memcpy(pTLV->value, szMsg, len);
                cout << pTLV->value << endl;
                free(pTLV);
                pTLV = NULL;
                return 0;
            }

            這里有關(guān)于設(shè)置變長TLV的詳細說明:http://www.douban.com/note/213324857/
            這里有一個問題,如何實現(xiàn)嵌套TLV結(jié)構(gòu)呢?大家有什么好的思路嗎?歡迎交流
            簡單實現(xiàn)了一下嵌套TLV,不知道有沒有問題。
            #include <iostream>
            using namespace std;

            struct TLVNODE
            {
                uint8_t tag;
                uint16_t len;
                char value[0];
            }__attribute__ ((packed));

            struct TLV
            {
                int hei;
                uint8_t tag;
                uint16_t len;
                struct TLVNODE value[0];
            } __attribute__ ((packed));

            int main()
            {
                //char *szMsg = "aaaaaaaaaaa";
                cout << sizeof(TLV) << endl;
                //uint16_t len = strlen(szMsg) + 1;

                char *szNodeMsg = "bbbbbbbbbb";
                uint16_t nodelen = strlen(szNodeMsg) + 1;
                struct TLVNODE *pNode = (struct TLVNODE *) malloc(sizeof(struct TLVNODE) + sizeof(char)*nodelen); 
                pNode->tag = 0x3;
                pNode->len = nodelen;
                memcpy(pNode->value, szNodeMsg, nodelen);


                struct TLV *pTlv;
                uint16_t nodeSize = sizeof(struct TLVNODE) + sizeof(char)*nodelen;
                pTlv = (struct TLV*)malloc(sizeof(struct TLV) + nodeSize);
                pTlv->tag = 0x2;
                pTlv->len = nodeSize;
            //    pTlv->value[0] = (struct TLVNODE)*pNode;
                memcpy(pTlv->value, pNode, nodeSize);
                free(pNode);
                pNode = NULL;
                cout << sizeof(*pTlv) << endl;
                /*for (int i = 0; i < len; ++i)
                {
                    pTlv->value[i] = szMsg[i]; 
                }
            */

                /*memcpy(pTlv->value, szMsg, len);*/
                //cout << pTlv->value << endl;
                free(pTlv);
                pTlv = NULL;
                return 0;
            }




            posted @ 2012-06-14 15:46 MrRightLeft 閱讀(6533) | 評論 (4)編輯 收藏

            僅列出標題  下一頁
            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導(dǎo)航

            統(tǒng)計

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲色欲久久久综合网| 伊人色综合久久天天人手人婷 | 99蜜桃臀久久久欧美精品网站| 伊人久久综在合线亚洲2019| 97久久精品午夜一区二区| 国产亚洲综合久久系列| 97久久超碰成人精品网站| 97久久国产亚洲精品超碰热| 久久久久久夜精品精品免费啦 | 欧洲精品久久久av无码电影 | 好久久免费视频高清| 久久国产精品国产自线拍免费| 久久久久免费看成人影片| 97久久超碰国产精品旧版| 国产精品久久久久一区二区三区| 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲 | 国产精品丝袜久久久久久不卡| WWW婷婷AV久久久影片| 久久亚洲欧美日本精品| 久久精品国产亚洲7777| 久久这里都是精品| 久久综合综合久久综合| 国产成人无码精品久久久免费| 久久99精品久久久久久不卡| 精品久久久一二三区| 久久丫精品国产亚洲av不卡| 久久亚洲国产精品一区二区| 武侠古典久久婷婷狼人伊人| 亚洲αv久久久噜噜噜噜噜| 99久久精品九九亚洲精品| 久久久久久国产a免费观看黄色大片 | 看久久久久久a级毛片| 久久美女人爽女人爽| 久久久国产精华液| 国产精品久久久久久久久鸭| 亚洲伊人久久成综合人影院| 97久久精品无码一区二区天美| 亚洲精品97久久中文字幕无码| 国产精品美女久久久久久2018| 精品多毛少妇人妻AV免费久久 | 亚洲欧美精品一区久久中文字幕|