如何加速Java中PC / SC阅读器上的卡缺失检测？

Question

an application I am working on requires to detect, as quick as possible (in 500 ms maximum), that a card is removed from the field.

Here is what I did to test the time needed to detect that absence of the card:

public static long timeToGetCardAbsent(int version) throws CardException{
    TerminalFactory factory = TerminalFactory.getDefault();

    CardTerminals terminalList = factory.terminals();
    CardTerminal ct = terminalList.list().get(0);

    long connectTime = 0, disconnectTime = 0;

    ct.waitForCardPresent(0);
    connectTime = new Date().getTime();

    ct.waitForCardAbsent(0);
    disconnectTime = new Date().getTime();

    return disconnectTime - connectTime;
}

When the program is running, I tap a (DESFire) contactless card on the reader and remove it immediatly.

Here are the outputs:

1437
1437
1438
1437
1422

I means that the reader (or the program?) needs almost 1.5 seconds to detect that the card is absent, which too long time for me.

Is there a way to speed up this detection? I am currently using javax.smartcardio , would I get better results with another library? I actually don't know what else I could use, do you have leads?

Thanks, GChabot

Answer 1

I actually managed to improve the detection time a lot today. I was looking at that web page from "NFC Wizard" and noticed that they were very fast at detecting my card removal. This javascript web page communicates with the reader through a Java applet, so it really uses nothing more than I have.

SpringCard, the creators of NFC Wizard, actually provides complete documentation and even source code for a similar application at that page, under Other resources > Java and "SpringCard PC/SC SDK (ZIP archive)" .

While browsing their code, I noticed that after performing operations on the card, the use the card.disconnect(false); function (I had tried to use card.disconnect(true); but had the same results as before... bad luck ).

So here is now what I do :

import java.util.Date;
import javax.smartcardio.*;

public class NewMethod {
    private long connectTime = -1;
    private long disconnectTime = -1;

    private TerminalFactory factory;
    private CardTerminals terminalList;
    private CardTerminal ct;

    public NewMethod() throws CardException{
        factory = TerminalFactory.getDefault();

        terminalList = factory.terminals();
        ct = terminalList.list().get(0);
    }

    public long waitForCardPresent(){
        try {
            ct.waitForCardPresent(0);
        } catch (CardException e) { }
        return new Date().getTime();
    }

    public long waitForCardAbsent(){
        while(true){
            try {
                Thread.sleep(10);
            } catch (InterruptedException e1) { }

            try{
                ct.connect("*").disconnect(false);
            }
            catch(Exception e) {
                return new Date().getTime();
            }
        }
    }

    public void run(){
        while(true){
            connectTime = waitForCardPresent();
            disconnectTime = waitForCardAbsent();
            System.out.println((disconnectTime-connectTime));
        }
    }

    public static void main(String[] args){
        NewMethod nm;
        try {
            nm = new NewMethod();
            nm.run();
        } catch (CardException e) {
            e.printStackTrace();
        }
    }
}

(The thread part is optional but I got the same results with or without it so I preferred to save a bit of processor consumption)

Here are the times I got with the threaded version: 531, 437, 656, 657, 735, 657, 547, 844, 15, 766, 859, 563, 765, 562, 422, 437, 563, 562, 562, 672, 672, 16, 547, 546, 672, 15, 344 and here with the unthreaded version: 984, 547, 796, 656, 796, 718, 656, 812, 625, 781, 813, 547, 797, 532, 407, 609, 719, 328, 469, 328, 0, 546, 625, 0, 843, 703

We may notice that the results are quite unstable (and quite better with the threaded version actually), this might come from the way I tap the card against the reader but I believe this is not the only reason.

It looks good enough for me now. I just hope I won't get a too great variability when I will actually use it on my application.

Answer 2

I've tested a bit on Linux, and in Linux, the default PCSC deamon is polling the driver each 400-500ms. Unstable drivers seem to remove this polling and use a different method, if the PCSC Lite information that I found is correct.

The Java method seems to return almost instantly, so that's not likely to be the culprit. Try and update your PCSC implementation, firmware and drivers to the latest version. If that does not work you've got no choice to work around it.

That answer did cost me an installation of PCSC on Linux + SCM SDI010 driver installation and the test of 3 firmware's. But I wanted the info myself anyway. I'll update the answer if I get a newer version of PCSC lite to work.