Subject: Re: [shim6] SHIM API and unconnected sockets

From: Shinta Sugimoto <[email-masked]>
Date: Sat, 09 Jan 2010 17:28:04 +0900

Hi Miika,

I found that I have not replied to your question below.  I am sorry for 
the delayed response.

Miika Komu wrote:
> Miika Komu wrote:
> 
> Hi,
> 
>> Henderson, Thomas R wrote:
>>
>> Hi,
>>
>>>> -----Original Message----- From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Miika Komu Sent:
>>>> Sunday, December 13, 2009 5:22 AM To: [email-masked] Cc: Kristian
>>>> Slavov Subject: [shim6] SHIM API and unconnected sockets
>>>>
>>>> Hi,
>>>>
>>>> the applicability of unconnected sockets says:
>>>>
>>>> 6.4. Notification from Multihoming Shim Sub-layer to Application
>>>>
>>>> ..
>>>>
>>>> There is no restriction in terms of applicability of the 
>>>> notification about locator change.  The notification can be
>>>> delivered to sockets regardless of if it is connected or
>>>> unconnected, stream-oriented or datagram-oriented.
>>>>
>>>> However, the shim6 locator API has to have a field for the ULID or 
>>>> otherwise an unconnected application cannot distinguish the
>>>> context:
>>>>
>>>> 7.1. Placeholder for Locator Information
>>>>
>>>> ... struct shim_locator { uint8_t    lc_family;       /* address
>>>> family */ uint8_t    lc_proto;        /* protocol */ uint16_t
>>>> lc_port;         /* port number */ uint16_t   lc_flags;        /*
>>>> flags */ uint16_t   lc_pref;         /* preference value */ 
>>>> uint32_t   lc_ifidx;        /* interface index */ struct in6_addr
>>>> lc_addr;    /* address */ };
>>>>
>>>> So, I think we need a struct in6_addr lc_ulid here and explain it
>>>> in the text.
>>>
>>>
>>> In section 6, under Figure 3, it says: In case of non-connected
>>> socket, msg_name member stores the socket address of the peer which
>>> should be considered as an identifier rather than a locator.  The
>>> locator of the peer node should be retrieved by SHIM_LOC_PEER_RECV as
>>> specified below.
>>>
>>> So, is the additional lc_ulid needed in this case?  Is it storing the
>>> socket address of the local host?
>>
>> This information is not available in socket options.
> 
> actually, I'm starting to wonder if I started this thread for nothing. I 
> think the lc_ulid field is not needed because section 6.4 applies only 
> to recvmg(). Right, Shinta?

Yes, seciton 6.4 applies only to recvsmsg().

As you mentioned above, I don't think identifier information needs to be 
embedded in the locator information data structure (shim_locator{}). 
The application can get identifier information by other means (as to the 
source identifier, the app can refer to the sockaddr stored in the 
msg_name.  as to the destination identifier, the app can use 
IP_RECVDSTADDR or IPV6_PKTINFO. as to the destination identifier).

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Sat, 09 Jan 2010 17:44:45 +0900

Miika Komu wrote:
> Shinta Sugimoto wrote:
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]]
>>>> On Behalf Of Miika Komu
>>>> Sent: Sunday, December 13, 2009 5:22 AM
>>>> To: [email-masked]
>>>> Cc: Kristian Slavov
>>>> Subject: [shim6] SHIM API and unconnected sockets
>>>>
>>>> Hi,
>>>>
>>>> notification
>>>>     about locator change.  The notification can be delivered
>>>> to sockets
>>>>     regardless of if it is connected or unconnected,
>>>> stream-oriented or
>>>>     datagram-oriented.
>>>>
>>>> otherwise an unconnected application cannot distinguish the context:
>>>>
>>>>     ...
>>>>         struct shim_locator {
>>>>                  uint8_t    lc_family;       /* address family */
>>>>                  uint8_t    lc_proto;        /* protocol */
>>>>                  uint16_t   lc_port;         /* port number */
>>>>                  uint16_t   lc_flags;        /* flags */
>>>>                  uint16_t   lc_pref;         /* preference value */
>>>>                  uint32_t   lc_ifidx;        /* interface index */
>>>>                  struct in6_addr lc_addr;    /* address */
>>>>          };
>>>>
>>>> So, I think we need a struct in6_addr lc_ulid here and
>>>> explain it in the
>>>> text.
>>>
>>>
>>> In section 6, under Figure 3, it says:
>>>    In case of non-connected socket, msg_name member stores the socket
>>>    address of the peer which should be considered as an identifier
>>>    rather than a locator.  The locator of the peer node should be
>>>    retrieved by SHIM_LOC_PEER_RECV as specified below.
>>>
>>> It is a bit unclear to me the relationship between an unconnected 
>>> socket and an underlying shim association (with context)-- perhaps 
>>> some explanatory text would be helpful to add that describes how the 
>>> transport-layer connection is related to the shim context, and what 
>>> it means when one is present but the other is not.
>>
>> I see your concern.  The relationship between an unconnected socket 
>> and shim context(s) is tricky and should be explained in the document, 
>> I think.  There was a discussion among authors whether to cover 
>> unconnected sockets or not for notification from the shim sub-layer to 
>> the application (the feature addressed in Section 6.4), and the 
>> outcome of the discussion was that we may cover unconnected socket as 
>> well provided that the shim sub-layer employs a kind of caching 
>> mechanism to store source and destination EID pair of the IP packet 
>> sent over the unconnected socket.  The cached information allows the 
>> shim sub-layer to  identify the target (unconnected) socket when there 
>> is an event (locator  change) occurs within a shim context.
>>
>> As Miika pointed out, we need to include the EID in the shim_locator{} 
>> structure in order to implement the notification mechanism *if* we aim 
>> at supporting unconnected socket.
> 
> I think the new field is not needed after all, please check the previous 
> email.
> 
>> All in all, I think we should simply exclude the support for 
>> unconnected sockets for the notification feature.  The reason is that 
>> there are too many system requirements posed by this, and I think it 
>> makes the system too complex.  The caching mechanism required by the 
>> support of unconnected sockets seems overkill, and the additional 
>> member (lc_ulid) for the shim_locator{} structure required by the 
>> support of unconnected sockets seems redundant to me as the data 
>> structure is meant to store information about a single locator.  I do 
>> not think it's worthwhile fulfilling these system requirements for the 
>> support of unnconnected sockets.  So, I'd suggest to specify that the 
>> notification from the shim sub-layer to the application is supported 
>> only for connected sockets.
>>
>> Miika (and maybe others), would you please hear your opinion on this?
> 
> I think we want to support unconnected sockets because the whole 
> notification feature requires recvmsg() which implies UDP based sockets. 
> This means that we're ruling out the majority of the audience which are 
> unconnected apps.

I am not sure if it is common that TCP applications do not use recvmsg() 
(TCP applications can use sendmsg() and recvmsg(), in theory), but if 
you really want to support unnconnected sockets, then I can live with that.

The system requirements posed by the support of unnconnected sockets are 
described in the document.

I am going to submit version 12 of the document shortly.

Regards,
Shinta