Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 May : Re: Indy UDP readevent doesn't use dual core/multi processors?
| Subject: | Re: Indy UDP readevent doesn't use dual core/multi processors? |
| Posted by: | "Remy Lebeau (TeamB)" (no.spam@no.spam.com) |
| Date: | Tue, 2 May 2006 11:14:53 |
"Mike" <johnson40@zonnet.nl> wrote in message
news:44571bbc$1@newsgroups.borland.com...
> The Indy 10 version that came with Delphi 2006.
If you upgrade to the latest snapshot of Indy 10, do you still have the
problem?
> That sounds great! Exactly what I need. I'm just wondering how it was
> possible to realize this? From the other posts in the newsgroups I got the
> impression that the UDP connectionless nature didn't make this possible?
Although UDP is connectionless, it still requires a separate socket for each
endpoint that will be receiving data. TIdUDPServer allocates a separate
listening socket for each IP/Port that you want to receive data on (it has
always done that), and then runs a separate thread for each one (that is
newer behavior).
> Or is it just as simple as looking at the source ip/port combination
> and calling it a "connection"?
That is partially what older versions used to do. Although TIdUDPServer has
always used multiple listening sockets, it used to have a single listening
thread that would continuously loop through all of the Bindings, and if any
had data available then it would pull out the IP/Port from that socket and
then trigger the OnUDPRead event with the current information. This
approach was only able to trigger the event for one socket at a time. The
newer model can trigger the event for multiple sockets simultaneously now.
> Is there now a point in the Indy code where the incoming packet is
> checked with a list of running threads by comparing source ip/port
> combination?
That is handled by the OS internally. Always has been. The OS manages the
network resources and routes the incoming packets to the correct socket
endpoint.
> Doesn't that involve some critical section stuff that slows down the code?
With each socket running in its own thread, there is no synchronization
needed between them. The only time you'll need to do that is if your own
code needs to share your own resources between multiple sockets in the event
handler.
> Is it possible to have some local variables hooked up on every
> binding/thread, as is the case with the TCP version? So can I make
> a derative ContextClass?
TIdUDPServer does not use Contexts at all. That is only available in
TIdTCPServer. There is currently no way to associate user data with the UDP
sockets in TIdUDPServer. You will have to keep track of your data manually.
Gambit