• <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 冰果 閱讀(1862) 評論(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。說這樣後續如果增加需求的時候,就不用再砍了。這個項目過了半年了,也沒有再對它加什麼需求。反倒是有些額外功能被砍,使得後續的生產、測試稍顯不便。  回復  更多評論   

                                                        
            色狠狠久久综合网| 久久无码av三级| 久久久久久久91精品免费观看| 亚洲&#228;v永久无码精品天堂久久| 国内精品久久久久久久久| 中文字幕久久亚洲一区| 久久精品无码午夜福利理论片| 国产精品久久国产精麻豆99网站 | 亚洲国产成人久久精品99| 国产美女亚洲精品久久久综合 | 欧美久久久久久午夜精品| 国产A三级久久精品| 品成人欧美大片久久国产欧美...| 久久亚洲熟女cc98cm| 品成人欧美大片久久国产欧美...| 国产精品99久久久精品无码 | 久久综合九色综合精品| 久久精品国产亚洲αv忘忧草| 国产国产成人久久精品| 久久久一本精品99久久精品66| 看全色黄大色大片免费久久久 | 超级碰碰碰碰97久久久久| 亚洲国产精品久久66| 色婷婷综合久久久久中文一区二区 | 四虎影视久久久免费| 亚洲国产精品久久久久| 久久精品蜜芽亚洲国产AV| 色综合久久夜色精品国产| 欧美精品丝袜久久久中文字幕| 99久久精品国产一区二区蜜芽| 国产∨亚洲V天堂无码久久久| 久久乐国产综合亚洲精品| 欧美久久一级内射wwwwww.| 久久夜色撩人精品国产| 国产精品九九久久免费视频| 97精品国产97久久久久久免费 | 久久国产成人| 精品国产综合区久久久久久| 91精品婷婷国产综合久久 | 亚洲欧美日韩久久精品第一区| 天天影视色香欲综合久久|