Hi Alex, On 09/09/14 11:47, Alexander Aring wrote: > Hi Martin, > > On Tue, Sep 09, 2014 at 11:17:15AM +0100, Martin Townsend wrote: >> 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. > Is "what compression methods like a device to use" part of any RFC? Is there > something which I don't know? I mean, okay you can do that in any > application layer in userspace. But I don't see that we need something > like this in kernelspace. I know there is no suggestion that you want to > implement something like this in kernelspace, but I want to clarify this. > > Application layer in userspace means, use some own coap(or whatever) based > protocol and setup the right compressions via userspace by some application.
I don't know what would be implemented in user or kernel space it's just a general observation that we need some mechanism in the future, of knowing what capabilities a device we want to send to supports so we can select compression accordingly. > - 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
