I have no wireshark parser and I don't have time to learn it... The content dumper exists in tst_parser.cpp (function parseOne). It follows the recommendations from section 6.1 and appendix A in RFC 7049 -- with one exception: there's no support for printing chunked strings.
I will make it a standalone tool and rely only on <stdlib.h> and <stdio.h> instead of Qt. On Wednesday 27 May 2015 09:02:26 Lankswert, Patrick wrote: > Thiago, > > It looks like a win on all sides from a design perspective. Where are we on > diagnostics? Meaning, have you been able to find a WireShark parser? Have > you added a printCBOR(...) method to dump the contents to a log? > > These are phase III items to help test engineering, etc. > > Pat > > > -----Original Message----- > > From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev- > > bounces at lists.iotivity.org] On Behalf Of Thiago Macieira > > Sent: Friday, May 22, 2015 6:14 PM > > To: iotivity-dev at lists.iotivity.org > > Subject: [dev] The move to CBOR > > > > Hello > > > > I've just pushed a series of commits that contain my latest updates on the > > move to CBOR. The commits (see list at the bottom of this email) implement > > the > > > > following: > > * modify several functions and structures dealing with payloads to keep > > the > > > > payload size in an extra variable, instead of using strlen > > > > * import the "libcbor" library [1] > > * add two cbor source files to the build > > * convert several payloads in the base resources from JSON to CBOR [2] > > > > Missing: > > * there are still a couple more places where JSON is used and I haven't > > fixed * a Cereal sink for the C++ API > > * modifying the CoAP Content Format PDU header from 50 > > > > (application/json) to > > > > 60 (application/cbor) -- I'd have done this, but I couldn't find where > > it's > > done, as COAP_MEDIATYPE_APPLICATION_JSON isn't used anywhere in > > > > our code > > > > * any code above the C++ layer that assumes that the payload is JSON, > > > > instead > > > > of using OCRepresentation like it should > > > > Other improvements: > > * the CBOR encoder does not allocate memory, unlike the cJSON one. This > > > > should shrink dynamic memory usage on all devices and open up the > > for the possibility of zero copy > > > > * this gets rid of manual JSON encoders and decoders. I found one in the > > > > source that is not even compliant > > > > I was asked for some benchmarks. First off, code sizes: > > $ find cjson libcbor -name \*.o | xargs size > > > > text data bss dec hex filename > > 7787 16 8 7811 1e83 cjson/cJSON.o > > 1077 0 0 1077 435 libcbor/src/cborencoder.o > > 2870 0 0 2870 b36 libcbor/src/cborparser.o > > > > Second, I prepared some performance benchmarks: > > JSON CBOR Improvement > > > > CPU ticks 14025 5100 2,75 > > CPU cycles 17127 6167 2,78 > > Branch misses 34,04 0,02 2057 > > Instructions 34555 5980 5,78 > > L1 data cache loads 10436 2017 5,17 > > L1 data cache misses 13,90 0,11 127 > > [see attached image for a graph] > > > > Notes: > > [1] the library will exist in an upstream on GitHub. I am in the process > > of > > obtaining the necessary repository from the Intel GitHub account, so this > > doesn't live on my personal GitHub account > > > > [2] the conversion is unconditional. I am not keeping the old JSON code. > > > > Relevant commits: > > https://gerrit.iotivity.org/gerrit/969 > > https://gerrit.iotivity.org/gerrit/968 > > https://gerrit.iotivity.org/gerrit/975 > > https://gerrit.iotivity.org/gerrit/991 > > https://gerrit.iotivity.org/gerrit/905 > > https://gerrit.iotivity.org/gerrit/992 > > https://gerrit.iotivity.org/gerrit/967 > > https://gerrit.iotivity.org/gerrit/1102 > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > Software Architect - Intel Open Source Technology Center -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
