Erratum, on the server side, the ATR is in the headers of connection "RA", not in the POST data..
On 09/22/2012 08:50 AM, Frank Marien wrote: > 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
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
