The primary changes to IoTivity internals involve how network addresses are handled. The situation prior to these changes is detailed in IOT-999.
As described in the API changes, a network address must be accompanied by additional information. See the description of OCDevAddr in “asdfasdf”. This additional information must be collected on received messages, transferred to the resource structures near the application, and used to make additional network transfers.
The context is kept in two fields (flags and adapter). The ‘adapter’ is an index used to direct network requests to the correct network adapter in the connectivity abstraction. The ‘flags’ are modifiers of how the connection will be made.
The network address is carried as a string for all adapter types. For IP addresses two additional pieces of context are needed: Scope ID and port number. The Scope ID is coded in standard form as a suffix on the address string (‘%11’) and is handled by the same conversion methods (getaddrinfo, getnameinfo) used for the address itself. The port number is stored in a separate variable. Since the IP adapter (and IP addressing) are likely to be the primary uses (by far) of the addressing, I felt having a separate port variable is appropriate.
The address string is allocated to be large enough to hold the largest string from any adapter. In practice, this means it is long enough to hold a fully expanded IPv6 address with an interface index (45 bytes).
Two IoTivity structures hold network addresses after this change: OCDevAddr and CAEndpoint_t. Previously, several nearly identical structures were used (CARemoteEndpoint_t, CAGroupEndpoint_t, CALocalConnectivity_t).
Also, OCDevAddr and CAEndpoint_t are identical in content. This identical nature is currently maintained by careful editing of the two structures. This is fragile, so it should be replace soon by using a single structure (probably OCDevAddr since it is also used in the API.) The build structure currently mandates separate structures for the C++ and connectivity abstraction layers. A future change in the build structure should eliminate that mandate. The cost would be eliminating the ability to build and test the connectivity abstraction separately from the OCStack layer.
I found that eliminating the proliferation of networking addressing structures simplified a lot of code.
For IPv6 the flags are needed at the bottom of the stack, so the CAEndpoint_t structure is used to carry the addressing information all the way to the bottom levels of the stack. You can see this in caipadapter.c and caipclient.c.
The C++ OCResource structure now holds the network addressing information in an OCDevAddr structure, simplifying receiving responses and sending requests.
The network address structures are now entirely devoted to addressing. Previously, some payload information (resourceUri) was kept in CARemoteEndpoint_t, but it has been moved to the payload info structures, where it belongs.
The appearance of payload information in the addressing structure was an artifact of our CoAP heritage. In CoAp the start of a message includes both the network address and the start of the payload (e.g.,
). New code in OCDoResource separates the address and resourceUri upon entry into the stack, so the resourceUri can be processed as part of the payload rather than kept with the address.
The indication of whether a network link should use security is now kept in the network address context as a flag (OC_SECURE) rather than carried along as a separate variable.