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 <[email protected]>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 [[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
