"Philippe Auphelle" <pauphelle.No.Spam.Please@wanadoo.fr> wrote in message
news:452ce304@newsgroups.borland.com...
> The Indy I have is a '10.1.5' that I downloaded as a "release"
> early December 2005
You are using an old version that is over 11 months old. Besides that, you
couldn't have downloaded it in December 2005, because TIdUDPServer was
re-written on November 17, 2005. The code you showed is not in the November
17 and later versions. For what you describe to be happening, you have to
be using a version that is older than that date.
> I precisely checked. And the fact is that does it just the way I said,
> and not the way you thought it did:
What I described is how it works *today*, not how it worked *11+ months
ago*.
> function TIdUDPServer.GetBinding: TIdSocketHandle;
That is not what the code looks like anymore. Each entry in the Bindings
collection has its own separate listener thread now.
In any case, if you look at what TIdUDPListenerThread actually does in the
version you have, you will see that it reads data on all entries of the
Bindings collection, not from a single entry only:
procedure TIdUDPListenerThread.BeforeRun;
var
i: integer;
begin
// fill list of socket handles
FReadList := TIdSocketList.CreateSocketList;
for i := 0 to FServer.Bindings.Count - 1 do begin
FReadList.Add(FServer.Bindings[i].Handle);
end;
end;
procedure TIdUDPListenerThread.Run;
//...
begin
FReadList.SelectRead(AcceptWait); // <-- waits for any Binding
socket to receive data
for i := 0 to FReadList.Count - 1 do try // <-- loops through all
Binding sockets that have pending data
// triggers the OnUDPRead event for each Binding socket...
end;
end;
> As you can see,
> TIdUDPListenerThread.Create(BufferSize, Self);
> is called just once
It may be starting a single listener thread, but that one thread instance is
actually processes all of the Binding sockets.
> with FCurrentBindings set to Bindings[0]
That has no effect whatsoever on the issue you are experiencing.
> and a debugging session shows that this code is called only once, creating
a
> single thread.
See above.
> Bottom line: That version didn't support multi-homing
Yes, it does fully support multi-homing. Just not as efficiently as newer
versions do, but it does nontheless.
> except maybe by running several instances of the server object
> and passing to each a different local address.
No, that is not needed.
> Aaaaaah!
> Evidence found, case closed.
Your evidence is misunderstood, and thus completely wrong. TIdUDPServer has
supported multi-homing for years, long before Indy 10 even existed.
Gambit
