Carston, I see the value of doing something along this line.
On the server side, choosing a specific port (range) seems obvious since there is little competition for ports. The client side is more problematical since there can be a large competition for ports. Trying to squeeze into the RFC '11' case means all applications on a client are competing for 16 ports, which will work much of the time, but is somewhat risky. 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. John -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Carsten Bormann Sent: Monday, June 22, 2015 4:29 PM To: Macieira, Thiago Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Proposal for IP Adapter and request for feedback 6LoWPAN UDP header compression also benefits if the port number you use for most of your messages is 0xf0xx (even more so if both ports are 0xf0bx). http://tools.ietf.org/html/rfc6282#section-4.3.3 It is only a byte (or three bytes) saved, but that is an easy byte to save just by choosing a port number fitting this pattern. Gr??e, Carsten _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
