On 19-Sep-19 13:23, Liguangpeng (Roc, Network Technology Laboratory) wrote:
> Please see inline.
>
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>> Sent: Thursday, September 19, 2019 4:39 AM
>> To: Liguangpeng (Roc, Network Technology Laboratory)
>> <liguangp...@huawei.com>; anima@ietf.org
>> Subject: Re: Review comments on draft-ietf-anima-grasp-api
>>
>> On 18-Sep-19 18:22, Liguangpeng (Roc, Network Technology Laboratory) wrote:
>>> Hi authors,
>>>
>>> I read the draft. I think the API list for grasp is complete and good. But
>>> I have
>> some comments on section 2.2.
>>>
>>> 2.2. Asynchronous Operations
>>>
>>> '... there are two main techniques for such parallel operations:
>> multi-threading, or a polling or 'event loop' structure.'
>>>
>>> According to my knowledge, 'multi-threading' is a different thing with
>> asynchronous programming mechanism. So I prefer to 'asynchronous
>> programming mechanisms with multi-threading' here.
>>
>> OK, will rephrase.
>>
>>> The main techniques for asynchronous programming discussed in draft should
>> be 'polling', however, polling is not so efficient. The more efficient one
>> is 'call
>> back' mechanism.
>>
>> Yes, we certainly need to discuss callbacks. I'm not sure it is always more
>> efficient, because that depends on the underlying implementation.
>>
> Agree that all performance rely on the implementation. Generally saying,
> polling will consume CPU resource to query response again and again until
> timeout occurs. In other hand, every implement of agent based on polling
> mechanism library will couple with the library. That means most time
> different programmers will write the code respectively for the agent and
> library. It's more hard to guarantee achieve the best performance. Compared
> to polling, call back mechanism decouples the whole workflow. Only the
> library programmer need to care about the asynchronous part performance. The
> agent programmers just need to implement logics according to 'call back'
> mechanism then everyone can get the same performance provided by the same
> library.
>
>>> 'session_nonce' parameter may be useful for polling, but 'call back function
>> pointer( or reference in some programming language)' is normally used as
>> parameter of invoked functions. All logics should be executed in call back
>> functions which will be called when some events occur, for example receiving
>> response message for the request, or message timeout.
>>
>> Yes. However, if you have two simultaneous negotiations, you will still need
>> the
>> session_nonce in the callback, I believe.
>
> Yes or not, I think. If the library is implemented based on call back
> mechanism, the agent programmer don't need to know anything about
> 'session-nonce'. This means there needn't be this parameter in this kind of
> API. Indeed, the implementer of library need to consider 'session_nonce'
> carefully if its name is still 'session_nonce'. So, my opinion is
> 'session_nonce' is necessary parameter for polling-based API, but not for
> call-back-based API.
Sorry to insist, but I really disagree. I'm thinking about how I would code the
callback function for a resource allocator, and I'm sure it would need some
sort of identifier for the particular resource request, since it might be
handling many resource requests in parallel. In GRASP terms that is a session
identifier.
Regards
Brian
>
>> Thanks very much,
>>
>> Brian
>>
>>>
>>> Best regards,
>>>
>>> Guangpeng Li
>>
> Best regards,
> Guangpeng
>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
