談談你接觸的通訊程序的模型

duanjigang

epoll并沒有改變傳統(tǒng)的select或poll等處理方式。大多數(shù)模型還是一個通信控制線程，多個數(shù)據(jù)處理線 ...
CU第一菜 發(fā)表于 2011-01-27 08:57

    數(shù)據(jù)處理是獨立的，是不是用進程更好些？因為它們之間沒有什么需要協(xié)作的

CU第一菜

數(shù)據(jù)處理是獨立的，是不是用進程更好些？因為它們之間沒有什么需要協(xié)作的
duanjigang 發(fā)表于 2011-01-27 09:41

    進程和線程沒有太大的本質區(qū)別，linux下個人偏好還是進程好，因為線程的話，如果主線程掛掉，會導致子線程也崩潰，可能出現(xiàn)一些異常。
也不能說完全沒有協(xié)作，比如說通信請求到達，需要指派給某個具體的進程來處理，這就是相應的協(xié)作關系了。

duanjigang

比如說通信請求到達，需要指派給某個具體的進程來處理，這就是相應的協(xié)作關系了。

CU第一菜 發(fā)表于 2011-01-27 09:45

這個指的是父進程把接收到的連接套接字傳遞給子進程繼續(xù)通訊嗎？？
這樣的話開銷會不會很大？我意思通訊數(shù)據(jù)接收一個進程就夠了，數(shù)據(jù)處理讓多個進程來完成···

CU第一菜

這個指的是父進程把接收到的連接套接字傳遞給子進程繼續(xù)通訊嗎？？
這樣的話開銷會不會很大？我 ...
duanjigang 發(fā)表于 2011-01-27 10:06

    設計的原則我覺得可以參考nginx，主進程只負責通信控制，數(shù)據(jù)處理有子進程來完成。
如果如版主大牛說的父進程進行通訊，那如果多個某些通信要進行多次交互，第一次數(shù)據(jù)處理由子進程A完成，而后續(xù)的數(shù)據(jù)交互處理，是不是可能再由主進程分派給其他子進程來完成了？
apache里面似乎是一個子進程負責處理完一個完整的tcp連接通信（待核實），讓子進程體現(xiàn)會話處理的完整性，是不是也是一種較好的方式。

dreamice

這個指的是父進程把接收到的連接套接字傳遞給子進程繼續(xù)通訊嗎？？
這樣的話開銷會不會很大？我 ...
duanjigang 發(fā)表于 2011-01-27 10:06

  英雄：  通信的開銷應該通過其通信方式來判定吧，設計一個比較優(yōu)化的方式，可能效率還是很高的。

CU第一菜

如果數(shù)據(jù)的收發(fā)走兩條連接的話，我們完全可以把通訊只用一個進程來做，數(shù)據(jù)處理多個子進程來實現(xiàn) ...
duanjigang 發(fā)表于 2011-01-27 10:33

    如果數(shù)據(jù)發(fā)送是以接收到的數(shù)據(jù)為判斷前提的，那還是存在數(shù)據(jù)接收和發(fā)送之間的通信同步了。個人感覺，以tcp連接會話為單位來做為進程處理更合理一些。

執(zhí)一

apache中用計分板的方式實現(xiàn)父進程和子進程之間的通信，記分板有點類似于共享內存。主進程和子進程之間又是通過管道來作為控制的，比如說主進程要結束子進程，子進程要向父進程報告錯誤等。

dreamice

apache中用計分板的方式實現(xiàn)父進程和子進程之間的通信，記分板有點類似于共享內存。主進程和子進程之間又是 ...
執(zhí)一 發(fā)表于 2011-01-27 13:47

    apache的多進程處理圖

duanjigang

多謝江總分享，還沒看apache的代碼，看這個圖暫時沒啥深切體會，只是覺得跟我目前做的模型很像:wink:

dreamice

多謝江總分享，還沒看apache的代碼，看這個圖暫時沒啥深切體會，只是覺得跟我目前做的模型很像
duanjigang 發(fā)表于 2011-01-27 15:05

    跟你的機制可能差異還是很大。

apache的主進程只負責控制，在初始化時創(chuàng)建一堆子進程，子進程通過記分牌和管道與主進程通信。
主進程除了控制子進程外，不做通信處理。子進程通過競爭獲得監(jiān)聽權，然后進行一系列的處理，因此apache的進程是負責一系列的連接處理的。這樣避免了進程間通信，效率還是很可觀的。