After doing some tests with Bettina Martelli and Ludovic Rousseau, it seems that there is a problem in the design for handling the client requests.
In the following I explained you the problem and I described the process in order you help me to choose a new design. I hope you may work with me on its implementation.
1) The problem:
Bettina have discovered a problem when we use many clients with heavy load (see [1]). Her patch ensures that all the clients will be served and not always the same (i.e. not the first in the client array list that sends the most of requests). But her solution does not solve the problem of timeout on the other client requests if the process for the actual client takes a long time. This problem is due to that there is only ONE thread to deal with ALL the requests.
Indeed if one client sends a request needed one hour before the response of the card, the daemon will be stopped during one hour and all the client requests will be timeout.
I have add the support allowing us to access in the same time to the slots of a multi-slot reader and to many identical reader using the same ifdhandler on the reader-side. But if on the client-side there is a problem of serialisation it is useless. Before my addition the problem was exactly the same.
I have not applied the patch of Bettina because we may be perhaps decide to change all the design.
2) The design:
Daemon side:
When PC/SC Lite daemon starts :
- it parses the command line
- it adds the reader on the config file and starts one thread by reader (for handling the events as card insertion, ...).
- it detects the hotplug readers and adds them (HPSearchHotPluggables).
- it starts a thread in order to know when a reader is plug/unplug for handling these events (HPEstablishUSBNotifications).
- it starts the loop for detect the client events and deals with them. There is only ONE thread for handling all the client requests (loop in the SVCServiceRunLoop). Follow the details of this loop.
* Call SHMProcessEvents:
This thread looks for in the client list from the beginning if a client has done a request until there is one. (From the beginning of the array implies that the clients in the end of the list may be never served. Bettina has solved this.)
*Call MSGFunctionDemarshall:
After detection of a request, the process continues by doing the request in calling the ifdhandler of the reader if needed.
And as this call is blocking, the thread sleeps until the end of the call.
*Call SHMMessageSend:
After this return the response is send to the client. The loop continues its detection of new client event.
Client side:
The client sends its request on a socket and waits until there is a response.
An other problem in this design is that the thread HPEstablishUSBNotifications needs a mutex for the plug/unplug.
This mutex is also used to protect the functions SHMProcessEvents, MSGFunctionDemarshall and SHMMessageSend. And this mutex also obstructs simultaneous client requests handling
Have you some ideas for a new design?
[1] http://archives.neohapsis.com/archives/dev/muscle/2003-q3/0206.html
Regards,
Damien Sauveron
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
