> In the OnReadFile event, when GrantAccess returns False,
> the server doesn't answer anything instead of returning a
> "file not found" error message to the TFTP client.
Forgot to mention that this "no reply" situation only happens when there
are two IPs in the machine, in the same testing conditions I described
previously (TFTP client calling on the wired LAN only).
And it happens just the same both using an implicit "with" pointer and
an explicit intermediate TStrings pointer to access the LocalAddresses.
A LAN analyzer session confirms that the server behaves normally when
OnReadFile returns True, but doesn't send anything on either link when
OnReadFile returns with GrantAccess set to False.
With only one IP, everything works like it should. /Ph.
Philippe Auphelle wrote:
> And, by the way, I have *also* tried the form you indicated in an even
> earlier message, where instead of using a "with" pointer I explicitly
> declared a TString pointer and worked from that one, but it didn't
> change a thing to the misbehavior of the application:
>
> procedure TDataModule1.StartTFTP;
> var
> Addresses: TStrings;
> i: integer;
>
> begin
> with DataModule1.IdTrivialFTPServer1 do
> begin
> Active := False; // Just in case.
> Bindings.Clear;
> ThreadedEvent := True; // No synch in a console.
> // All other component properties are the default ones.
> Addresses := GStack.LocalAddresses;
> // For each of our IP addresses, create and init a binding.
> for i := 0 to Addresses.Count - 1 do
> with Bindings.Add do
> begin
> IP := Addresses[i];
> WriteLn('Created binding '
> + IP
> + ':'
> + IntToStr(Port)
> );
> end;
> Active := True;
> end;
> end;
>
> Finally, as I mentioned before, the problem as I reported it is fixed in
> the snapshot that was released two days ago, but that same snapshot has
> another problem:
> In the OnReadFile event, when GrantAccess returns False, the server
> doesn't answer anything instead of returning a "file not found" error
> message to the TFTP client.
>
> I so far traced the code through the exception handlers to the point
> where it is supposed to send of a "File not found" message as a reply,
> but haven't yet got to the point where I could see what prevents the
> send from occurring.
> All of this was found using the minimal console TFTP server I sent
> yesterday.
>
> Oh well. /Ph.
>
>
> Remy Lebeau (TeamB) wrote:
>> "Philippe Auphelle" <pauphelle.No.Spam.Please@wanadoo.fr> wrote in
>> message
>> news:452e1a2b@newsgroups.borland.com...
>>
>>> After fixing in yesterday's snapshot the couple of lines that don't
>> compile,
>>> I used the snapshot Indy, recompiled my app, and surprise! It *does*
>>> work with two IPs, *without* changing anything else in my own code.
>>
>> As it should be.
>>
>>> Once again, I have no doubt that TidUDPServer has been *designed*
>>> to support multi-homing for years, but the hard fact is that the
>>> version I
>>> used of a stable 10.1.5 as of today does *not* seem to work properly
>>> on a multi-homed config.
>>
>> Yes, it does. TIdUDPServer has been using the same multi-homed
>> architecture
>> for years that has worked fine. The re-write done 11 months ago was
>> merely
>> to optimize that better so that the OnUDPRead events triggered on
>> multiple
>> items in the Bindings collection are not serialized anymore, which they
>> always were due to the single listener thread looping through the
>> Bindings
>> one at a time. But the Bindings themselves still work the same as they
>> always have.
>>
>>> // For each of our IP addresses, create and init a binding.
>>> for i := 0 to GStack.LocalAddresses.Count - 1 do
>>> with Bindings.Add do
>>> begin
>>> IP := GStack.LocalAddresses[i];
>>
>> I explained to you earlier about the danger of accessing the
>> LocalAddresses
>> property over and over like that.
>>
>>
>> Gambit
