【问题标题】:How to read an extension .proto file (textformat.merge) with old code?如何使用旧代码读取扩展名 .proto 文件(textformat.merge)?
【发布时间】:2012-05-05 02:59:57
【问题描述】:

我的问题与谷歌协议缓冲区的 C# 实现有关(protobuf-csharp-port,作者 jon skeet,干得好!)

我遇到了扩展问题:假设我写了:

  • “transport_file.proto”带有“传输消息”和一些代码
    处理它“code_old”。
  • 我写了一个传输消息的扩展 “Mytransport.proto”文件,以及读取它的新代码“code_new”。

我正在尝试读取一条新消息(来自 MyTransport.proto),其中 code_old 期望忽略扩展,但我在 TextFormat 的合并方法中遇到异常:“transport”没有名为“whatever_new_field”的字段

Transport.Builder myAppConfigB = new Transport.Builder();
System.IO.StreamReader fich = System.IO.File.OpenText("protocolBus.App.cfg");
TextFormat.Merge(fich.ReadToEnd(),myAppConfigB);
fich.Close();

新的扩展文件如下所示:

...
  Transport 
  { 
     TransportName: "K6Server_0"
     DllImport: "protocolBus.Transports.CentralServer"
     TransportClass: "K6Server"
     K6ServerParams
     {
        K6Server { host: "85.51.11.23" port: 40069 }
        Service: "TZinTalk"
        ...
     }
  }
...

而旧的,没有扩展:

...
  Transport 
  { 
     TransportName: "K6Server_0"
     DllImport: "Default"
     TransportClass: "Multicast"
  }
...

整个想法是使用基于文本的协议缓冲区作为配置文件,我在其中编写了一些参数,并基于其中一个加载和组装(它将使用新扩展读取整个消息(初始化参数对象)。

有什么想法吗?(这是一个令人绝望的问题:D)

我正在使用 MSVC# 2008Express 版本,protobuf-csharp-port 版本 0.9.1(总有一天我会升级一切)。

提前致谢。


我正在研究具有不同传输方式的非中心化发布-订阅消息框架(对于原始文件中的任何书面消息,我会自动创建一个发布和订阅者类)。默认情况下,我使用多播,但也包括广播和“UDP 星”。我让扩展机制让人们使用它的 owm 配置参数添加新的传输,这些参数应该由我的主 code_old 读取(只是为了加载程序集)并让新的传输 (.dll) 再次读取它(完全)。 好奇的?上一个几乎可以使用的版本在http://protocolbus.casessite.org

更新 1

文本格式的扩展类型括在括号中(很高兴知道,我不知道:D)所以我应该写:

 [K6ServerParams]
 {
    K6Server { host: "85.51.11.23" port: 40069 }
    Service: "TZinTalk"
    ...
 }

【问题讨论】:

    标签: c# protocol-buffers protobuf-net


    【解决方案1】:

    协议缓冲区被设计为在使用它们的 binary 格式时向后和向前兼容,但是当前代码当然不希望解析具有未知字段的 text 格式.它可能会被更改以执行此操作,但我想检查 Java 代码以尝试保持与之相同。

    您有什么理由不使用二进制表示开始吗?这是正常的预期用途,也是绝大多数工作都投入其中的用途。(话虽如此,在远离代码之后,这一切似乎有点模糊......)

    【讨论】:

    • 哇,没想到这么快就有答案了!我很感激。感谢你的回答。这让我发疯,我认为我做错了什么......好吧,我想我必须以其他方式去做。再次感谢!我在网上发送包时使用二进制版本,它非常适合,但对于配置,我更喜欢文本版本(没有人,没有用于配置的 xml 文件,原始版本更具可读性)。
    • @chasques:如果您查看最新版本,我们有一些 JSON 支持,您可能会发现它比文本格式支持更具可读性。 可能支持未知字段 - 我不确定。
    • 这可能是更新到新版本的好理由。我正在考虑将另一个文件与新参数(原型的扩展参数)一起使用,但 json 解决方案似乎更优雅。我会检查一下。再次感谢!
    • 嗨,只需几行代码就可以为这件事添加一些亮点:我确实更新了您的库,这比我想象的要容易得多,并且我确实尝试使用 JSON 格式化程序 JsonFormatReader 并获得相同的结果.所以,不要再找借口偷懒了:我一直在研究代码,我得出了一些结论: 1.- C# 版本(我猜也是 java 版本):如果扩展未注册,则抛出异常或者根本不存在注册表!!!
    • 2.- C++ 版本:在没有找到扩展名的情况下(没有扩展名或没有注册表)返回 false 并继续解析消息,之后使用日志或错误收集器通知(ReportError) ,但不停止解析器(为扩展中的每个字段重复错误/日志通知(对此不太确定))。因此,在这种情况下,可以读取带有未知扩展名的文本格式消息。我正在尝试使用“n~apa”(西班牙语,简单但不好的工程解决方案)来修改 TextFormat.cs,以实现我的私有功能。再次感谢。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2016-12-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-08-20
    相关资源
    最近更新 更多