Hi Remy,
Thanks for your reponse, but one thing still puzzles me!!!
If I can use AThread.Data to recognise users, how is simply identifying the
AThread bad?
IE Data is a Property of the AThread so presumably (correct me if I am
wrong) it would still identify the very exact same thread/property which
ever I use to identify my users?
Sorry if I seem dumb asking, but if I don't ask I don't know!
Oh and FYI, I am using TIdThreadManagerDefault.
I did once look at using a TList and the Threads.LockList thing but I had a
problem in that I also needed to keep track of offline clients in the same
place - EG an array and not a threadlist of active threads. If you have a
better idea please let me know!
Thx!
"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:459c31b8$1@newsgroups.borland.com...
>
> "Turboz" <turboz@turboz.moved.in> wrote in message
> news:459c2421@newsgroups.borland.com...
>
>> I am building a server which identifies users by their AThread
> (Looping
>> through an array of records to find a matching TIdPeerThread and
> then
>> obtaining the user name associated with it).
>
> That is not a good way to identify users, even in Indy 8. You should
> be using your own custom tracking information. You can use the
> TIdPeerThread.Data property to associate your data with individual
> threads if you want, but you should not be tracking the threads
> themselves. Add your own tracking data to a list in the server's
> OnConnect event, and clear it from the list in the OnDisconnect event.
> If you need to find a TIdPeerThread instance, you can loop through the
> server's Threads list, look for the Data that matches what you are
> looking for. This way, it doesn't matter what the server does with the
> threads, and your code will be easier to port to later versions.
>
>> However recently something sprung to my memory about the Indy
>> Threadmanager pooling AThreads.
>
> All the more reson to change how you are tracking users in the first
> place.
>
>> So, I was wondering if someone could explain in fairly easy to
>> understand terms, what the thread manager actually does
>
> That is a little complex to answer, actually. It really depends on
> WHICH thread manager you are using. Indy has 2 available.
>
> One manager, TIdThreadMgrDefault, creates a new thread when a client
> connections, and then destroys the thread when the client disconnects.
>
> The other manager, TIdThreadMgrPool, stores idle threads in a list.
> When a client connects, if there is an idle thread available, that
> thread is associated with the new client and then resumed. Otherwise
> a new thread is created. Either way, when the client disconnects, the
> thread is paused and then put back into the list for later reuse if
> the list has room, otherwise the thread is destroyed.
>
>> is it actually safe to identify the unique user by their AThread?
>
> No, it is not, especially when pooling is involved.
>
>
> Gambit
