At IETF 98, there was a request to avoid using setsockopt() as a blocking function for OnDemand as it is a function that is intended to merely set options and return immediately without waiting for external events (e.g., arrival of packets).
Some alternatives include: * Adding a new blocking function after setsockopt() * Using only the new function without setsockopt() * Using the new function without bind() Add a new blocking function after setsockopt() This alternative was suggested in the discussion in Chicago. The idea is to add a new call - waitforscservice() (wait for session continuity service) that blocks until the requested IP address with the session continuity service is provided by the network. This way, setsockopt() is used for setting the required session-continuity service request and does not block. The sequence of operations by an application will be: 1. Call socket() - open a socket 2. Call setsockopt() - to set the required session continuity service: Fixed, session-lasting or non-persistent. This call may trigger the TCP stack in the mobile node to request the address. 3. Call waitforscservice() - to block the thread until the address with the desired session-continuity service is provided (or until an indication that the service is not available) 4. Call connect() - to start a 3-way handshake when a TCP socket is initiated 5. Start receiving and transmitting bytes. In this sequence, there is a hidden assumption that waitforscservice() binds the created source IP address to the socket. Alternatively, we can define waitforscservice() as a function that returns the created IP address and require the application to call bind() to explicitly bind the address to the socket. Use only the new function without setsockopt() This alternative defines a new blocking function: setsc() (Set Session Continuity), specifies the type of session continuity service desired by the application. It is returns immediately if a source IP address with the desired session continuity service was already allocate to the mobile node, or blocks and initiates a request to the network to provide the appropriate IP prefix. When the prefix is provided (or when the operation fails) the function returns with the assigned source IP address and appropriate return status. After the source IP is set, the application calls bind() with the specified source IP address to bind it to the socket. The sequence of operations by an application will be: 1. Call socket() - open a socket 2. Call setsc() - set the required session continuity service and block until the address is provided. Return the address that was generated as a result of this request. 3. Call bind() with the provided IP address - bind the socket with the provided source IP address 4. Call connect() - to start a 3-way handshake when a TCP socket is initiated 5. Start receiving and transmitting bytes Use the new function without bind() Actually, setsc() can implicitly call bind() when successful in obtaining a source IP address with the desired session-continuity attributes. This eliminates the need to explicitly call bind(). The sequence of operations by an application will be: 1. Call socket() - open a socket 2. Call setsc() - set the required session continuity service (Fixed, Session-lasting or Non-persistent) and block until the address is provided. 3. Call connect() - to start a 3-way handshake when a TCP socket is initiated 4. Start receiving and transmitting bytes. There are pros and cons to this approach: There are less functions to call on one hand, but there is less flexibility in choosing which source IP address to bind on the other. The previous alternative is more aligned with the traditional Socket operation enabling an application to bind to a specific source IP address or transport port only when required to do so. Please share your thoughts and send your comments. Which is the preferred one? Any other (better) alternatives? Thanks, Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
