summaryrefslogtreecommitdiffstats
path: root/examples/using_union_messages/README.txt
diff options
context:
space:
mode:
authorPetteri Aimonen <jpa@git.mail.kapsi.fi>2013-11-17 19:20:04 +0200
committerPetteri Aimonen <jpa@git.mail.kapsi.fi>2013-12-29 20:26:57 +0200
commitef31774cd902a6f069b8f2b80b870167328f5acb (patch)
tree321c008c224a5e197925030e1ddafcc0a88536d6 /examples/using_union_messages/README.txt
parent480b39cc0adc749ad81183fad2bfce6548c56604 (diff)
Moving files around
Renamed READMEs to README.txt to be more friendly for Windows users.
Diffstat (limited to 'examples/using_union_messages/README.txt')
-rw-r--r--examples/using_union_messages/README.txt52
1 files changed, 52 insertions, 0 deletions
diff --git a/examples/using_union_messages/README.txt b/examples/using_union_messages/README.txt
new file mode 100644
index 00000000..7a1e75d4
--- /dev/null
+++ b/examples/using_union_messages/README.txt
@@ -0,0 +1,52 @@
+Nanopb example "using_union_messages"
+=====================================
+
+Union messages is a common technique in Google Protocol Buffers used to
+represent a group of messages, only one of which is passed at a time.
+It is described in Google's documentation:
+https://developers.google.com/protocol-buffers/docs/techniques#union
+
+This directory contains an example on how to encode and decode union messages
+with minimal memory usage. Usually, nanopb would allocate space to store
+all of the possible messages at the same time, even though at most one of
+them will be used at a time.
+
+By using some of the lower level nanopb APIs, we can manually generate the
+top level message, so that we only need to allocate the one submessage that
+we actually want. Similarly when decoding, we can manually read the tag of
+the top level message, and only then allocate the memory for the submessage
+after we already know its type.
+
+
+Example usage
+-------------
+
+Type `make` to run the example. It will build it and run commands like
+following:
+
+./encode 1 | ./decode
+Got MsgType1: 42
+./encode 2 | ./decode
+Got MsgType2: true
+./encode 3 | ./decode
+Got MsgType3: 3 1415
+
+This simply demonstrates that the "decode" program has correctly identified
+the type of the received message, and managed to decode it.
+
+
+Details of implementation
+-------------------------
+
+unionproto.proto contains the protocol used in the example. It consists of
+three messages: MsgType1, MsgType2 and MsgType3, which are collected together
+into UnionMessage.
+
+encode.c takes one command line argument, which should be a number 1-3. It
+then fills in and encodes the corresponding message, and writes it to stdout.
+
+decode.c reads a UnionMessage from stdin. Then it calls the function
+decode_unionmessage_type() to determine the type of the message. After that,
+the corresponding message is decoded and the contents of it printed to the
+screen.
+