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

            冰果

            技術群:26678700     
            交流QQ: 704839634
            合作: 1) 可兼職遠程辦公開發; 2) 有一套Go+Python開發的行業短信云平臺可合作;3)目前正在開發物聯網、大數據平臺。

            socket通訊是使用第三方庫還是手工封裝操作系統api

                  socket通訊是使用第三方庫還是手工封裝操作系統api?
                  我相信做過幾年的服務器程序開發,你不止一次和網絡通訊、數據庫、文件系統打交道。閉上眼睛,靜靜回憶一下你開發的那些C++服務器系統,是不是大多數都涉及四個部分:
                  業務邏輯模塊、網絡通訊模塊、數據庫訪問模塊、文件訪問模塊。
                  單談網絡通訊模塊,我們可能既手工封裝操作系統api,又使用第三方庫。
                  在unix/linux系統上,直接調用socket()系列。
                  在windows上,直接調用winsock2提供的API。
                  使用MFC開發的,可能直接使用MFC提供的那個框架。
                  使用了boost庫的,可能喜歡使用那個異步io庫。
                  還有著名的ACE庫,以及類似的跨平臺庫。
                  ......
                  使用什么來實現都沒錯,主要是我們最好把握好一個度:
                  你的項目你的系統是什么規模,最好就采用什么規模的實現方式。
                  技術人員總有一種傾向,新學了一種知識,總是想使用一下,不管它合適不合適,有沒有害處。
                  我曾經看到一段簡單的代碼,就是一個線程實現,沒有什么數據同步、數據通訊等等,可這個線程是用ACE庫里的線程類來實現的,整個程序就四五個小小行數的cpp文件,為了一個線程,就引進一個大大ACE,而ACE僅僅在我那臺linux開發機上編譯出一個庫就花大半個上午,發布的時候還要帶上個so庫文件,這么簡單的功能直接使用pthread庫,linux常常都自帶了,完全沒有必要引入這么大的庫。
                  設計原則上講,形式追隨功能。
                  我們用什么形式去實現功能,是功能決定的,至于你能否把握這個原則,那要看你知識的廣度、開發經驗等。
                  雙節棍在李小龍手里很厲害,你也像他那樣快速舞動一下,我看馬上就頭上腫起來了。也不是說我們就不能練雙節棍了,你立志成為武術好手, 雙節棍高手,那你要下很多功夫,當然就功到自然成了。
                  可以說,作為個人最好在技術上廣而精,逐步擴大自己知識面;商業項目開發時,則最好形式追隨功能,也要看參與者現有的知識結構。
                  
                  我的理解有限,大家多回復一下自己的看法,回復一下曾經開發通訊模塊時都采用什么。

            posted on 2012-03-11 12:40 冰果 閱讀(1868) 評論(2)  編輯 收藏 引用

            評論

            # re: socket通訊是使用第三方庫還是手工封裝操作系統api 2012-03-13 17:29 vvilp

            同意, 做幾個小web 完全沒必要用到ssh 可以自己搭個小框架,但是現在 ssh 滿天飛,能用上ssh的大規模web卻不太多.....  回復  更多評論   

            # re: socket通訊是使用第三方庫還是手工封裝操作系統api 2012-03-15 09:27 Serval

            可能作者的考慮是爲了後期的擴展和維護吧,加入功能陸續加入的時候,某些庫就會體現出它的便利來。但是,個人有一點疑問:是否需要爲了後續不確定的需求而增加現在開發的複雜度。我個人的想法是,最好能夠搭建出一個好的數學模型,將時間,和後續增加需求的可能性都作為輸入,計算出一個值,根據這個值來決定採取那樣的設計。
            比如,我們一次做東西,需要限制在300KB,於是有工程師便砍掉了能看的所有功能,約270KB。說這樣後續如果增加需求的時候,就不用再砍了。這個項目過了半年了,也沒有再對它加什麼需求。反倒是有些額外功能被砍,使得後續的生產、測試稍顯不便。  回復  更多評論   

                                                        
            四虎久久影院| 无码精品久久久久久人妻中字 | 理论片午午伦夜理片久久| 久久本道久久综合伊人| 久久国产欧美日韩精品免费| 午夜精品久久久久久99热| Xx性欧美肥妇精品久久久久久| 久久免费99精品国产自在现线| 久久水蜜桃亚洲av无码精品麻豆| 狠狠精品久久久无码中文字幕 | 精品国产一区二区三区久久| 狠狠色综合久久久久尤物| 一本久久知道综合久久| 精品国产91久久久久久久a| 亚洲精品乱码久久久久久中文字幕 | 久久精品国产亚洲av水果派| 精品无码久久久久久久久久| 久久99精品国产麻豆宅宅| 久久久久香蕉视频| 国产精品一区二区久久精品无码 | 国产精品女同一区二区久久| 亚洲国产精品无码久久| 亚洲精品tv久久久久| 国产成人精品久久| 日韩精品国产自在久久现线拍| 中文精品久久久久人妻不卡| 亚洲国产高清精品线久久| 国产亚州精品女人久久久久久 | 中文字幕人妻色偷偷久久| 香蕉aa三级久久毛片| 精品久久人人爽天天玩人人妻| 99久久人妻无码精品系列| 漂亮人妻被黑人久久精品| 综合人妻久久一区二区精品| 久久人与动人物a级毛片| 97视频久久久| 77777亚洲午夜久久多喷| 亚洲国产另类久久久精品小说 | 精品熟女少妇AV免费久久| 久久这里只有精品首页| 中文国产成人精品久久亚洲精品AⅤ无码精品|