" it makes sense to always try these ports even if the current device has no 6LoWPAN interfaces."
On a server I probably agree. I doubt shortage of these sockets on a server. On a client we should only ask for them if we expect to benefit. But how do we tell? I'd be willing to take the application's word for it (bit in flags), but I wouldn't want to do it by default. John Light Intel OTC OIC Development -----Original Message----- From: Macieira, Thiago Sent: Wednesday, June 24, 2015 11:46 AM To: Light, John J Cc: Carsten Bormann; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Proposal for IP Adapter and request for feedback On Wednesday 24 June 2015 11:33:41 Light, John J wrote: > I don't know how header compression works. At what point does the > referenced UDP LOWPAN_NHC Format come into play? Are both ports created > first, so you know what you've got to work with? Or do you only know > one port at a time and have to make assumptions about the other port? > If the ports are created first and you pick the Format after, then > pulling from a 256 entry pool seems doable. > One concern is tying up limited space without actually using header > compression. Header compression is applied by the node that transmits on the 6LoWPAN adapter. So it makes sense to always try these ports even if the current device has no 6LoWPAN interfaces. But like I said, it might be best to come up with a Linux kernel feature to suggest these ports and let it do the finding of the free one available. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
