On Tue, Dec 02, 2014 at 11:23:36AM +0200, Jukka Rissanen wrote: ... > > I forgot to mention earlier that I think we need to support the case > where some clients are using different compression method than the other > (at the same time). What do you think? > > _Currently_ I would to do the following: Sending side: We have a mapping from nexthdr IPv6 field to the configurated (at the moment the defaults compression methods) next header compression. lowpan_compress -> nexthdr to nhc struct -> do nhc compression This is a 1:1 mapping for nexthdr as UDP we have RFC6282 UDP. _Maybe_ we can do some socket options settings in the future to have not always a 1:1 mapping. Sending sockopts to 6LoWPAN layer seems to be difficult, I don't know how much possible that is and the IPv6 agree with that. Otherwise we need some great idea to make allow different compression methods per socket. Currently a 1:1 seems to be okay. Receiving side: There we need to support everything what we can support. The next header compression id is a variable length of bitstring (that's why there is a complicated rbtree datastructure inside the nhc framework). This number is unique to each compression methods. It's some kind of n:1 mapping e.g. (UDP RFC6282) to UDP and (UDP FOOBAR) to UDP. So sending side _can_ be optionally and receiving _should_ be implemented. I have a new series which makes both optionally. The reason is that we can register the NHC ID and print a warning which NHC ID isn't supported. So this beahviour is more "We know this NHC but we don't support compression and uncompression". This will print a warning and users have two options: 1. Implement the nhc. 2. Change network configuration to not do this nhc on other nodes. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
