Hi Alex, On 09/09/14 10:46, Alexander Aring wrote: > Hi Martin, > > On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: > ... >>> I thought more about that, you mean the receiving part only? So the >>> uncompression. The point is that we don't have no interface for an user >>> that can decide if he like to use UDP compression like RFC 6282 or UDP >>> compression like GHC. This is only relevant for the transmit part. So >>> compression is optionally. (We should have some interface to make this >>> configurable by user -> adding this to the nhc layer, later). >> I've implemented compression and decompression. You are right in that we >> need a mechanism of configuring what gets compressed by what method. > ok. But how we deal with that currently with GHC UDP and UDP RFC6282 > compression. We can't not support both compression methods. > > btw. how we should call it now? Uncompression or decompression, I can > also name the callbacks to decompression. I am not a native speaker so > I will ask you which is better now. :-) As an English speaker I have to admit I don't know. Here's one link I found on the subject http://english.stackexchange.com/questions/56480/difference-between-uncompress-and-decompress to confuse you even more :)
> >>> On the uncompression part, means the receiving part we can support both. >>> UDP RFC 6282 or UDP like GHC, the next header id value should be >>> different there. That means currently we can receive every packets but >>> transmit only RFC6282 compression formats. >>> >>> So for receiving this, it's okay. But for compression, since we don't >>> have some interface to make this configurable we should use RFC 6282. >> So I will ensure UDP is compressed by 6282. Then I was going to start out >> by just compressing ICMPv6 with GHC and monitor how much data is saved by >> using GHC. Later on we will implement a mechanism of configuring what gets >> compressed and by which compression method. > Okay, you mean that you will leave UDP compression by 6282 but insert a > receive handling (decompression) for UDP GHC? > > RFC6282 doesn't describe any compression/decompression(or uncompression) > format for ICMPv6, so we could handle there compression and > uncompression. I understand now you did it that way, or? For the moment I will assume all ICMPv6 traffic is compressed and decompressed with GHC as this will be the only Next Header Compression format. In future we need something better. We also need a method of knowing what compression formats a device supports. I can see a list of compression formats which could also be a list by protocol. Then when sending to a device you would select the highest ranking supported compression format for that device. > > About the mechanism by user: > > There are several ways about to do it from userspace. I know now sysfs > or netlink. Do you have already some idea how you want to make this > configurable by user? > > > btw. > This reminds me a little bit like setting led trigger type, (blink, > heartbeat, mmc, net, etc...). This is done by sysfs. > >> The GHC spec states that a device indicates it's GHC capability using a >> 6LoWPAN Capability Indication Option (6CIO), this is an ND option. As far >> as I can see there is no type assigned yet by IANA so I was wondering if we >> should have this as an experimental configuration item in the kernel? > Yes, please make a bool into net/6lowpan/Kconfig and add support for > drafts only if selected. > > In code you simple need to use "if (IS_ENABLED(CONFIG_FOO))" to > registration the nhc format into the nhc framework/layer or not. > > Replace FOO with a propber 6LOWPAN_NHC_DRAFTS or something else. You can > write in the help what exactly this means. > > - Alex - Martin ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
