Hi Roger,
I'm thinking "aloud" below, Some of this is proven, but most is not and
certainly not in combination with
smart cards. you asked for "any" hint, so here goes my imagination:
Summary:
Both card communications and HTTP are half-duplex, and asymmetric, your
only problem is that HTTP is request/response with
the server having no way to take the initiative. I'm assuming it *has*
to be HTTP, you have no way of using a simple TCP connection
(because that would make it *much* simpler and less wasteful).
There are various solutions but most involve polling and/or blocking,
and this has serious drawbacks, both in terms of response time
and resource usage. Response time might get you into trouble with some
cards (timeouts - I haven't really seen this in the wild, which is why I
write "might").
What I (and, for example, twitter) do is to consider the HTTP response
as a header, followed by a file of undetermined length. In fact,
the HTTP response becomes a stream and after the header you just use
half of the TCP connection it's on and forget that it's going through
HTTP server and client. I serve text-formatted data in this way, often
for months on end (and so does Twitter).
You could do the same, and also the opposite, which is having a HTTP
POST of undetermined length.
In essence, open 2 HTTP connections, of which you'll use half of the TCP
connection each, to obtain a full-duplex channel, which you'll then use
in half-duplex mode.. (which is why, if you could have gotten away with
just plain TCP, it would be much better..)
On the client side:
Open HTTP connection "RA" to the server, to endpoint (URL, port..)
"RAE". method POST.
Open a second HTTP connection "A" to the server, to endpoint (URL,
port..) "AE". method POST. Send headers.
connect to the card
compose HTTP Headers including ATR "X-ATR: ....BC" and send headers over
connection "RA".
Block reading from connection "RA"
when data appears:
read it, construct APDU with it and send to card
send response APDU over connection "A".
On the server side:
Somehow keep track of 2 connections with the same identifier (SSL
mutual, cookie, in headers.. etc..), and
have one thread access them both (this may be tricky in some
environments. Haven't tried in e.g. Web container)
block reading from connection "RA".
when data appears:
read it, it's an ATR.
decide whether this ATR is yours to handle
if it is
while work_to_do:
send APDU over connection "A"
block reading from connection "RA"
read it, it's an APDU Response
...etc.. It would be smart to have timeouts, and/or not simply loop
reading and writing, but make it a read state machine,
and just act according to events (connections/disconnections, ATR,
responses..)
This solution is far from optimal: It takes 2 TCP connections where one
would have sufficed, and then wastes half of each (where
the half-duplex nature of the card could already be said to waste half
of a full-duplex TCP channel)
However, the alternative would be to create new connections, constantly,
to get the response APDU to the server, and in my
experience this can be much worse in terms of consequences: TCP
connections take up resources in the server (and often,
in intermediate devices on the path) long after the connection was
closed. While maintaining 2 connections instead of one
doubles the immediate resource usage, having each device make many small
connections will do *much* worse. Also, if your
protocol happens to be sensitive to timing, you may be in trouble if the
server takes a while to accept each new connection.
my .0077 Euro :-)
-f
On 09/22/2012 07:28 AM, Roger Brown wrote:
> I think writing a user-mode IFD Handler for PCSC-LITE with some form of IPC
> would be preferable to writing a Linux kernel device driver.
>
> One problem I see is that apache is client server, where-as the program using
> PCSCLITE/WinSCard expects to be the client in control.
>
> Does this mean that the phone would need to poll the apache server for APDUs
> to send to the card? HTTP might not be the best protocol to use if the linux
> machine needs to send arbitrary messages to the reader.
>
> _______________________________________________
>
> NFC capable smartphone with reader software <----> apache server which
> delegates connection between smartphone and driver <----> linux driver <---->
> pcsc-lite middleware <----> application
>
> this is a short recap of the architecture i thougt about.
>
> Hopefully this is somehow realizable, every hint would be welcome.
>
> thanks
>
> Christian
>
>
> _______________________________________________
> Muscle mailing list
> [email protected]
> http://lists.drizzle.com/mailman/listinfo/muscle
>
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
