Parallel Process with readers - pcsc-lite

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Parallel Process with readers - pcsc-lite

MURILO COSTA
Hello

I have a Java system developed to record some smart cards and actually I am using it on Windows, but now I am looking forward to switch it to Linux, because some problems with USB smart card readers that I had, and to work with it I am using the pcsc-lite, that works very well.

But looking at some test results, I checked that the time of process on Linux is greater than on Windows, and looks like the reason is because the "parallel" process of windows, that doesn't happen on Linux when two or more readers are used. In Linux the commands are not send at the same time, they are synchronized, increasing the process time of whole process.

Is it a normal situation? Is there a way to work totally in parallel process?

I am using the OpenSuse 12.3 Linux with pcsc-lite 1.8.8, and the reader driver is a ccid compatible.

Thanks in advance.

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: Parallel Process with readers - pcsc-lite

Frank Marien
Strange, Murilo,

I'm on Linux (Arch), and have never observed anything like that, from
Java or otherwise.

For example, in

https://code.google.com/p/commons-eid/source/browse/commons-eid-dialogs/src/main/java/be/fedict/eid/commons/dialogs/BeIDSelector.java

the dialog is reading photos and names from electronic identity cards in
parallel, as many as there are readers.

Without this parallelism this dialog would become unfeasible with 2 or
more readers since reading the photo takes several seconds, but the
photos appear at about the same time, in 1.1 times the time required to
read one photo. Tried this with 5 readers, should scale up much higher.

This was also tested on various windows platforms, various Linux distros
and OSX and works fine everywhere.

Clearly parallellism works for me, as it should work for you.

I don't have OpenSUSE handy to try this but I would think it highly
improbable that they would have patched pcsc-lite to become an iterative
server somehow.

I'm guessing the serialization of your calls happens somewhere in your
own code or Java rather than in pcsc-llite or the OS..



-f

On 07/03/13 17:05, MURILO COSTA wrote:

> Hello
>
> I have a Java system developed to record some smart cards and actually I am using it on Windows, but now I am looking forward to switch it to Linux, because some problems with USB smart card readers that I had, and to work with it I am using the pcsc-lite, that works very well.
>
> But looking at some test results, I checked that the time of process on Linux is greater than on Windows, and looks like the reason is because the "parallel" process of windows, that doesn't happen on Linux when two or more readers are used. In Linux the commands are not send at the same time, they are synchronized, increasing the process time of whole process.
>
> Is it a normal situation? Is there a way to work totally in parallel process?
>
> I am using the OpenSuse 12.3 Linux with pcsc-lite 1.8.8, and the reader driver is a ccid compatible.
>
> Thanks in advance.
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: Parallel Process with readers - pcsc-lite

Francois Grieu-3
In reply to this post by MURILO COSTA
On 03/07/2013 17:05, MURILO COSTA wrote:
> I have a Java system (..) looking at some test results, I checked that the time of process on Linux is greater than on Windows, and looks like the reason is because the "parallel" process of windows, that doesn't happen on Linux when two or more readers are used. In Linux the commands are not send at the same time, they are synchronized, increasing the process time of whole process.
>
> Is it a normal situation? Is there a way to work totally in parallel process?
>
> I am using the OpenSuse 12.3 Linux with pcsc-lite 1.8.8, and the reader driver is a ccid compatible.

Like Frank Marien, I have an application using pcsc-lite (as bundled with whatever version of Red Hat or Centos 5 or 6)
that extensively use parallel processing on e.g. 8 readers using pcsc-lite; it works like a charm. It is written in C,
not Java. Perhaps you hit some JVM limitation.

  Francois Grieu

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

RES: Parallel Process with readers - pcsc-lite

MURILO COSTA
Hi Frank and Francois

It's really strange, because works fine on windows, and it seems there is no reason to don't work under OpenSuse.
What kind of readers are you using? Serial or USB? Can you give the names?

I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...

Do you think that issue have some relationship with this Ludovic post:
http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html

Thanks

Regards,

Murilo


________________________________________
De: Muscle [[hidden email]] em nome de Francois Grieu [[hidden email]]
Enviado: quarta-feira, 3 de julho de 2013 13:57
Para: MUSCLE
Assunto: Re: [Muscle] Parallel Process with readers - pcsc-lite

On 03/07/2013 17:05, MURILO COSTA wrote:
> I have a Java system (..) looking at some test results, I checked that the time of process on Linux is greater than on Windows, and looks like the reason is because the "parallel" process of windows, that doesn't happen on Linux when two or more readers are used. In Linux the commands are not send at the same time, they are synchronized, increasing the process time of whole process.
>
> Is it a normal situation? Is there a way to work totally in parallel process?
>
> I am using the OpenSuse 12.3 Linux with pcsc-lite 1.8.8, and the reader driver is a ccid compatible.

Like Frank Marien, I have an application using pcsc-lite (as bundled with whatever version of Red Hat or Centos 5 or 6)
that extensively use parallel processing on e.g. 8 readers using pcsc-lite; it works like a charm. It is written in C,
not Java. Perhaps you hit some JVM limitation.

  Francois Grieu

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Bruno Jesus
On Wed, Jul 3, 2013 at 2:15 PM, MURILO COSTA
<[hidden email]> wrote:
> Hi Frank and Francois
>
> It's really strange, because works fine on windows, and it seems there is no reason to don't work under OpenSuse.
> What kind of readers are you using? Serial or USB? Can you give the names?
>
> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
>
> Do you think that issue have some relationship with this Ludovic post:
> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html

If your readers are single-device multi-slot readers then that will
certainly affect them. If the readers are multi-device single-slot
then there should be no problem. A multi-device reader is a reader
that is detected as several different USB devices (sometimes as a HUB
sometimes as USB composite), an example of this reader is the Duali
DE-620.

If the readers are single-slot there shouldn't be any problem.

> Thanks
>
> Regards,
>
> Murilo

Abraços,
Bruno

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Frank Marien

On 07/03/13 19:25, Bruno Jesus wrote:
> On Wed, Jul 3, 2013 at 2:15 PM, MURILO COSTA
> <[hidden email]> wrote:
>> Hi Frank and Francois
>>
>> It's really strange, because works fine on windows, and it seems there is no reason to don't work under OpenSuse.
>> What kind of readers are you using? Serial or USB? Can you give the names?
Mine are all USB, single-slot readers. For example:

Bus 001 Device 003: ID 1a44:0001 VASCO Data Security International
Digipass 905 SmartCard Reader

Bus 004 Device 004: ID 04e6:5119 SCM Microsystems, Inc. SCR3340 -
ExpressCard54 Smart Card Reader

ACS APG8201, etc..




>>
>> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
>>
>> Do you think that issue have some relationship with this Ludovic post:
>> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html
> If your readers are single-device multi-slot readers then that will
> certainly affect them. If the readers are multi-device single-slot
> then there should be no problem. A multi-device reader is a reader
> that is detected as several different USB devices (sometimes as a HUB
> sometimes as USB composite), an example of this reader is the Duali
> DE-620.
>
> If the readers are single-slot there shouldn't be any problem.

so, Murilo, if you do habe such readers, connect one of them and run

$ sudo lsusb -v | grep bMaxCCIDBusySlots

to see what that reader reports..

>
>> Thanks
>>
>> Regards,
>>
>> Murilo
> Abraços,
> Bruno
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Ludovic Rousseau
In reply to this post by MURILO COSTA
2013/7/3 MURILO COSTA <[hidden email]>:
> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...

I guess it is a javax.smartcardio "limitation".

You need to create one context per reader using SCardEstablishContext.
I bet the Java wrapper creates only one context for all the readers.
In pcsc-lite the context is associated to a mutex. So all your
commands will block on the same mutex even if they use different
readers.
I don't know if is it easy or even possible to avoid this Java wrapper
"feature".

> Do you think that issue have some relationship with this Ludovic post:
> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html

No.

Bye

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Michael StJohns-2
At 03:45 PM 7/3/2013, Ludovic Rousseau wrote:

>2013/7/3 MURILO COSTA <[hidden email]>:
>> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
>
>I guess it is a javax.smartcardio "limitation".
>
>You need to create one context per reader using SCardEstablishContext.
>I bet the Java wrapper creates only one context for all the readers.
>In pcsc-lite the context is associated to a mutex. So all your
>commands will block on the same mutex even if they use different
>readers.
>I don't know if is it easy or even possible to avoid this Java wrapper
>"feature".


Probably not - here's the source code from the default provider implementation for JDK7.  It even comments that it uses the same context id for each of these:




final class PCSCTerminals extends CardTerminals {

    // SCARDCONTEXT, currently shared between all threads/terminals
    private static long contextId;

    // terminal state used by waitForCard()
    private Map<String,ReaderState> stateMap;

    PCSCTerminals() {
        // empty
    }

    static synchronized void initContext() throws PCSCException {
        if (contextId == 0) {
            contextId = SCardEstablishContext(SCARD_SCOPE_USER);
        }
    }


One way around this is to grab the source code and build yourself a different provider using the code as a base.

Mike




>> Do you think that issue have some relationship with this Ludovic post:
>> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html
>
>No.
>
>Bye
>
>--
> Dr. Ludovic Rousseau
>
>_______________________________________________
>Muscle mailing list
>[hidden email]
>http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com



_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

RES: RES: Parallel Process with readers - pcsc-lite

MURILO COSTA
In reply to this post by Ludovic Rousseau
Hello,

$ lsusb
Bus 002 Device 031: ID 046a:002d Cherry GmbH SmartTerminal XX44
Bus 002 Device 003: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications....

$ lsusb -v | grep bMaxCCIDBusySlots
        bMaxCCIDBusySlots        1
        bMaxCCIDBusySlots        1

Look like the readers are not the problem, anyway I'm testing it with pcsc-tools

About the possible Java limitation, I'll take a look, the code of Frank maybe can help

Regards,

Murilo

________________________________________
De: Muscle [[hidden email]] em nome de Ludovic Rousseau [[hidden email]]
Enviado: quarta-feira, 3 de julho de 2013 16:45
Para: MUSCLE
Assunto: Re: [Muscle] RES: Parallel Process with readers - pcsc-lite

2013/7/3 MURILO COSTA <[hidden email]>:
> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...

I guess it is a javax.smartcardio "limitation".

You need to create one context per reader using SCardEstablishContext.
I bet the Java wrapper creates only one context for all the readers.
In pcsc-lite the context is associated to a mutex. So all your
commands will block on the same mutex even if they use different
readers.
I don't know if is it easy or even possible to avoid this Java wrapper
"feature".

> Do you think that issue have some relationship with this Ludovic post:
> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html

No.

Bye

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Frank Marien
In reply to this post by Ludovic Rousseau
So my parallellism works because the chips are all so slow one can transmit
while the others are still figuring out the next APDU? Fascinating, I'll
try and
do a timing diagram on that.


On 07/03/13 21:45, Ludovic Rousseau wrote:

> 2013/7/3 MURILO COSTA <[hidden email]>:
>> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
> I guess it is a javax.smartcardio "limitation".
>
> You need to create one context per reader using SCardEstablishContext.
> I bet the Java wrapper creates only one context for all the readers.
> In pcsc-lite the context is associated to a mutex. So all your
> commands will block on the same mutex even if they use different
> readers.
> I don't know if is it easy or even possible to avoid this Java wrapper
> "feature".
>
>> Do you think that issue have some relationship with this Ludovic post:
>> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html
> No.
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Sebastien Lorquet
In reply to this post by Ludovic Rousseau
Le 03/07/2013 21:45, Ludovic Rousseau a écrit :

> 2013/7/3 MURILO COSTA <[hidden email]>:
>> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
> I guess it is a javax.smartcardio "limitation".
>
> You need to create one context per reader using SCardEstablishContext.
> I bet the Java wrapper creates only one context for all the readers.
> In pcsc-lite the context is associated to a mutex. So all your
> commands will block on the same mutex even if they use different
> readers.
> I don't know if is it easy or even possible to avoid this Java wrapper
> "feature".
Hello

One possible method would be to use JNA to talk directly to
libpcsclite.so (or winscard.dll on windows)
This would allow you to use the pcsclite C API from java.

Best regards
Sebastien

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Frank Marien
In reply to this post by Ludovic Rousseau

On 07/03/13 22:02, Michael StJohns wrote:

> At 03:45 PM 7/3/2013, Ludovic Rousseau wrote:
>> 2013/7/3 MURILO COSTA <[hidden email]>:
>>> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
>> I guess it is a javax.smartcardio "limitation".
>>
>> You need to create one context per reader using SCardEstablishContext.
>> I bet the Java wrapper creates only one context for all the readers.
>> In pcsc-lite the context is associated to a mutex. So all your
>> commands will block on the same mutex even if they use different
>> readers.
>> I don't know if is it easy or even possible to avoid this Java wrapper
>> "feature".
>
> Probably not - here's the source code from the default provider implementation for JDK7.  It even comments that it uses the same context id for each of these:
>
>
>
>
> final class PCSCTerminals extends CardTerminals {
>
>     // SCARDCONTEXT, currently shared between all threads/terminals
>     private static long contextId;
>
>     // terminal state used by waitForCard()
>     private Map<String,ReaderState> stateMap;
>
>     PCSCTerminals() {
>         // empty
>     }
>
>     static synchronized void initContext() throws PCSCException {
>         if (contextId == 0) {
>             contextId = SCardEstablishContext(SCARD_SCOPE_USER);
>         }
>     }
>
>
> One way around this is to grab the source code and build yourself a different provider using the code as a base.
I'm looking at doing exactly that to solve a different problem.. not
entirely sure that I'll end up implementing the full javax.smartcardio,
though. Probably only CardTerminal and Card, inside the current
commons-eid API.
I guess that would allow me to implement that will separate contexts.
Looking at the JRE8 sources for that.

Still.. I think we're missing something, here. If it's inherent in
libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from
the sources above), then why I can I read 5 photos from 5 eID's in the
same required to read one, and also, why would Murilo *not* have the
issue on Windows? Different implementation there?

-f

>
> Mike
>
>
>
>
>>> Do you think that issue have some relationship with this Ludovic post:
>>> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html
>> No.
>>
>> Bye
>>
>> --
>> Dr. Ludovic Rousseau
>>
>> _______________________________________________
>> Muscle mailing list
>> [hidden email]
>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: RES: Parallel Process with readers - pcsc-lite

Frank Marien
In reply to this post by MURILO COSTA

On 07/03/13 22:19, MURILO COSTA wrote:

> Hello,
>
> $ lsusb
> Bus 002 Device 031: ID 046a:002d Cherry GmbH SmartTerminal XX44
> Bus 002 Device 003: ID 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications....
>
> $ lsusb -v | grep bMaxCCIDBusySlots
>         bMaxCCIDBusySlots        1
>         bMaxCCIDBusySlots        1
>
> Look like the readers are not the problem, anyway I'm testing it with pcsc-tools
>
> About the possible Java limitation, I'll take a look, the code of Frank maybe can help
If you want to use commons-eid, there is a low-level class

https://code.google.com/p/commons-eid/source/browse/commons-eid-client/src/main/java/be/fedict/commons/eid/client/CardAndTerminalManager.java

instantiate, addCardListener, start()

your card listener will get called for all cards present. Do something
with the Card object that the callback gives you, in a new thread,
something lenghty.. all of these should be parallel.

after you get cardEventsInitialized, you'll get only removals and
inserts. One way to go is to insert one card, time it, then insert 2 at
a time, time it, etc.. I have found that this hardly takes more time..
even though it looks like it can't  work in theory.. We'll get to the
bottom of this.

Example on using CardAndTerminalManager:

https://code.google.com/p/commons-eid/source/browse/commons-eid-tests/src/main/java/be/fedict/commons/eid/examples/events/MixedDetectionExamples.java




>
> Regards,
>
> Murilo
>
> ________________________________________
> De: Muscle [[hidden email]] em nome de Ludovic Rousseau [[hidden email]]
> Enviado: quarta-feira, 3 de julho de 2013 16:45
> Para: MUSCLE
> Assunto: Re: [Muscle] RES: Parallel Process with readers - pcsc-lite
>
> 2013/7/3 MURILO COSTA <[hidden email]>:
>> I thought that maybe can be a Java problem, do you know some software to do this kind of test (parallelism) ? I'll check if pcsc-tools can do that...
> I guess it is a javax.smartcardio "limitation".
>
> You need to create one context per reader using SCardEstablishContext.
> I bet the Java wrapper creates only one context for all the readers.
> In pcsc-lite the context is associated to a mutex. So all your
> commands will block on the same mutex even if they use different
> readers.
> I don't know if is it easy or even possible to avoid this Java wrapper
> "feature".
>
>> Do you think that issue have some relationship with this Ludovic post:
>> http://ludovicrousseau.blogspot.com.br/2013/06/ccid-descriptor-statistics_7148.html
> No.
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Frank Marien
In reply to this post by Sebastien Lorquet

On 07/04/13 00:06, Sébastien Lorquet wrote:

> Le 03/07/2013 21:45, Ludovic Rousseau a écrit :
>> 2013/7/3 MURILO COSTA <[hidden email]>:
>>> I thought that maybe can be a Java problem, do you know some
>>> software to do this kind of test (parallelism) ? I'll check if
>>> pcsc-tools can do that...
>> I guess it is a javax.smartcardio "limitation".
>>
>> You need to create one context per reader using SCardEstablishContext.
>> I bet the Java wrapper creates only one context for all the readers.
>> In pcsc-lite the context is associated to a mutex. So all your
>> commands will block on the same mutex even if they use different
>> readers.
>> I don't know if is it easy or even possible to avoid this Java wrapper
>> "feature".
> Hello
>
> One possible method would be to use JNA to talk directly to
> libpcsclite.so (or winscard.dll on windows)
> This would allow you to use the pcsclite C API from java.

Yes, this is what I'm planning to do.. Have a POC for this, using some
helper tools to build the wrapper,
if appears to work, so I can use SCard.. methods from Java, but it looks
and feels pretty nasty as compared to
just using javax.smartcardio which uses libjpcsc which is also
built-in.. I also imagine it won't be trivial to get right,
e.g. with regards to object/connection lifecycle and Java Threads. I'm
mitigating this in our case by only
implementing privately for own use cases, and not to conform to
javax.smartcardio entirely. Still
it's probably more effort than one thinks. My idea is to create a
different backend for commons-eid::CardAndTerminalManager
based on that wrapper, and implement only Card and CardTerminal "by the
book", everything else low-level via the wrapper.

Since it's all GPLled, happy to collaborate :-)

>
> Best regards
> Sebastien
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Ludovic Rousseau
In reply to this post by Frank Marien
2013/7/4 Frank Marien <[hidden email]>:
> Still.. I think we're missing something, here. If it's inherent in
> libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from
> the sources above), then why I can I read 5 photos from 5 eID's in the
> same required to read one, and also, why would Murilo *not* have the
> issue on Windows? Different implementation there?

The Microsoft WinSCard API implementation is different from pcsc-lite
and so has different "limitations".
So yes, the Windows and Unix implementations are different.

Bye

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Frank Marien
Sure, Ludovic,

I understand, the windows implementation may not have that mutex at that
same granularity, so the naive Java single-shared-context strategy may
have less
of an impact on that platform.

What I'm curious about is why I'm *not* noticing any such difference,
this while
I'm developing on GNU/Linux (pcsc-lite), but we're routinely testing on
both OSX (fork of pcsc-lite)
*and* Windows (closed-source proprietary implementation), and Murilo
*does* notice such an impact.

We're both testing on both Linux and Windows..
I'm looking for the cause of the difference between these experiences.

But I suggest both Murilo and I do a timing diagram (see if there is
overlap in the timing of the transfers) of our experiments, and then get
back here with the results, because otherwise we're just discussing
perception and that may be deceiving, not to mention getting more
off-topic than strictly necessary.

I think it's interesting because of my impression that I *am* getting
parallellism with pcsc-lite, from java,
while, after reading the previous explanations, that shouldn't really be
possible.

-f

On 07/04/13 09:33, Ludovic Rousseau wrote:

> 2013/7/4 Frank Marien <[hidden email]>:
>> Still.. I think we're missing something, here. If it's inherent in
>> libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from
>> the sources above), then why I can I read 5 photos from 5 eID's in the
>> same required to read one, and also, why would Murilo *not* have the
>> issue on Windows? Different implementation there?
> The Microsoft WinSCard API implementation is different from pcsc-lite
> and so has different "limitations".
> So yes, the Windows and Unix implementations are different.
>
> Bye
>
> --
>  Dr. Ludovic Rousseau
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: Parallel Process with readers - pcsc-lite

Frank Marien
Right,

Parallellization test, Java SE 1.6, Arch Linux,

pcsc-lite version 1.8.8.
Enabled features: Linux x86_64-unknown-linux-gnu serial usb libudev
usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd
configdir=/etc/reader.conf.d

one reader:

689 0 0
1043 0 255
1167 0 510
1291 0 765
1414 0 1020
1538 0 1275
1662 0 1530
1786 0 1785
2160 0 2040
2284 0 2295
2407 0 2550
2529 0 2629
Total for 0=2786ms

two readers:

540 0 0
984 1 0
1088 0 255
1213 1 255
1338 1 510
1462 0 510
1586 0 765
1710 1 765
1835 1 1020
1959 0 1020
2334 1 1275
2458 0 1275
2582 0 1530
2707 1 1530
2832 1 1785
2956 0 1785
3079 0 2040
3204 1 2040
3578 0 2295
3703 1 2295
3828 1 2550
3952 0 2550
4131 1 2629
4200 0 2629
Total for 0=4208ms
Total for 1=3676ms

three readers:

564 0 0
651 2 0
753 1 0
857 2 255
982 0 255
1097 1 255
1221 2 510
1346 0 510
1461 1 510
1585 2 765
1710 0 765
1825 1 765
1949 2 1020
2074 0 1020
2189 1 1020
2313 2 1275
2437 0 1275
2561 2 1530
2686 0 1530
2802 1 1275
3176 2 1785
3301 0 1785
3416 1 1530
3541 0 2040
3664 2 2040
3780 1 1785
3904 2 2295
4019 1 2040
4144 0 2295
4267 2 2550
4383 1 2295
4508 0 2550
4630 2 2629
4745 1 2550
4871 0 2629
Total for 0=4873ms
4984 1 2629
Total for 2=4792ms
Total for 1=5047ms

So, the time required to read that 2629-byte file from these cards does
increase with the number of readers you're doing this on in parallel.
Consistent: Java uses one context and pcsc-lite has a Mutex per context.

On windows, this appears not to be the case, indeed. time to read that
file is avg 2.8 seconds and stays 2.8 seconds with two or three readers.

For my "pick a card" dialog, the slowdown is acceptable and I had never
noticed it. (It still takes only 5 seconds to read 3 photos, not the 9
seconds it takes if I read them one after the other),
so it's not really serial in practice: the cards aren't spending all
their time sending data, in any case. It's not a full pipe, each block
is an APDU and APDU Response cycle, and that may account for the
mitigation of the fenomenon here.

Still, Murilo, if you want to read all those cards at once efficiently,
I'm afraid you won't be able to count on the JRE's default PCSC wrapper
and javax.smartcardio..

So the next question is obvious: do you require the Provider features of
javax.smartcardio, or do you just need to access smart cards and do
private stuff with them directly?) (since the former would be much more
work to implement).

WKR,
-f




On 07/04/13 10:54, Frank Marien wrote:

> Sure, Ludovic,
>
> I understand, the windows implementation may not have that mutex at that
> same granularity, so the naive Java single-shared-context strategy may
> have less
> of an impact on that platform.
>
> What I'm curious about is why I'm *not* noticing any such difference,
> this while
> I'm developing on GNU/Linux (pcsc-lite), but we're routinely testing on
> both OSX (fork of pcsc-lite)
> *and* Windows (closed-source proprietary implementation), and Murilo
> *does* notice such an impact.
>
> We're both testing on both Linux and Windows..
> I'm looking for the cause of the difference between these experiences.
>
> But I suggest both Murilo and I do a timing diagram (see if there is
> overlap in the timing of the transfers) of our experiments, and then get
> back here with the results, because otherwise we're just discussing
> perception and that may be deceiving, not to mention getting more
> off-topic than strictly necessary.
>
> I think it's interesting because of my impression that I *am* getting
> parallellism with pcsc-lite, from java,
> while, after reading the previous explanations, that shouldn't really be
> possible.
>
> -f
>
> On 07/04/13 09:33, Ludovic Rousseau wrote:
>> 2013/7/4 Frank Marien <[hidden email]>:
>>> Still.. I think we're missing something, here. If it's inherent in
>>> libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from
>>> the sources above), then why I can I read 5 photos from 5 eID's in the
>>> same required to read one, and also, why would Murilo *not* have the
>>> issue on Windows? Different implementation there?
>> The Microsoft WinSCard API implementation is different from pcsc-lite
>> and so has different "limitations".
>> So yes, the Windows and Unix implementations are different.
>>
>> Bye
>>
>> --
>>  Dr. Ludovic Rousseau
>>
>> _______________________________________________
>> Muscle mailing list
>> [hidden email]
>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>>
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

RES: RES: Parallel Process with readers - pcsc-lite

MURILO COSTA
Hello,

I have the the same results as you Frank, the process time always increase for each reader, and is a JRE problem, because I made some tests using the "scriptor" of pcsc-tools with two and three readers in different threads , and the execution time was identical of just one reader.

In my case, I just need to stablish a connection to smart cards in one or more readers and send commands to them, this is very practical, easy and fast with javax.smartcardio, but this non-parallelism become a real problem for me, I really need it. What would you suggest? Do you think rewrite the provider is a good option? It will be very low-level for me, I'm not so used to it hehe

My system is all Java based, then will become a little hard to rebuild it to another language, but is a possibility...

Just a curiosity, this happen on Apple OS too?

Thanks for all the help.

Regards

Murilo


________________________________________
De: Muscle [[hidden email]] em nome de Frank Marien [[hidden email]]
Enviado: quinta-feira, 4 de julho de 2013 11:48
Para: [hidden email]
Assunto: Re: [Muscle] RES: Parallel Process with readers - pcsc-lite

Right,

Parallellization test, Java SE 1.6, Arch Linux,

pcsc-lite version 1.8.8.
Enabled features: Linux x86_64-unknown-linux-gnu serial usb libudev
usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd
configdir=/etc/reader.conf.d

one reader:

689 0 0
1043 0 255
1167 0 510
1291 0 765
1414 0 1020
1538 0 1275
1662 0 1530
1786 0 1785
2160 0 2040
2284 0 2295
2407 0 2550
2529 0 2629
Total for 0=2786ms

two readers:

540 0 0
984 1 0
1088 0 255
1213 1 255
1338 1 510
1462 0 510
1586 0 765
1710 1 765
1835 1 1020
1959 0 1020
2334 1 1275
2458 0 1275
2582 0 1530
2707 1 1530
2832 1 1785
2956 0 1785
3079 0 2040
3204 1 2040
3578 0 2295
3703 1 2295
3828 1 2550
3952 0 2550
4131 1 2629
4200 0 2629
Total for 0=4208ms
Total for 1=3676ms

three readers:

564 0 0
651 2 0
753 1 0
857 2 255
982 0 255
1097 1 255
1221 2 510
1346 0 510
1461 1 510
1585 2 765
1710 0 765
1825 1 765
1949 2 1020
2074 0 1020
2189 1 1020
2313 2 1275
2437 0 1275
2561 2 1530
2686 0 1530
2802 1 1275
3176 2 1785
3301 0 1785
3416 1 1530
3541 0 2040
3664 2 2040
3780 1 1785
3904 2 2295
4019 1 2040
4144 0 2295
4267 2 2550
4383 1 2295
4508 0 2550
4630 2 2629
4745 1 2550
4871 0 2629
Total for 0=4873ms
4984 1 2629
Total for 2=4792ms
Total for 1=5047ms

So, the time required to read that 2629-byte file from these cards does
increase with the number of readers you're doing this on in parallel.
Consistent: Java uses one context and pcsc-lite has a Mutex per context.

On windows, this appears not to be the case, indeed. time to read that
file is avg 2.8 seconds and stays 2.8 seconds with two or three readers.

For my "pick a card" dialog, the slowdown is acceptable and I had never
noticed it. (It still takes only 5 seconds to read 3 photos, not the 9
seconds it takes if I read them one after the other),
so it's not really serial in practice: the cards aren't spending all
their time sending data, in any case. It's not a full pipe, each block
is an APDU and APDU Response cycle, and that may account for the
mitigation of the fenomenon here.

Still, Murilo, if you want to read all those cards at once efficiently,
I'm afraid you won't be able to count on the JRE's default PCSC wrapper
and javax.smartcardio..

So the next question is obvious: do you require the Provider features of
javax.smartcardio, or do you just need to access smart cards and do
private stuff with them directly?) (since the former would be much more
work to implement).

WKR,
-f




On 07/04/13 10:54, Frank Marien wrote:

> Sure, Ludovic,
>
> I understand, the windows implementation may not have that mutex at that
> same granularity, so the naive Java single-shared-context strategy may
> have less
> of an impact on that platform.
>
> What I'm curious about is why I'm *not* noticing any such difference,
> this while
> I'm developing on GNU/Linux (pcsc-lite), but we're routinely testing on
> both OSX (fork of pcsc-lite)
> *and* Windows (closed-source proprietary implementation), and Murilo
> *does* notice such an impact.
>
> We're both testing on both Linux and Windows..
> I'm looking for the cause of the difference between these experiences.
>
> But I suggest both Murilo and I do a timing diagram (see if there is
> overlap in the timing of the transfers) of our experiments, and then get
> back here with the results, because otherwise we're just discussing
> perception and that may be deceiving, not to mention getting more
> off-topic than strictly necessary.
>
> I think it's interesting because of my impression that I *am* getting
> parallellism with pcsc-lite, from java,
> while, after reading the previous explanations, that shouldn't really be
> possible.
>
> -f
>
> On 07/04/13 09:33, Ludovic Rousseau wrote:
>> 2013/7/4 Frank Marien <[hidden email]>:
>>> Still.. I think we're missing something, here. If it's inherent in
>>> libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from
>>> the sources above), then why I can I read 5 photos from 5 eID's in the
>>> same required to read one, and also, why would Murilo *not* have the
>>> issue on Windows? Different implementation there?
>> The Microsoft WinSCard API implementation is different from pcsc-lite
>> and so has different "limitations".
>> So yes, the Windows and Unix implementations are different.
>>
>> Bye
>>
>> --
>>  Dr. Ludovic Rousseau
>>
>> _______________________________________________
>> Muscle mailing list
>> [hidden email]
>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>>
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com



_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: RES: Parallel Process with readers - pcsc-lite

Frank Marien

On 07/04/13 19:18, MURILO COSTA wrote:
> Hello,
>
> I have the the same results as you Frank, the process time always increase for each reader, and is a JRE problem, because I made some tests using the "scriptor" of pcsc-tools with two and three readers in different threads , and the execution time was identical of just one reader.
Yes, there is nothing more going on than that single context created by
the javax.smartcardio implementation.
>
> In my case, I just need to stablish a connection to smart cards in one or more readers and send commands to them, this is very practical, easy and fast with javax.smartcardio, but this non-parallelism become a real problem for me, I really need it. What would you suggest? Do you think rewrite the provider is a good option? It will be very low-level for me, I'm not so used to it hehe
Well, I am, although I spend far too much time writing pure Java and
Python these days, I try and keep my C/C++ skills dusted off.
Although at some point it becomes necessary to wrap the PCSC C calls
with Java, and that used to be a major PITA and great source
of problems with JNI, I'm experimenting with JNA and BridJ and, although
admittedly wrappers still look convulted, at least it feels like
it's going to work and not give intermittent low-level errors and
crashes, something that was easy to do with JNI.

That being said, I need to do this myself, because of that pesky bitness
bug in OSX JRE's that makes PCSC calls crash the JVM
on 64-bit systems.. But if you don't have to run on OSX, you could use
the existing libj2pcsc wrapper that is in the standard JRE distributions,
just write a new set of classes around that, all Java from there.

the wrapper looks like nothing more than that: a JNI wrapper around some
native C methods:

[frank@hiram ~]$ objdump --syms /opt/jre1.7.0_07/lib/i386/libj2pcsc.so |
grep smartcardio
00000d40 g     F .text  00000117            
Java_sun_security_smartcardio_PCSC_SCardTransmit
00001060 g     F .text  00000116            
Java_sun_security_smartcardio_PCSC_SCardControl
00001020 g     F .text  0000003c            
Java_sun_security_smartcardio_PCSC_SCardEndTransaction
00000fe0 g     F .text  00000035            
Java_sun_security_smartcardio_PCSC_SCardBeginTransaction
00000c10 g     F .text  00000062            
Java_sun_security_smartcardio_PCSC_SCardEstablishContext
00000fa0 g     F .text  0000003c            
Java_sun_security_smartcardio_PCSC_SCardDisconnect
00000c80 g     F .text  000000b5            
Java_sun_security_smartcardio_PCSC_SCardConnect
00001690 g     F .text  00000209            
Java_sun_security_smartcardio_PlatformPCSC_initialize
00001520 g     F .text  000000e5            
Java_sun_security_smartcardio_PCSC_SCardListReaders
00000e60 g     F .text  00000132            
Java_sun_security_smartcardio_PCSC_SCardStatus
00001180 g     F .text  0000024a            
Java_sun_security_smartcardio_PCSC_SCardGetStatusChange

so it should be possible to just loadLibrary("j2pcsc") to be able to
access the SCardXXXX methods from Java.
But the hard part is to get the argument types right. There are no
pointers in Java..

This is what a BirdJ wrapper looks like:

@Library("pcsclite")
@Runtime(CRuntime.class)
public class SCard {

    static {
        BridJ.register();
    }

[...]

@CLong
    native public static long SCardEstablishContext(int dwScope, Pointer
pvReserved1, Pointer pvReserved2, Pointer<Long> phContext);
    /**
     * Original signature : <code>long
SCardReleaseContext(SCARDCONTEXT)</code><br>
     * <i>native declaration : /usr/include/pcsclite.h:234</i>
     */

It uses these special Pointer etc.. types.. I will attempt to wrap those
again to end up with all the native stuff in separate classes whose
interface
is pure Java. Want to properly encapsulate that.


>
> My system is all Java based, then will become a little hard to rebuild it to another language, but is a possibility...
Well.. you won't hear me telling you not to .. I think the language (if
chosen properly) accounts for only
10% of the result. the other 90% are with the developer :-)

>
> Just a curiosity, this happen on Apple OS too?
haven't ran that particular test, but the pcsc deamon in
SmartCardServices is a fork of the one on pcsc-lite,
and the JRE implementation is the same, so, should be the same there.

>
> Thanks for all the help.
>
> Regards
>
> Murilo
>
>
> ________________________________________
> De: Muscle [[hidden email]] em nome de Frank Marien [[hidden email]]
> Enviado: quinta-feira, 4 de julho de 2013 11:48
> Para: [hidden email]
> Assunto: Re: [Muscle] RES: Parallel Process with readers - pcsc-lite
>
> Right,
>
> Parallellization test, Java SE 1.6, Arch Linux,
>
> pcsc-lite version 1.8.8.
> Enabled features: Linux x86_64-unknown-linux-gnu serial usb libudev
> usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd
> configdir=/etc/reader.conf.d
>
> one reader:
>
> 689 0 0
> 1043 0 255
> 1167 0 510
> 1291 0 765
> 1414 0 1020
> 1538 0 1275
> 1662 0 1530
> 1786 0 1785
> 2160 0 2040
> 2284 0 2295
> 2407 0 2550
> 2529 0 2629
> Total for 0=2786ms
>
> two readers:
>
> 540 0 0
> 984 1 0
> 1088 0 255
> 1213 1 255
> 1338 1 510
> 1462 0 510
> 1586 0 765
> 1710 1 765
> 1835 1 1020
> 1959 0 1020
> 2334 1 1275
> 2458 0 1275
> 2582 0 1530
> 2707 1 1530
> 2832 1 1785
> 2956 0 1785
> 3079 0 2040
> 3204 1 2040
> 3578 0 2295
> 3703 1 2295
> 3828 1 2550
> 3952 0 2550
> 4131 1 2629
> 4200 0 2629
> Total for 0=4208ms
> Total for 1=3676ms
>
> three readers:
>
> 564 0 0
> 651 2 0
> 753 1 0
> 857 2 255
> 982 0 255
> 1097 1 255
> 1221 2 510
> 1346 0 510
> 1461 1 510
> 1585 2 765
> 1710 0 765
> 1825 1 765
> 1949 2 1020
> 2074 0 1020
> 2189 1 1020
> 2313 2 1275
> 2437 0 1275
> 2561 2 1530
> 2686 0 1530
> 2802 1 1275
> 3176 2 1785
> 3301 0 1785
> 3416 1 1530
> 3541 0 2040
> 3664 2 2040
> 3780 1 1785
> 3904 2 2295
> 4019 1 2040
> 4144 0 2295
> 4267 2 2550
> 4383 1 2295
> 4508 0 2550
> 4630 2 2629
> 4745 1 2550
> 4871 0 2629
> Total for 0=4873ms
> 4984 1 2629
> Total for 2=4792ms
> Total for 1=5047ms
>
> So, the time required to read that 2629-byte file from these cards does
> increase with the number of readers you're doing this on in parallel.
> Consistent: Java uses one context and pcsc-lite has a Mutex per context.
>
> On windows, this appears not to be the case, indeed. time to read that
> file is avg 2.8 seconds and stays 2.8 seconds with two or three readers.
>
> For my "pick a card" dialog, the slowdown is acceptable and I had never
> noticed it. (It still takes only 5 seconds to read 3 photos, not the 9
> seconds it takes if I read them one after the other),
> so it's not really serial in practice: the cards aren't spending all
> their time sending data, in any case. It's not a full pipe, each block
> is an APDU and APDU Response cycle, and that may account for the
> mitigation of the fenomenon here.
>
> Still, Murilo, if you want to read all those cards at once efficiently,
> I'm afraid you won't be able to count on the JRE's default PCSC wrapper
> and javax.smartcardio..
>
> So the next question is obvious: do you require the Provider features of
> javax.smartcardio, or do you just need to access smart cards and do
> private stuff with them directly?) (since the former would be much more
> work to implement).
>
> WKR,
> -f
>
>
>
>
> On 07/04/13 10:54, Frank Marien wrote:
>> Sure, Ludovic,
>>
>> I understand, the windows implementation may not have that mutex at that
>> same granularity, so the naive Java single-shared-context strategy may
>> have less
>> of an impact on that platform.
>>
>> What I'm curious about is why I'm *not* noticing any such difference,
>> this while
>> I'm developing on GNU/Linux (pcsc-lite), but we're routinely testing on
>> both OSX (fork of pcsc-lite)
>> *and* Windows (closed-source proprietary implementation), and Murilo
>> *does* notice such an impact.
>>
>> We're both testing on both Linux and Windows..
>> I'm looking for the cause of the difference between these experiences.
>>
>> But I suggest both Murilo and I do a timing diagram (see if there is
>> overlap in the timing of the transfers) of our experiments, and then get
>> back here with the results, because otherwise we're just discussing
>> perception and that may be deceiving, not to mention getting more
>> off-topic than strictly necessary.
>>
>> I think it's interesting because of my impression that I *am* getting
>> parallellism with pcsc-lite, from java,
>> while, after reading the previous explanations, that shouldn't really be
>> possible.
>>
>> -f
>>
>> On 07/04/13 09:33, Ludovic Rousseau wrote:
>>> 2013/7/4 Frank Marien <[hidden email]>:
>>>> Still.. I think we're missing something, here. If it's inherent in
>>>> libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from
>>>> the sources above), then why I can I read 5 photos from 5 eID's in the
>>>> same required to read one, and also, why would Murilo *not* have the
>>>> issue on Windows? Different implementation there?
>>> The Microsoft WinSCard API implementation is different from pcsc-lite
>>> and so has different "limitations".
>>> So yes, the Windows and Unix implementations are different.
>>>
>>> Bye
>>>
>>> --
>>>  Dr. Ludovic Rousseau
>>>
>>> _______________________________________________
>>> Muscle mailing list
>>> [hidden email]
>>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>>>
>> _______________________________________________
>> Muscle mailing list
>> [hidden email]
>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>>
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>
>
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
Reply | Threaded
Open this post in threaded view
|

Re: RES: RES: Parallel Process with readers - pcsc-lite

Michael Traut
In reply to this post by MURILO COSTA
We already have a platform independent native adapter to pcsc and pcsc-lite. We developed this before smartcardio popped up and never switched because of the limitations of smartcardio - it is used in our (closed-source) EAL certified signature application.

We'd like to donate this lib if anybody is interested...

The runtime stack consists of

- JNA runtime
- intarsys native memory model (as we dislike the JNA abstractions...). This is already BSD licensed (via jPod on SourceForge)
- intarsys PCSC wrapper (including all SCARD features WE needed so far)
- intarsys Card abstraction. A small layer on top of PCSC, with some features we found very useful in the years.

The pro is without doubt that we use this for years, fixed small "bugs" with every version of win*, 32 and 64 bit, Mac and Unix derivates, for every card reader explicitly supported and poorly programmed by the provider... There have been so many incompatibilities to work around we simply can't list...

For some, the downside may be that we do NOT plug in smartcardio and have different abstraction for terminal/card/connection. The "card" abstraction (while not required, but really recommended) is quite strict and on the exact opposite of smartcardio. Every card terminal and every card connection comes with its own context...

If appropriate, make some suggestions on where to host the lib....



On Thu, Jul 4, 2013 at 7:18 PM, MURILO COSTA <[hidden email]> wrote:
Hello,

I have the the same results as you Frank, the process time always increase for each reader, and is a JRE problem, because I made some tests using the "scriptor" of pcsc-tools with two and three readers in different threads , and the execution time was identical of just one reader.

In my case, I just need to stablish a connection to smart cards in one or more readers and send commands to them, this is very practical, easy and fast with javax.smartcardio, but this non-parallelism become a real problem for me, I really need it. What would you suggest? Do you think rewrite the provider is a good option? It will be very low-level for me, I'm not so used to it hehe

My system is all Java based, then will become a little hard to rebuild it to another language, but is a possibility...

Just a curiosity, this happen on Apple OS too?

Thanks for all the help.

Regards

Murilo


________________________________________
De: Muscle [[hidden email]] em nome de Frank Marien [[hidden email]]
Enviado: quinta-feira, 4 de julho de 2013 11:48
Para: [hidden email]
Assunto: Re: [Muscle] RES: Parallel Process with readers - pcsc-lite

Right,

Parallellization test, Java SE 1.6, Arch Linux,

pcsc-lite version 1.8.8.
Enabled features: Linux x86_64-unknown-linux-gnu serial usb libudev
usbdropdir=/usr/lib/pcsc/drivers ipcdir=/run/pcscd
configdir=/etc/reader.conf.d

one reader:

689 0 0
1043 0 255
1167 0 510
1291 0 765
1414 0 1020
1538 0 1275
1662 0 1530
1786 0 1785
2160 0 2040
2284 0 2295
2407 0 2550
2529 0 2629
Total for 0=2786ms

two readers:

540 0 0
984 1 0
1088 0 255
1213 1 255
1338 1 510
1462 0 510
1586 0 765
1710 1 765
1835 1 1020
1959 0 1020
2334 1 1275
2458 0 1275
2582 0 1530
2707 1 1530
2832 1 1785
2956 0 1785
3079 0 2040
3204 1 2040
3578 0 2295
3703 1 2295
3828 1 2550
3952 0 2550
4131 1 2629
4200 0 2629
Total for 0=4208ms
Total for 1=3676ms

three readers:

564 0 0
651 2 0
753 1 0
857 2 255
982 0 255
1097 1 255
1221 2 510
1346 0 510
1461 1 510
1585 2 765
1710 0 765
1825 1 765
1949 2 1020
2074 0 1020
2189 1 1020
2313 2 1275
2437 0 1275
2561 2 1530
2686 0 1530
2802 1 1275
3176 2 1785
3301 0 1785
3416 1 1530
3541 0 2040
3664 2 2040
3780 1 1785
3904 2 2295
4019 1 2040
4144 0 2295
4267 2 2550
4383 1 2295
4508 0 2550
4630 2 2629
4745 1 2550
4871 0 2629
Total for 0=4873ms
4984 1 2629
Total for 2=4792ms
Total for 1=5047ms

So, the time required to read that 2629-byte file from these cards does
increase with the number of readers you're doing this on in parallel.
Consistent: Java uses one context and pcsc-lite has a Mutex per context.

On windows, this appears not to be the case, indeed. time to read that
file is avg 2.8 seconds and stays 2.8 seconds with two or three readers.

For my "pick a card" dialog, the slowdown is acceptable and I had never
noticed it. (It still takes only 5 seconds to read 3 photos, not the 9
seconds it takes if I read them one after the other),
so it's not really serial in practice: the cards aren't spending all
their time sending data, in any case. It's not a full pipe, each block
is an APDU and APDU Response cycle, and that may account for the
mitigation of the fenomenon here.

Still, Murilo, if you want to read all those cards at once efficiently,
I'm afraid you won't be able to count on the JRE's default PCSC wrapper
and javax.smartcardio..

So the next question is obvious: do you require the Provider features of
javax.smartcardio, or do you just need to access smart cards and do
private stuff with them directly?) (since the former would be much more
work to implement).

WKR,
-f




On 07/04/13 10:54, Frank Marien wrote:
> Sure, Ludovic,
>
> I understand, the windows implementation may not have that mutex at that
> same granularity, so the naive Java single-shared-context strategy may
> have less
> of an impact on that platform.
>
> What I'm curious about is why I'm *not* noticing any such difference,
> this while
> I'm developing on GNU/Linux (pcsc-lite), but we're routinely testing on
> both OSX (fork of pcsc-lite)
> *and* Windows (closed-source proprietary implementation), and Murilo
> *does* notice such an impact.
>
> We're both testing on both Linux and Windows..
> I'm looking for the cause of the difference between these experiences.
>
> But I suggest both Murilo and I do a timing diagram (see if there is
> overlap in the timing of the transfers) of our experiments, and then get
> back here with the results, because otherwise we're just discussing
> perception and that may be deceiving, not to mention getting more
> off-topic than strictly necessary.
>
> I think it's interesting because of my impression that I *am* getting
> parallellism with pcsc-lite, from java,
> while, after reading the previous explanations, that shouldn't really be
> possible.
>
> -f
>
> On 07/04/13 09:33, Ludovic Rousseau wrote:
>> 2013/7/4 Frank Marien <[hidden email]>:
>>> Still.. I think we're missing something, here. If it's inherent in
>>> libj2pcsc (java wrapper) or javax.smartcardio (and it looks like it from
>>> the sources above), then why I can I read 5 photos from 5 eID's in the
>>> same required to read one, and also, why would Murilo *not* have the
>>> issue on Windows? Different implementation there?
>> The Microsoft WinSCard API implementation is different from pcsc-lite
>> and so has different "limitations".
>> So yes, the Windows and Unix implementations are different.
>>
>> Bye
>>
>> --
>>  Dr. Ludovic Rousseau
>>
>> _______________________________________________
>> Muscle mailing list
>> [hidden email]
>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>>
>
> _______________________________________________
> Muscle mailing list
> [hidden email]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com



_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com


_______________________________________________
Muscle mailing list
[hidden email]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
12