亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

  免費注冊 查看新帖 |

Chinaunix

  平臺 論壇 博客 文庫
123下一頁
最近訪問板塊 發(fā)新帖
查看: 5232 | 回復(fù): 20
打印 上一主題 下一主題

[C] 請教一個服務(wù)器程序協(xié)議設(shè)計的問題 [復(fù)制鏈接]

論壇徽章:
1
2015年辭舊歲徽章
日期:2015-03-03 16:54:15
跳轉(zhuǎn)到指定樓層
1 [收藏(0)] [報告]
發(fā)表于 2013-09-27 09:47 |只看該作者 |倒序瀏覽
本帖最后由 csumck 于 2013-09-27 09:49 編輯

假設(shè)網(wǎng)絡(luò)中存在機器A、B、C、D四臺服務(wù)器, 它們各自只能連接最近的服務(wù)器,也就是說A只能連B,B能連A、C,C能連B、D,D只能連C。  每臺服務(wù)器上也同時還有來自其他服務(wù)器的連接。
我的程序是通過TCP通信的,現(xiàn)在A想發(fā)一個數(shù)據(jù)請求,該數(shù)據(jù)需要依次在B、C、D四臺機器上查找才能組織完全,也就是說請求包的路由順序是 A->B->C->D,由于上面網(wǎng)絡(luò)拓?fù)涞脑,響?yīng)回包的路由必須是D->C->B->A。
問題是: C收到D的回包后,如何知道這個回包是要回給B的,B收到C的回包后如何知道包是要回給A的?

我現(xiàn)在用了個比較笨的解決辦法:
      協(xié)議包頭里有個請求流水號seq。B收到A的請求后,把請包頭里的seq的值換成seqb(短期內(nèi)不會重復(fù))再發(fā)送給C,同時記錄seqb是“來自A服務(wù)器的,原seq值是seqa”。 C收到B的請求包后,也是同樣做法,包頭里的seqb換成seqc再發(fā)給D,同時記錄seqc是“來自C服務(wù)器,原seq值是seqb”。依此類推。
      這個方法能解決問題,但是有幾個缺點:
      1. 這種記錄的數(shù)據(jù)是要消耗內(nèi)存的,包量越大消耗也越大(當(dāng)然內(nèi)存對現(xiàn)在服務(wù)器來講不是大問題,但能減少消耗肯定最好了)
      2. 另外就是要判斷超時,有些沒有被及時回包的請求記錄要刪除,增加了服務(wù)器計算負(fù)擔(dān)
      3. 服務(wù)一旦遭遇故障重啟后,這些記錄就會消失,收到回包后就找不到請求來自哪臺機器了(通過共享內(nèi)存等持久化的辦法也可以解決,但是也會增加編碼和維護的工作量)

希望大家能給指導(dǎo)一下,給些啟發(fā)! 是不是協(xié)議還有其他的設(shè)計思路? 或者我這個笨辦法有沒有改進的空間?

ps. 為啥會有這種蛋疼的網(wǎng)絡(luò)結(jié)構(gòu)呢? 主要是各公司間安全通信的需要,各個機房只對某臺機器開放網(wǎng)絡(luò)連接的權(quán)限,這臺機器就像一個網(wǎng)關(guān)一樣處理所有進出這個機房的數(shù)據(jù)(主要是鑒定合法性、然后分流)。。。

論壇徽章:
6
酉雞
日期:2013-11-04 15:30:02巳蛇
日期:2014-01-23 10:36:23雙魚座
日期:2014-01-23 13:08:332015亞冠之鹿島鹿角
日期:2015-09-03 14:36:002015亞冠之武里南聯(lián)
日期:2015-09-18 10:48:1315-16賽季CBA聯(lián)賽之山西
日期:2016-05-05 00:05:33
2 [報告]
發(fā)表于 2013-09-27 09:57 |只看該作者
ID|類型(方向)|服務(wù)器標(biāo)識|長度|數(shù)據(jù)|

論壇徽章:
1
2015年辭舊歲徽章
日期:2015-03-03 16:54:15
3 [報告]
發(fā)表于 2013-09-27 10:00 |只看該作者
回復(fù) 2# Dannysd


    多謝, 不過我還是沒明白。。方向和服務(wù)器類型具體是什么值呢? 能不能結(jié)合我那個例子說一下?

論壇徽章:
17
處女座
日期:2013-08-27 09:59:352015亞冠之柏太陽神
日期:2015-07-30 10:16:402015亞冠之薩濟拖拉機
日期:2015-07-29 18:58:182015年亞洲杯之巴勒斯坦
日期:2015-03-06 17:38:17摩羯座
日期:2014-12-11 21:31:34戌狗
日期:2014-07-20 20:57:32子鼠
日期:2014-05-15 16:25:21亥豬
日期:2014-02-11 17:32:05丑牛
日期:2014-01-20 15:45:51丑牛
日期:2013-10-22 11:12:56雙子座
日期:2013-10-18 16:28:17白羊座
日期:2013-10-18 10:50:45
4 [報告]
發(fā)表于 2013-09-27 10:03 |只看該作者
回復(fù) 1# csumck


    在應(yīng)用層實現(xiàn)一個簡單的路由協(xié)議,由這個路由協(xié)議決定處理節(jié)點失效和重定向等問題,通過路由協(xié)議確定目標(biāo)主機。你可以參考一下消息隊列(MQ)的消息路由。有很多開源實現(xiàn)。

論壇徽章:
36
子鼠
日期:2013-08-28 22:23:29黃金圣斗士
日期:2015-12-01 11:37:51程序設(shè)計版塊每日發(fā)帖之星
日期:2015-12-14 06:20:00CU十四周年紀(jì)念徽章
日期:2015-12-22 16:50:40IT運維版塊每日發(fā)帖之星
日期:2016-01-25 06:20:0015-16賽季CBA聯(lián)賽之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16賽季CBA聯(lián)賽之福建
日期:2016-04-07 11:25:2215-16賽季CBA聯(lián)賽之青島
日期:2016-04-29 18:02:5915-16賽季CBA聯(lián)賽之北控
日期:2016-06-20 17:38:50技術(shù)圖書徽章
日期:2016-07-19 13:54:03程序設(shè)計版塊每日發(fā)帖之星
日期:2016-08-21 06:20:00
5 [報告]
發(fā)表于 2013-09-27 10:19 |只看該作者
本帖最后由 cokeboL 于 2013-09-27 10:35 編輯

1. 這種記錄的數(shù)據(jù)是要消耗內(nèi)存的,包量越大消耗也越大(當(dāng)然內(nèi)存對現(xiàn)在服務(wù)器來講不是大問題,但能減少消耗肯定最好了)

每臺機器應(yīng)該有自己能轉(zhuǎn)發(fā)的列表,以及上游下游的區(qū)分比如

a的
transmit_map =
{
        //key  value           attr
        'b',     ip + port,    pre/behind
}

b的
transmit_map =
{
        //key  value           attr
        'a',   ip + port,    pre/behind
        'c',   ip + port,    pre/behind
}
依此推

a發(fā)一個請求的時候,請求包里包含一個請求序列棧
包頭里包含一個請求序列棧長,request_stack_len

接收請求時,如果本機不是最后該請求所需到達(dá)的最后一臺機器,就把本機id入棧,
把request_stack_len ++,并且轉(zhuǎn)發(fā)給下一臺機器
如果是最后一個機器,比如d,作為終結(jié)者,根據(jù)請求序列棧,把所查詢的數(shù)據(jù)返回給上家

也就是請求的時候只發(fā)請求命令和請求序列,從最后一臺機器開始返回數(shù)據(jù),前面每臺把自己的
數(shù)據(jù)加到其中,比如

a發(fā)請求給b:
[
  ... ,
  request_stack_len = 1,
  'a'
]

b收到繼續(xù)轉(zhuǎn)發(fā)給c
[
  ... ,
  request_stack_len = 2,
  'a',
  'b'
]

c收到繼續(xù)轉(zhuǎn)發(fā)給d
[
  ... ,
  request_stack_len = 3,
  'a',
  'b',
  'c'
]

d收到后因為自己是最后一臺,就取出序列棧尾c,并返回數(shù)據(jù)給c
[
  ... ,
  return_stack_len = 2,
  'a',
  'b',
  data_len = n,
  [data]
]

c收到后把自己的數(shù)據(jù)加到里面返回給b
[
  ... ,
  return_stack_len = 1,
  'a',
  data_len = n,
  [data] //數(shù)據(jù)加到里面
]

論壇徽章:
6
酉雞
日期:2013-11-04 15:30:02巳蛇
日期:2014-01-23 10:36:23雙魚座
日期:2014-01-23 13:08:332015亞冠之鹿島鹿角
日期:2015-09-03 14:36:002015亞冠之武里南聯(lián)
日期:2015-09-18 10:48:1315-16賽季CBA聯(lián)賽之山西
日期:2016-05-05 00:05:33
6 [報告]
發(fā)表于 2013-09-27 10:28 |只看該作者
回復(fù) 3# csumck


    方向是代表由A發(fā)起的還是由D返回的,根據(jù)這個就知道應(yīng)該傳給上一個服務(wù)器還是下一個服務(wù)器

    服務(wù)器標(biāo)識是B的話,根據(jù)方向就能判斷是該傳給C還是傳給A

    我覺得這個結(jié)構(gòu)在最前面還應(yīng)該加上一個表示整個結(jié)構(gòu)數(shù)據(jù)的長度字段,這樣方便你TCP接收時候處理

論壇徽章:
36
子鼠
日期:2013-08-28 22:23:29黃金圣斗士
日期:2015-12-01 11:37:51程序設(shè)計版塊每日發(fā)帖之星
日期:2015-12-14 06:20:00CU十四周年紀(jì)念徽章
日期:2015-12-22 16:50:40IT運維版塊每日發(fā)帖之星
日期:2016-01-25 06:20:0015-16賽季CBA聯(lián)賽之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16賽季CBA聯(lián)賽之福建
日期:2016-04-07 11:25:2215-16賽季CBA聯(lián)賽之青島
日期:2016-04-29 18:02:5915-16賽季CBA聯(lián)賽之北控
日期:2016-06-20 17:38:50技術(shù)圖書徽章
日期:2016-07-19 13:54:03程序設(shè)計版塊每日發(fā)帖之星
日期:2016-08-21 06:20:00
7 [報告]
發(fā)表于 2013-09-27 10:28 |只看該作者
2. 另外就是要判斷超時,有些沒有被及時回包的請求記錄要刪除,增加了服務(wù)器計算負(fù)擔(dān)

中轉(zhuǎn)的機器不需要記錄請求,始發(fā)的地方發(fā)請求的時候記錄個請求標(biāo)示和時間,做一個總的超時等待,超了就刪掉,就可以了吧,沒什么麻煩的

論壇徽章:
36
子鼠
日期:2013-08-28 22:23:29黃金圣斗士
日期:2015-12-01 11:37:51程序設(shè)計版塊每日發(fā)帖之星
日期:2015-12-14 06:20:00CU十四周年紀(jì)念徽章
日期:2015-12-22 16:50:40IT運維版塊每日發(fā)帖之星
日期:2016-01-25 06:20:0015-16賽季CBA聯(lián)賽之深圳
日期:2016-01-27 10:31:172016猴年福章徽章
日期:2016-02-18 15:30:3415-16賽季CBA聯(lián)賽之福建
日期:2016-04-07 11:25:2215-16賽季CBA聯(lián)賽之青島
日期:2016-04-29 18:02:5915-16賽季CBA聯(lián)賽之北控
日期:2016-06-20 17:38:50技術(shù)圖書徽章
日期:2016-07-19 13:54:03程序設(shè)計版塊每日發(fā)帖之星
日期:2016-08-21 06:20:00
8 [報告]
發(fā)表于 2013-09-27 10:34 |只看該作者
3. 服務(wù)一旦遭遇故障重啟后,這些記錄就會消失,收到回包后就找不到請求來自哪臺機器了(通過共享內(nèi)存等持久化的辦法也可以解決,但是也會增加編碼和維護的工作量)

見上面的帖子,發(fā)請求和回包的時候都包含了請求和回發(fā)的序列棧,不會不知道來自哪臺機器。防止服務(wù)器宕機應(yīng)該在發(fā)包回包之間有確認(rèn)機制,可能還是要做個超時重發(fā),比如 b轉(zhuǎn)請求給c,
計時3s,c收到轉(zhuǎn)發(fā)給d后確認(rèn)給b,如果3s過了b沒收到確認(rèn)重發(fā)請求給c。c轉(zhuǎn)發(fā)給d的時候d就可以以回包作為確認(rèn)。并且c回數(shù)據(jù)給b的時候給d一個確認(rèn),d超時沒收到c成功轉(zhuǎn)給b的確認(rèn),
就重發(fā)數(shù)據(jù)給c。直到a收到所有數(shù)據(jù),過程over

論壇徽章:
15
射手座
日期:2014-11-29 19:22:4915-16賽季CBA聯(lián)賽之青島
日期:2017-11-17 13:20:09黑曼巴
日期:2017-07-13 19:13:4715-16賽季CBA聯(lián)賽之四川
日期:2017-02-07 21:08:572015年亞冠紀(jì)念徽章
日期:2015-11-06 12:31:58每日論壇發(fā)貼之星
日期:2015-08-04 06:20:00程序設(shè)計版塊每日發(fā)帖之星
日期:2015-08-04 06:20:00程序設(shè)計版塊每日發(fā)帖之星
日期:2015-07-12 22:20:002015亞冠之浦和紅鉆
日期:2015-07-08 10:10:132015亞冠之大阪鋼巴
日期:2015-06-29 11:21:122015亞冠之廣州恒大
日期:2015-05-22 21:55:412015年亞洲杯之伊朗
日期:2015-04-10 16:28:25
9 [報告]
發(fā)表于 2013-09-27 10:34 |只看該作者
本帖最后由 yulihua49 于 2013-09-27 11:06 編輯

這是交易中間件的活。
我們的交易中間件可以做到這個。

實現(xiàn)方法可以說一下,沒那么復(fù)雜。
首先,作為交易中間件,他有統(tǒng)一的數(shù)據(jù)包規(guī)范,客戶端,服務(wù)器,呼叫,返回都是相同的包格式,這是數(shù)據(jù)包可以被中繼的必要條件。
其次,每一個交易節(jié)點(它可以是客戶端、服務(wù)器、客戶端+服務(wù)器。。。。),內(nèi)部對每個到達(dá)的交易都有一個context,
這個context里含有接入socket和若干接出socket。
當(dāng)它需要級聯(lián)接出時,就會從連接池獲取一個適當(dāng)?shù)膕ocket放在接出socket里(通過交易路由功能),并對它發(fā)送數(shù)據(jù)。
事件管理器會監(jiān)聽這個socket的返回,監(jiān)聽到了,把這個context提交給它的回調(diào)函數(shù)(也在context里),
在這個回調(diào)函數(shù)里處理其余的業(yè)務(wù),其中,它既可以再次調(diào)用接出socket,也可以返回接入socket。不會搞錯的。
在任何一個客戶端連接服務(wù)器時,服務(wù)器都會給他分配一個context,并對其訪問權(quán)進行認(rèn)證?蛻舳诵璩鍪旧矸葑C、指紋等信息。
最后,這個context就是聯(lián)系雙方的‘ID’。直到一方logout。
其間,設(shè)置事件處理器(如epoll),一直使用這個context。

完了。


論壇徽章:
1
2015年辭舊歲徽章
日期:2015-03-03 16:54:15
10 [報告]
發(fā)表于 2013-09-27 10:49 |只看該作者
回復(fù) 5# cokeboL


    好辦法,多謝你這么詳細(xì)的講解,太感謝了!
    再請教個具體點的問題,你說的這個辦法里,每個服務(wù)的id是如何確定的?
您需要登錄后才可以回帖 登錄 | 注冊

本版積分規(guī)則 發(fā)表回復(fù)

  

北京盛拓優(yōu)訊信息技術(shù)有限公司. 版權(quán)所有 京ICP備16024965號-6 北京市公安局海淀分局網(wǎng)監(jiān)中心備案編號:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年舉報專區(qū)
中國互聯(lián)網(wǎng)協(xié)會會員  聯(lián)系我們:huangweiwei@itpub.net
感謝所有關(guān)心和支持過ChinaUnix的朋友們 轉(zhuǎn)載本站內(nèi)容請注明原作者名及出處

清除 Cookies - ChinaUnix - Archiver - WAP - TOP