We use thinstation also, thats probably a good way to view rdp clients, by starting it directly on them, usersnames would be an issue, but it should be possible to modify the rdesktop client to get usernames. But by the sounds of it you use citrix not rdp. If I get some time i might modify a thinstation client and attempt to put italc on it.
From: italc-devel-bounces@... [italc-devel-bounces@...] On Behalf Of Juan Antonio Marin Beltran [tonin@...]
Sent: Friday, 23 May 2008 5:09 AM
To: Tobias Doerffel
Subject: Re: [Italc-devel] ITALC thread model suggestion
Tobias Doerffel escribió:
Am Sonntag, 11. Mai 2008 13:10:21 schrieb Juan Antonio Marin Beltran:
This is my first post to the list. I work at University of Cordoba
(Spain) and we are using ITALC from 1 month to control all our
classrooms. We use in them a ThinClient named "ThinStation" for about 5
years. We have modified the thinclient to offer a full local linux
session using a NFS repository that acts as /usr/local for all
computers. The students have in the same class computer a local linux
session, a X session to a solaris server and a windows session to a
metaframe farm using icaclient. Each session runs on a different VT in
the same computer, so they can works with all environments at same time
switching using CTRL-ALT-Fx.
Now we have about 500 computers in 20 classrooms, all monitorized with
ITALC from our personnel.
We have detected a big problem with ITALC multi-threading model. It
seems that ITALC at start allocate one thread for each computer. With
italc master running at windows vista computers, there isn't any
problem, but under linux computers, there is open file limits and max
threads limits. With ubuntu 7 we can only put about 278 clients
computers in globalconfig.xml.
Why don't you create globalconfig.xml files let's say for each room and use
the according one when starting master in a room?
As I said, we are using ITALC to control ALL classroom from a central location to give remote assistance and monitoring to all users in our classrooms. So, we need to have all classrooms available at once. In each classroom of course the teacher computer is configured only with the classroom clients to allow teacher usual tasks.
I think that ITALC is more than a teacher's tool and can be easily adapted to a admin's tool with minor changes.
Of course it wil be possible to recompile the kernel to modify
FD_SETSIZE and max threads, but we think that the approach isn't right.
We think that it will be better to allocate client threads "at fly" when
a classroom becomes visible, and destroy them when switch to other
classroom. Here are the pros and cons of this change:
- Italc master application could run on linuxes with many client
computers without recompiling kernel.
- The time to start is much quicker.
- Less memory and cpu consumption.
- The switch between classrooms may be slower, but with the performance
gain due to have much less threads, it could be imperceptible.
Basically you're right - but implementing won't be that easy. I'll see what I
can do after final 1.0.9 release.
I hope that in future releases it will be possible to have in
consideration this change. We are open to help in the development.
Do you have coding experiences? Ever taken a look at iTALC-sources? Any help
is always appreciated :)
Yes, we have coding experience and a lot of "human power" using our computing science students :) I'm thinking about offer some final-graduate jobs (I'm not sure if the spelling of this is right ...) to improve italc especifications. But we want to stay in the main branch of italc if it's possible.
Looking the code, I see that in the "client" constructor, the last line is this:
m_updateThread = new updateThread( this );
¿Can it be moved to the setVisible method of classRoomItem? Create updateThread when visible an destroy when hide. So it doesn't seems to difficult to implement.
We hope also to contribute with an "ica" daemon that switch between
multi VT sessions in thinclients to monitor with italc at client side
instead thar server side.
Hm don't understand completely what you mean with that. Could you please
explain a little more detailled?
Many thinclient linux-based distributions like thinstation, pxes, etc. use a multi-screen Xorg to handle many client connections to many servers. You can have for instance one citrix-ica connection to a windows server running ica-client on X display :0.0, another one using nxclient to a unix o windows server on X display :1.0, a local firefox browser in kiosk mode in X display :2.0 and so on. Using LTSP can use the same approach.
Each X display use a different linux VT and you can switch from one session to other using CTRL-ALT-Fx key combinations.
So you can control each session at server side, starting italc ica client in the server using differents ports for each client session as wiki say.
Our approach is to start italc ica client locally on each thinclient. Italc client starts in the same display that the user is using at a time. Our daemon (a simple bash script running on background), monitor if the VT have changed and if so, it kill the italc ica client and start a new using the new X display. So the teacher or admin see on italc IMA application the same output that the user is seeing in his scren.
Of course, if the student in one session is connected to a windows server through citrix ica client or nxclient, we haven't knowledge of the username because italc client is running at client side and no at server side. We get the username (setting the USER environment variable before start italc client) using a WMI query to the server using wbemcli.
I hope that this brief explanation allow to understand better our italc implementation.
This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender.