A critical performance issue on UICC

[GoogleCodeExporter]

Purpose of this feature: Performance improvement

How should the feature be integrated: Globalplatform Access Control enforcer

Due to the communication latency between device and UICC, fetching the Refresh 
tag every time when openLogicalChannel() is called is proved very costly at 
performance.

One of improvement options is to move the Refresh tag fetching from Channel 
layer to Session layer.  In other words, AC enforcer should fetch the Refresh 
tag only when a new session instead of a channel is opened.   Theologically the 
change will booster the performance 40% to 80%.

Thanks.  

Original issue reported on code.google.com by danny.w....@gmail.com on 5 Sep 2012 at 5:32

[GoogleCodeExporter]

Could you highlight which applications could benefit from this change? 
The real-world applications we're aware of are either
- UI-driven: user opens app, app opens session & channel & exchange data, user 
closes app, app closes channel & session
- background services: trigger from somewhere, service starts, opens session & 
channel, exchange data, service closes channel & session
Which use case do you have in mind where an application opens & closes a 
channel a lot of times inside one session?

Original comment by Daniel.A...@gi-de.com on 7 Sep 2012 at 2:21

[GoogleCodeExporter]

A client to SEEK can benefit from this, because during 1 full Operation, the 
client might have a need to interact with different Applet on the SE.

With the current implementation, each time a client want to openLogicalChannel 
against a specific AID, even if the rule is not changed, SEEK always need to 
open the Access Control applet to check whether the rule has been changed.

Client openSession
----------------------->
Client openLogicalChannel(AID 1)
----------------------->
                        AC Enforcer openLogicChannel(AC Applet)
                        ---------------------->
                        AC Enforcer check rule
                        ---------------------->
                        AC Enforcer logic on checking access allowed
                        -----
                             |
                        <----
                        SEEK openLogicChannel(AID 1)
                        ---------------------->
Client do some APDU Exchange
----------------------->
                        ---------------------->
Client closeLogicChannel
----------------------->
                        ---------------------->
...
...
...
Client openLogicalChannel(AID X)
----------------------->
                        AC Enforcer openLogicChannel(AC Applet)
                        ---------------------->
                        AC Enforcer check rule
                        ---------------------->
                        AC Enforcer logic on checking access allowed
                        -----
                             |
                        <----
                        SEEK openLogicChannel(AID X)
                        ---------------------->
Client do some APDU Exchange
----------------------->
                        ---------------------->
Client closeLogicChannel
----------------------->
                        ---------------------->
Client closeSession
----------------------->

By moving the "check AC Applet" logic to Session, it can eliminate the extra 
transaction related to access control, and benefit run time performance.

Of course, the main issue might be that whether Specification on Access Control 
allowed the checking of rule refresh to happen on Session level instead of 
Channel level.

Original comment by tommypo...@gmail.com on 7 Sep 2012 at 3:16

[GoogleCodeExporter]

I fully agree that AC checks in Session.open() could speed up applications a 
lot over the current implementation inside Channel.open().
My question was targeting the importance of this change request - do you have 
an application (outside a test-lab) where this performance improvements apply?
As developers contributing to this project are limited we have to prioritize 
any change request - especially requests that have such big impacts on the 
current architecture... :)

Original comment by Daniel.A...@gi-de.com on 7 Sep 2012 at 10:54

[GoogleCodeExporter]

ISIS Wallet is one of the applications which will benefit from this change.

Original comment by danny.w....@gmail.com on 9 Sep 2012 at 5:40

[GoogleCodeExporter]

fixed in SCAPI-3.0.0

Original comment by Daniel.A...@gi-de.com on 15 Apr 2013 at 3:12

• Changed state: Done