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 [[email protected]] em nome de Frank Marien
> [[email protected]]
> Enviado: quinta-feira, 4 de julho de 2013 11:48
> Para: [email protected]
> 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 <[email protected]>:
>>>> 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
>>> [email protected]
>>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>>>
>> _______________________________________________
>> Muscle mailing list
>> [email protected]
>> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>>
>
> _______________________________________________
> Muscle mailing list
> [email protected]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>
>
>
> _______________________________________________
> Muscle mailing list
> [email protected]
> http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
>
_______________________________________________
Muscle mailing list
[email protected]
http://lists.musclecard.com/mailman/listinfo/muscle_lists.musclecard.com
