"Jamie Dale" <j.dale@turboz.net> wrote in message
news:44802576@newsgroups.borland.com...
> I'm not sure but I thought ALL indy servers were multithreaded anyway?
They are. But TIdUDPServer's threading model is different than
TIdTCPServer's since UDP is connectionless. TIdUDPServer can't have 1
thread per client like TIdTCPServer can, because there are no client
connections to begin with.
> Not sure but if your UDPserver is multithreaded like the TCPserver, then
> you don't need to fire a seperate thread as it will automatically create a
> new thread instance and execute the code you've written in the unit.
TIdUDPServer does not do that. Only TIdTCPServer does.
> My tcp thread could not send commands to a component on the form
Yes, it can. You just have to Synchronize the access, either by calling
TThread.Synchronize() directly, or by using the TIdSync or TIdNotify
classes.
> I had to put the text into a public string and set a timer to read it..
That is not thread-safe, unless you wrap the string with a mutex, semaphore,
or critical section. If the thread writes to the string at the same time
that the timer is reading it, you can have unexpected behavior.
> I ain't sure about UDPserver but assuming its the same as the TCP
It is not.
> you just need to write your handling code (IE, process the message, do
> database lookup [ini files are surprisingly good too] etc and send
response)
> and the UDPserver will automatically thread it with a new instance based
> on your unit at runtime.
That is not what happens. However, the TIdUDPServer.OnUDPRead event handler
code can be written similar to the TIdTCPServer.OnExecute event handler
code, but just keep in mind that the OnUDPRead event for multiple clients
are triggered in a serialized manner because of the nature of UDP, whereas
the OnExecute events are triggered in parallel instead.
Gambit
