C ++ IPC通讯

Mut*_*thu 1 c++ ip tcp ipc

我在以下情况下无法做出决定。请需要专家的帮助。

方案:在两个框中运行的两个进程之间存在TCP / IP通信。

通信方法1:在套接字上基于流的通信。在接收方的哪里,他将接收整个字节缓冲区,并将前几个固定字节解释为标头,然后对其进行反序列化,从而了解消息长度,并开始获取该长度的消息并反序列化,然后继续进行下一个消息标头,如下所示:上....

通讯方式2:将所有消息放入向量中,向量将驻留在类对象中。一次性将类对象序列化并发送给接收者。接收器反序列化类对象,并一一读取向量数组。

请让我知道哪种方法有效,如果有其他方法,请指导我。

基于类的数​​据传输和基于结构的数据传输的优缺点,以及哪种情况适合哪种情况?

Ton*_*roy 5

您的问题缺少一些关键细节,并且混杂了各种问题,使任何无法提供良好答案的尝试都感到沮丧。

具体来说,方法2神秘地“序列化”和“反序列化”对象和包含的向量,而没有指定如何完成操作的任何细节。实际上,细节是方法1中提到的那种。因此,除非您在使用序列化库和从头做起之间进行选择(在这种情况下,我会说使用库),否则1和2并不是替代方案。因为您是新手,而图书馆更可能会正确处理此问题)。

我可以说:

  • 在TCP层,这是最有效的读入一个体面的大小的块(因为我倾向于在PC /服务器硬件的工作,我只是用64K虽然较小可能足以得到同样的吞吐量),并有各自read()recv()从套接字读取尽可能多的数据
    • 在读取了足够的字节(以许多读取/接收次数为单位)以尝试对数据进行某种解释之后,有必要认识到序列化输入的特定部分的结尾:有时在所涉及的数据类型中是隐式的,有时它是使用某些前哨进行通信的(例如换行或NUL),有时可能会有一个固定大小的前缀“ expect N bytes”标头。此方面/考虑因素通常分层应用于对象流和嵌套的子对象等。
    • TCP读/接收可能传递的数据比任何单个请求中发送的数据都要多,因此在上面组装的块的末尾,您可能具有1个或多个字节,这些字节在逻辑上是后续但不完整逻辑消息的一部分
    • C ++ iostream已支持读取较大的块然后访问缓冲区中各种固定和可变大小的元素的过程,但是如果需要,可以自行滚动

因此,让我强调一下:不要假设您从套接字的任何给定读取中接收到的字节数都不会超过1个字节:如果您说20字节的标头,则应该循环读取,直到遇到错误或汇编所有20个字节为止。一次发送20个字节,write()或者send()并不意味着将20个字节显示为一个read()/ recv()。TCP是字节流协议,必须在提供字节数时(在提供字节数时)取任意数量,直到有足够的数据来解释它为止。同样,准备获得比客户端在单个write()/`send()中写入的数据更多的数据。

基于类的数​​据传输和基于结构的数据传输的优缺点,以及哪种情况适合哪种情况?

这些术语完全是伪造的。类和结构在C ++中几乎是相同的-分组数据和相关函数的机制(它们的区别仅在于它们-默认情况下-将基类和数据成员暴露给客户端代码的方式)。可以具有成员函数或支持代码,以帮助序列化和反序列化数据。例如,最简单和最典型的支持是operator<<and / or operator>>流功能。

如果您想通过专门的“编写二进制块,读取二进制块”的方法(例如,将结构视为没有支持代码的POD)来对比这些流函数,那么我想说一下流函数从流式传输到人类可读的表示形式开始,这将使您的系统更容易,更快捷地进行开发,调试和支持。一旦您真正满意了,如果运行时性能需要它,则可以使用二进制表示形式进行优化。如果您很好地编写了序列化代码,您将不会注意到粗化器之间的性能差异void*/#bytes 数据模型和适当的每个成员序列化,但后者可以更轻松地支持异常情况-具有不同大小的整数/长度等的系统之间的可移植性,不同的字节顺序,有意的选择相对于指向数据的深度复制还是浅层复制等。 ...

我还建议您查看boost序列化库。即使您不使用它,它也应该使您更好地了解如何在C ++中合理地实现这种事情。