On 25/04/07, Ulf Leichsenring <[EMAIL PROTECTED]> wrote:
Hi
Hello,
I'm using pcscd 1.4.0 under Linux (Debian Etch and eLux) for smartcardlogon to and smartcard usage within Citrix sessions (Win2003 Server) using X.509v3 certificates. After logging into the Citrix server using the smartcard and starting 3 other published Citrix Applications on other servers within the session, I reached the smartcard session limits within pcscd (applications are not accepting the smartcard anymore).
I am already aware of this limitation. Citrix is the only application I know that suffers from this limitation.
In the pcscd.h I found a limitation for 16 applications and 16 channels within the applications. I played around with these values and set PCSCLITE_MAX_APPLICATIONS PCSCLITE_MAX_APPLICATION_CONTEXTS PCSCLITE_MAX_READER_CONTEXT_CHANNELS PCSCLITE_MAX_APPLICATION_CONTEXT_CHANNELS PCSCLITE_MAX_THREADS from 16 to 64, just for testing. After this, I could start all the needed smartcard applications within the Citrix session without reaching the limits. When I monitored the memory usage of pcscd with 'top', I saw that pcscd is consuming 387M of virtual RAM on the linux client after starting 9 smartcard applications within the citrix session. This seems very high to me.
I tried to reproduce the problem but I only have 28MB of virtual memory when I use 64 and 19MB with the default value 16. In both cases I had NO application, just pcscd started. I have no idea where this 387M number comes from. Can you do more experiments? What is the virtual mem used with the default configuration?
What can I do to optimize the memory usage of pcscd. I need to raise the pcscd session limits because here the users are using linux thin clients , Citrix and every server (and published application) logon is forced to use smartcards/certificates for authentication. So there are probably 3 to 10 applications in use by the user. Every citrix session seems to use 3 to 5 smartcard channels.
pcscd is doing static memory allocation. So the number of applications, contexts, etc. are limited. The solution would be to use a dynamic allocation. That would be a major change. Patchs are welcome :-) Bye -- Dr. Ludovic Rousseau _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
