網(wǎng)絡(luò)傳輸過程結(jié)構(gòu)體序列化的問題

okmmno1

網(wǎng)絡(luò)傳輸過程結(jié)構(gòu)體序列化的問題

在網(wǎng)絡(luò)傳輸過程中，需要將函數(shù)的參數(shù)序列化,
也就是將函數(shù)的參數(shù)一次copy到一個(gè)固定的內(nèi)存塊中發(fā)送出去
例如:

int rtStart(int handle, int path, char sth)；

對(duì)于此函數(shù)無非是：

memcpy(buffer, &handle, sizeof(int)); memcpy(buffer + sizeof(int), &path, sizeof(int)); memcpy(buffer + 2*sizeof(int), &sth, sizeof(char));

目前遇到的問題是：
函數(shù)類型如下：

int rtStart(int handle, int path, A* sth)； typedef struct {      int a;      int b;       B* c; }A;

然后

typedef struct {      int a;      int b;       C* c; }B;

...
...
這樣的嵌套有好多層，
而且類似的函數(shù)有一百多個(gè)，如果單純的依靠手工
一個(gè)一個(gè)內(nèi)存拷貝的話顯然太stupid了，
有沒有一種可以通用的序列化功能，
類似于

int rtStart(int handle, int path, A* sth) {     ser(1);//1是函數(shù)類型號(hào)，預(yù)定義      ... }

ser函數(shù)和調(diào)用者函數(shù)無關(guān)，然后就將rtStart參數(shù)序列化？
不考慮用xml傳輸，因?yàn)榫W(wǎng)絡(luò)傳輸太頻繁，xml效率無法滿足要求
或者ACE里面有沒有類似的功能？

zhujiang73

原帖由 okmmno1 于 2007-11-20 09:28 發(fā)表
網(wǎng)絡(luò)傳輸過程結(jié)構(gòu)體序列化的問題

在網(wǎng)絡(luò)傳輸過程中，需要將函數(shù)的參數(shù)序列化,
也就是將函數(shù)的參數(shù)一次copy到一個(gè)固定的內(nèi)存塊中發(fā)送出去
例如:
int rtStart(int handle, int path, char sth)；
對(duì)于此函 ...

看來像是做“遠(yuǎn)程調(diào)用”，跟我現(xiàn)在做的差不多。   在遠(yuǎn)程調(diào)用程序中，我是盡量避免使用含有指針的結(jié)構(gòu)體，如果要用只能自己編程做打包處理。 目前 C/C++ 不支持自動(dòng)序列化，我想這是因?yàn)榫幾g后的執(zhí)行文件沒有保留完整的類型信息，不過以后的 C++ 可能會(huì)加上完整的 RTTI 和自動(dòng)序列化。

okmmno1

原帖由 zhujiang73 于 2007-11-20 10:24 發(fā)表


看來像是做“遠(yuǎn)程調(diào)用”，跟我現(xiàn)在做的差不多。   在遠(yuǎn)程調(diào)用程序中，我是盡量避免使用含有指針的結(jié)構(gòu)體，如果要用只能自己編程做打包處理。 目前 C/C++ 不支持自動(dòng)序列化，我想這是因?yàn)榫幾g后的執(zhí)行文件 ...

恩，差不多就是遠(yuǎn)程調(diào)用的概念，但是目前想做的就是，實(shí)現(xiàn)一個(gè)自動(dòng)化的概念，有程序自己控制序列化的功能，而不是手工的每次去copy

zhujiang73

原帖由 okmmno1 于 2007-11-20 10:32 發(fā)表

恩，差不多就是遠(yuǎn)程調(diào)用的概念，但是目前想做的就是，實(shí)現(xiàn)一個(gè)自動(dòng)化的概念，有程序自己控制序列化的功能，而不是手工的每次去copy

需要把函數(shù)參數(shù)打包，再發(fā)送到遠(yuǎn)端是嗎？  對(duì)于簡單類型，和不含有指針的結(jié)構(gòu)體數(shù)據(jù)，通用指針可以幫你大大簡化這一過程，不過遇到含有指針的結(jié)構(gòu)體，必須自己先打包才能處理�？梢詤⒖家幌挛业拇笞鳎�    http://blog.chinaunix.net/u/21585/showart_290864.html

今天 “C++ 簡單遠(yuǎn)程調(diào)用” 第三版完成了，現(xiàn)在我叫他 “gcpprc” ，這次主要改進(jìn)了遠(yuǎn)程調(diào)用過程中參數(shù)的打包和解包過程。這次我把 gcpprc 和演示程序的源碼分成兩組源文件，這樣 gcpprc 就可以單獨(dú)編譯成一個(gè)共享庫。我決定 gcpprc 在 lgpl2 協(xié)議下發(fā)行，對(duì) lgpl 通常的理解是，如果您寫的軟件始終以動(dòng)態(tài)連接的形式連接到這個(gè)函數(shù)庫，您可以不公開源碼，靜態(tài)連接和對(duì)庫本身的修改需要公開源碼。這樣您就可以用 gcpprc 開發(fā)商業(yè)程序了，我個(gè)人認(rèn)為 gcpprc 可以把一部分網(wǎng)絡(luò)程序的編程難度降低一半以上，如果您需要對(duì) gcpprc 的技術(shù)支持和定制開發(fā)，我就要考慮收費(fèi)了。  這次發(fā)布的 gcpprc 的演示程序 gcpprccli/gcpprcser 在 gpl2 協(xié)議下發(fā)行，關(guān)于對(duì) gpl/lgpl 的權(quán)威解釋請(qǐng)看 http://www.gnu.org/licenses/ 。 附件中是 gcpprc 程序源碼，真正的本人原創(chuàng)。

musics

你還是在每個(gè)結(jié)構(gòu)體定義的時(shí)候同時(shí)定義該結(jié)構(gòu)的序列化函數(shù)吧.統(tǒng)一接口.
在純C中,比如,在結(jié)構(gòu)中加個(gè)函數(shù)指針,C++中使用一個(gè)統(tǒng)一的基類或虛函數(shù),在每個(gè)需要遠(yuǎn)程傳輸類中都實(shí)現(xiàn)該功能.

okmmno1

有沒有一種類似corba的實(shí)現(xiàn)方式呢？

yuanchengjun

原帖由 okmmno1 于 2007-11-20 09:28 發(fā)表
網(wǎng)絡(luò)傳輸過程結(jié)構(gòu)體序列化的問題

在網(wǎng)絡(luò)傳輸過程中，需要將函數(shù)的參數(shù)序列化,
也就是將函數(shù)的參數(shù)一次copy到一個(gè)固定的內(nèi)存塊中發(fā)送出去
例如:
int rtStart(int handle, int path, char sth)；
對(duì)于此函 ...

這種做法是有問題的。

okmmno1

樓上兄弟，能具體指教一下么？
現(xiàn)在的想法是，在客戶端可服務(wù)器兩個(gè)各準(zhǔn)備一個(gè)文件，里面對(duì)各個(gè)結(jié)構(gòu)體進(jìn)行描述，然后再程序運(yùn)行時(shí)，
程序按照文件中的內(nèi)容對(duì)傳進(jìn)的結(jié)構(gòu)體進(jìn)行內(nèi)存序列化。

galaxywar

原帖由 okmmno1 于 2007-11-26 15:04 發(fā)表
樓上兄弟，能具體指教一下么？
現(xiàn)在的想法是，在客戶端可服務(wù)器兩個(gè)各準(zhǔn)備一個(gè)文件，里面對(duì)各個(gè)結(jié)構(gòu)體進(jìn)行描述，然后再程序運(yùn)行時(shí)，
程序按照文件中的內(nèi)容對(duì)傳進(jìn)的結(jié)構(gòu)體進(jìn)行內(nèi)存序列化。

你的方法是可行的，可以處理那些內(nèi)容比較簡單，特別是字段之間沒有依賴的情況。
我見過的別的做法都比較相似，每個(gè)結(jié)構(gòu)體都寫一個(gè)serialize函數(shù)，有嵌套指針的時(shí)候就直接調(diào)那個(gè)結(jié)構(gòu)體的serialize函數(shù)。跟重載<<，>>思想一樣。當(dāng)然這是C++的做法。如果C的話也差不多，因類所用到的結(jié)構(gòu)體類型在編碼時(shí)期就是確定的。

zhujiang73

原帖由 galaxywar 于 2007-11-26 15:16 發(fā)表

你的方法是可行的，可以處理那些內(nèi)容比較簡單，特別是字段之間沒有依賴的情況。
我見過的別的做法都比較相似，每個(gè)結(jié)構(gòu)體都寫一個(gè)serialize函數(shù)，有嵌套指針的時(shí)候就直接調(diào)那個(gè)結(jié)構(gòu)體的serialize函數(shù)。跟重載 ...

理論上編譯器應(yīng)該可以自動(dòng)生成這個(gè)serialize函數(shù)，好像開發(fā)下一代 C++  編譯器的大師們正在討論相關(guān)問題。