User Tools

Site Tools


proposal_for_network_interface_management_in_iotivity_stack

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
proposal_for_network_interface_management_in_iotivity_stack [2015/03/26 15:17]
John Light
proposal_for_network_interface_management_in_iotivity_stack [2015/03/27 18:53] (current)
John Light [Implementation notes]
Line 130: Line 130:
   - Based on user feedback, we could choose when to provide the Configuration stage, which might be complicated by dynamic changes to the ID array.   - Based on user feedback, we could choose when to provide the Configuration stage, which might be complicated by dynamic changes to the ID array.
  
-Default stage behavior simplifies implementation because there is no need to bind interfaces to the socket ​we are using. ​ We only need two sockets (one IPv6, one IPv4) sending and listening on the same port (5683), plus two more sockets for DTLS.  (If it is known we are only using DTLS, only two ports would be needed.) ​ All sockets ​would not bind to a local address ​(INADDR_ANY).  ​In factthis behavior is already entirely implemented in the ca-ipv6 branch.+For the Default stagewe should create a pair of sockets (IPv6 and IPv4) for each active interface. ​ All of them should be added to the CoAP multicast group for the CoAP port (5683). ​ (For DTLS we will need that many more sockets ​bound to the CoAP DTLS port (5684)).  ​When an application requests a FindResourcewe will iterate through all the available interfaces to send the multicast message. ​ Two listening sockets (CoAP and CoAP DTLS) are sufficient
  
-Selection stage behavior is slightly more complex.  ​The simplest way to do it is to open a pair of sockets (IPv6 and IPv4) for each active entry in the ID array at startup, storing ​the associated ​file descriptor in the ID array element. ​ Each of these sockets will be bound to the interface specified in the ID array. ​ This small number of sockets is not a burden on Linux, which is built to scale to many hundreds of sockets. ​ Then open up an unbound socket (as in the Default stage).  ​When a Find request arrives, do one of two things: +Selection stage behavior is slightly more complex.  ​As in the Default stage, we open a pair of sockets (IPv6 and IPv4) for each active entry in the ID array at startup, storing ​its file descriptor in the associated ​array element. ​     When a FindResource ​request arrives, do one of two things: 
-  - If the lower 24 bits of OCInterfaceMask are zero, use the unbound socket, as in Default stage.+  - If the lower 24 bits of OCInterfaceMask are zero, send the request to all interfaces, as in Default stage.
   - If non-zero, loop through the bits and use the file descriptor in the corresponding ID array entry to send the message. ​ (Maybe only one bit will be set in a particular request.)   - If non-zero, loop through the bits and use the file descriptor in the corresponding ID array entry to send the message. ​ (Maybe only one bit will be set in a particular request.)
  
proposal_for_network_interface_management_in_iotivity_stack.txt · Last modified: 2015/03/27 18:53 by John Light