具有动态内存的命名管道策略？
Hokay，所以我有一个应用程序，我需要一些 IPC...我认为命名管道是可行的方法，因为它们非常易于使用。
无论如何，我有一个关于如何使用命名管道处理动态内存的问题。
假设我有一个这样的类：
class MyTestClass {
public:
MyTestClass() { _data = new int(4); }
int GetData() { return *_data; }
int GetData2() { return _data2; }
private:
int* _data;
int _data2;
};
现在，当我创建一个充满 MyTestClass 对象的缓冲区然后通过管道发送它们时，我显然在目标进程中丢失了 _data 并得到了垃圾。我应该使用一些策略吗？对于简单的情况，我可以使用值类型，但对于许多复杂的类，我需要使用某种动态内存，而且我喜欢指针。
或者，我应该考虑使用共享内存吗？谢谢
Hokay so I have an application where I need some IPC... I'm thinking named pipes are the way to go because they are so easy to use.
Anyways, I have a question about how to handle dynamic memory using named pipes.
Say I have a class such as this:
class MyTestClass {
public:
MyTestClass() { _data = new int(4); }
int GetData() { return *_data; }
int GetData2() { return _data2; }
private:
int* _data;
int _data2;
};
Now when I create a buffer full of MyTestClass objects then send them over the pipe, I'm obviously losing _data in the destination process and getting garbage. Is there some strategy to this that I should use? I can use value types for simple cases, but for many complex classes I need to use some sort of dynamic memory and I like pointers.
Or, should I just look at using shared memory instead? Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
命名管道和共享内存都有类似的问题：您需要将结构的内容序列化到发送端，并从接收端反序列化结构。
无论您使用命名管道还是共享内存，序列化过程本质上都是相同的。对于嵌入式指针（如 _data 和 _data2），您需要以一致的方式序列化指针的内容。
您可以使用多种序列化策略，具体取决于结构在内存中的布局方式以及 IPC 的效率。或者您可以使用 DCE RPC 并让 RPC 封送代码为您处理复杂性。
Both named pipes and shared memory have similar issues: You need to serialize the contents of the structure into the on the sending side and deserialize the structure from the on the receiving side.
The serialization process is essentially identical whether you're using named pipes or shared memory. For embedded pointers (like _data and _data2) you need to serialize the contents of the pointer in a consistent fashion.
There are lots of serialization strategies that you could use, depending on how your structures are laid out in memory and how efficient your IPC has to be. Or you could use DCE RPC and let the RPC marshaling code handle the complexities for you.
要通过命名管道发送数据，必须在发送端序列化（或编组）数据，并在接收端反序列化（或解编组）数据。
听起来很可疑，好像您只是在数据结构中写入字节的副本。这根本就没有什么好处。您没有复制分配的数据（它不是存储在数据结构的第一个和最后一个字节之间，而是存储在其他地方）并且您正在从一台机器复制指针（
_data）（或进程）到另一个进程，并且本地进程中的内存地址在另一个进程中没有保证意义。为自己定义一个有线协议（如果需要，请查看 ASN.1 - 不，再考虑一下，不要那么绝望），该协议定义了通过线路传输的数据的布局。然后实现发送器和接收器（或串行器和解串器）功能。或者找到其他人已经执行此操作的代码。
还要记住处理字节序 - 您必须定义通过命名管道发送字节的顺序。
例如，您可以定义发送的消息由一个网络字节顺序的 4 字节无符号整数组成，定义后面有多少个结构，每个结构可以是数组的 4 个带符号 4 字节整数的序列，后跟一个带符号的整数。
_data2的 4 字节整数（也按网络字节顺序发送）。请注意，选择命名管道作为 IPC 机制在很大程度上是无关紧要的；除非您使用共享内存（本质上在同一台机器上），否则必须处理字节序，即使使用共享内存，您也需要处理序列化。
To send the data over a named pipe, you must serialize (or marshal) the data on the sending end, and deserialize (or unmarshal) it on the receiving end.
It sounds suspiciously as if you are simply writing a copy of the bytes in the data structure. This is no good whatsoever. You aren't copying the allocated data (it isn't stored between the first and last bytes of the data structure, but somewhere else altogether) and you are copying a pointer (
_data) from one machine (or process) to another, and the memory address in the local process has no guaranteed meaning in the other.Define yourself a wire protocol (if desparate, look at ASN.1 - no, on second thoughts, don't get that desparate) that defines the layout of the data for transmission over the wire. Then implement sender and receiver (or seralizer and deserializer) functions. Or find someone else's code that does this already.
Also remember to deal with endian-ness - you must define which sequence the bytes are sent through the named pipe.
For example, you could define that the message sent consists of a 4-byte unsigned integer in network byte order defining how many structures follow, and each structure could be a sequence of 4 signed 4-byte integers for the array followed by a single signed 4-byte integer for
_data2(also sent in network byte order).Note that the choice of named pipe as the IPC mechanism is largely immaterial; unless you are using shared memory (inherently on the same machine), then endian-ness has to be dealt with, and even with shared memory, you need to deal with serialization.