>>[Hans] But when sending a message is 8 or 16 bits sent across?
>> We had discussed before if a major/minor scheme could be applied on top of 
>> this. If 16 bits are sent/received I guess we have the possibility to use 
>> the unused 8 bits for a minor version?

Message format version is 16 Bits and is being sent across. For using the 
Major/minor version, you need to add lot of code in applications and MDS as 
well which is not suggested(But if certain cases arise we may need
to think of it).


On Friday 04 April 2014 12:16 PM, Hans Feldt wrote:
> See inline
> Thanks,
> Hans
>
>> -----Original Message-----
>> From: SuryaNarayana Garlapati [mailto:suryanarayana.garlap...@oracle.com]
>> Sent: den 4 april 2014 08:29
>> To: Hans Feldt
>> Cc: Hans Feldt; Hans Nordebäck; praveen malviya; nagendr...@oracle.com; 
>> opensaf-devel@lists.sourceforge.net
>> Subject: Re: [devel] [PATCH 2 of 5] amfnd: store amfd mds ver [#574]
>>
>> Hi Hans,
>> Comments/answers inline.
>>
>> Regards
>> Surya
>> On Friday 04 April 2014 11:16 AM, Hans Feldt wrote:
>>> Hi,
>>> I interpreted your answer such that there are two alternatives:
>>> 1) rely on mds sub part version but then I need to handle NEW-ACTIVE or
>>> 2) use message format version instead
>>>
>>> Seems like you had a preference for 2?
>> [Surya] Yes, message format should be used and that is the correct way
>> to handle this situation.
>>> Any alternative seems to require quite a few more changes in amfnd.
>>> Alt1 would need add new event event handling in both the mds callback
>>> and main thread. Alt2 would require to preserve the message format
>>> version all the way to the event handler.
>> [Surya] Yes, it is preferred to preserve the message format
>> version(variable i_msg_fmt_ver) all the way to event handler.
>>> But again the strange thing is that these are not the same formats and
>>> there is not much explaining what they are.
>> [Surya] I think i had already explained in my earlier emails, but here
>> goes the explanation.
>>
>>    MDS Service subpart version is the version of a service with which it
>> has installed with MDS.
>> Message format version is the version with which a message was encoded.
>> Such that on the receiving end,
>> application uses this message format version and decodes the message
>> accordingly.
>>>    mds sub part version is 8
>>> bits, used at MDS install and service discovery (SVC_EVENT callback).
>> [Surya] Yes you are correct.
>>> But message format version is 16 bit. Normally (at least in amf)
>>> message format version seems to get filled with sub part version so 8
>>> bits of it is unused.
>> [Surya] Actually there were some limitations with the number of bits
>> that were available in the TIPC namesequence bind.
>> So it was limited it to 8 bits for the SVC install.
> [Hans] But when sending a message is 8 or 16 bits sent across?
> We had discussed before if a major/minor scheme could be applied on top of 
> this. If 16 bits are sent/received I guess we have the possibility to use the 
> unused 8 bits for a minor version?
>
>>> Thanks,
>>> Hans
>>>
>>> On 3 April 2014 13:13, SuryaNarayana Garlapati
>>> <suryanarayana.garlap...@oracle.com> wrote:
>>>> Comments:
>>>> 1. First of all, the mds sub part version should not be stored/used. You
>>>> should depend on the message format version as SI rank is being embedded
>>>> in the new message(which is being sent from AVD).
>>>>     If you have a requirement for usage of message version, you can get it
>>>> at runtime when you receive a SUSI message etc. Decode the received
>>>> message and use the message format version.
>>>> 2.  As per patch, Storage of mds version will happen only once for a
>>>> life time. You need to process the NEW-ACTIVE event of MDS as well
>>>> which will make sure to store the mds version even after the
>>>> failover/switchover.
>>>>
>>>> Regards
>>>> Surya
>>>>
>>>> On Friday 28 March 2014 06:44 PM, Hans Feldt wrote:
>>>>>     osaf/services/saf/avsv/avd/avd_mds.c           |  2 ++
>>>>>     osaf/services/saf/avsv/avnd/avnd_di.c          |  1 +
>>>>>     osaf/services/saf/avsv/avnd/avnd_mds.c         |  3 +++
>>>>>     osaf/services/saf/avsv/avnd/include/avnd_cb.h  |  1 +
>>>>>     osaf/services/saf/avsv/avnd/include/avnd_evt.h |  1 +
>>>>>     5 files changed, 8 insertions(+), 0 deletions(-)
>>>>>
>>>>>
>>>>> diff --git a/osaf/services/saf/avsv/avd/avd_mds.c 
>>>>> b/osaf/services/saf/avsv/avd/avd_mds.c
>>>>> --- a/osaf/services/saf/avsv/avd/avd_mds.c
>>>>> +++ b/osaf/services/saf/avsv/avd/avd_mds.c
>>>>> @@ -414,6 +414,8 @@ static uint32_t avd_mds_svc_evt(MDS_CALL
>>>>>                         break;
>>>>>
>>>>>                 case NCSMDS_SVC_ID_AVND:
>>>>> +                     // TODO remove, just for test
>>>>> +                     LOG_NO("%s: AVND UP version: %u", __FUNCTION__, 
>>>>> evt_info->i_rem_svc_pvt_ver);
>>>>>                         if (evt_info->i_node_id == cb->node_id_avd) {
>>>>>                                 AVD_EVT *evt = calloc(1, sizeof(AVD_EVT));
>>>>>                                 osafassert(evt);
>>>>> diff --git a/osaf/services/saf/avsv/avnd/avnd_di.c 
>>>>> b/osaf/services/saf/avsv/avnd/avnd_di.c
>>>>> --- a/osaf/services/saf/avsv/avnd/avnd_di.c
>>>>> +++ b/osaf/services/saf/avsv/avnd/avnd_di.c
>>>>> @@ -421,6 +421,7 @@ uint32_t avnd_evt_mds_avd_up_evh(AVND_CB
>>>>>
>>>>>                 /* store the AVD MDS address */
>>>>>                 cb->avd_dest = evt->info.mds.mds_dest;
>>>>> +             cb->avd_mds_ver = evt->info.mds.rem_svc_pvt_ver;
>>>>>
>>>>>                 avnd_send_node_up_msg();
>>>>>         }
>>>>> diff --git a/osaf/services/saf/avsv/avnd/avnd_mds.c 
>>>>> b/osaf/services/saf/avsv/avnd/avnd_mds.c
>>>>> --- a/osaf/services/saf/avsv/avnd/avnd_mds.c
>>>>> +++ b/osaf/services/saf/avsv/avnd/avnd_mds.c
>>>>> @@ -594,8 +594,11 @@ uint32_t avnd_mds_svc_evt(AVND_CB *cb, M
>>>>>         case NCSMDS_UP:
>>>>>                 switch (evt_info->i_svc_id) {
>>>>>                 case NCSMDS_SVC_ID_AVD:
>>>>> +                     // TODO remove, just for test
>>>>> +                     LOG_NO("%s: AVD UP version: %u", __FUNCTION__, 
>>>>> evt_info->i_rem_svc_pvt_ver);
>>>>>                         /* create the mds event */
>>>>>                         evt = avnd_evt_create(cb, AVND_EVT_MDS_AVD_UP, 0, 
>>>>> &evt_info->i_dest, 0, 0, 0);
>>>>> +                     evt->info.mds.rem_svc_pvt_ver = 
>>>>> evt_info->i_rem_svc_pvt_ver;
>>>>>                         break;
>>>>>
>>>>>                 case NCSMDS_SVC_ID_AVA:
>>>>> diff --git a/osaf/services/saf/avsv/avnd/include/avnd_cb.h 
>>>>> b/osaf/services/saf/avsv/avnd/include/avnd_cb.h
>>>>> --- a/osaf/services/saf/avsv/avnd/include/avnd_cb.h
>>>>> +++ b/osaf/services/saf/avsv/avnd/include/avnd_cb.h
>>>>> @@ -50,6 +50,7 @@ typedef struct avnd_cb_tag {
>>>>>         MDS_DEST avnd_dest;     /* AvND mds addr */
>>>>>         MDS_DEST avd_dest;      /* AvD mds addr */
>>>>>         bool is_avd_down;       /* Temp: Indicates if AvD went down */
>>>>> +     MDS_SVC_PVT_SUB_PART_VER avd_mds_ver; /* Director MDS version */
>>>>>
>>>>>         /* cb related params */
>>>>>         NCS_LOCK lock;          /* cb lock */
>>>>> diff --git a/osaf/services/saf/avsv/avnd/include/avnd_evt.h 
>>>>> b/osaf/services/saf/avsv/avnd/include/avnd_evt.h
>>>>> --- a/osaf/services/saf/avsv/avnd/include/avnd_evt.h
>>>>> +++ b/osaf/services/saf/avsv/avnd/include/avnd_evt.h
>>>>> @@ -128,6 +128,7 @@ typedef struct avnd_tmr_evt {
>>>>>     typedef struct avnd_mds_evt {
>>>>>         MDS_DEST mds_dest;      /* mds address */
>>>>>         NODE_ID node_id;
>>>>> +     MDS_SVC_PVT_SUB_PART_VER rem_svc_pvt_ver;
>>>>>     } AVND_MDS_EVT;
>>>>>
>>>>>     /* HA STATE change event definition */
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Opensaf-devel mailing list
>>>>> Opensaf-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Opensaf-devel mailing list
>>>> Opensaf-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel


------------------------------------------------------------------------------
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to