Gambit,
Since I wanted to clear once for all that potential firewall / antivirus
/ whatever external issue that you suspected, I decided to change my
console TFTPServer code a little bit: The newer test program now creates
and uses one instance of TrivialFTPServer per binding, each instance
declared with a single, explicitely defined binding. I dynamically
create the instances, hooking the very same event handlers
I used previously to all instances.
With this setup, the console TFTPServer code works great, whatever the
number of IP addresses there are on the machine.
This establishes that the problem is not in the firewall, nor in the
antivirus or anything else, but in the way TrivialFTPServer handles
multiple bindings.
I went back to the one-year-old version of Indy 10 that is on the AToZed
site (the one that compiles without any modification), and compiled my
multi-instance of mono-binding TTrivialFTPServer servers: That version
of Indy worked too, with either one or several IPs.
Finally, that also gives me a work around to the problem at hand - not
the most elegant, nor satisfying, nor resource efficient way to do, but
much better than no solution at all.
Finally, and FWIW, using the recent Indy snapshot and a single
TTrivialFTPServer instance with multiple addresses in Bindings (i.e. the
previous incarnation of the program as I posted it before), I tracked
the attempt that the server makes to send an answer to the client down
to the point where the ws2 SendTo routine is invoked.
As far as I could tell, the parms passed along to ws2_32.sendto that I
could check seemed to be good (i.e. destination IP and port, message
buffer and buffer length, IP stack version), and no error was reported
upon return - all bytes were reported as transmitted.
BUT a LAN analyzer running in the same machine as the TFTP server
never sees any outgoing message on any IP, and the client never
receives any answer either.
I couldn't check at this point in time if the socket that was used for
sending was in the right state (nor even that it was the right one, as a
matter of fact, because that would have required previous tracking of
the ws2 socket creation). And I only partially checked the sockaddr
struct passed to sendto.
In any case, since I now get the right results using the same event
routines hooked to multiple instances of a mono-bound TrivialFTPServer,
there is now little doubt that
1) there is a problem in the way the one-year-old TTrivialFTPServer
handles multiple bindings, and that
2) there is another, different problem in the recent snapshots. /Ph.
Remy Lebeau (TeamB) wrote:
> "Philippe Auphelle" <pauphelle.No.Spam.Please@wanadoo.fr> wrote in message
> news:452f4bfb@newsgroups.borland.com...
>
>> 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.
>
> For the OnReadFile event to be triggered to begin with, the receiving socket
> has to be valid, and the remote IP/Port has to be reported by the OS and be
> valid for that event. When the OnReadFile handler exits, the reply is sent
> back on the same socket to the same IP/Port that sent the request. If those
> values are present and accurate, then there is no way for the analyzer to
> not show a reply being sent.
>
> Incidently, do you have any anti-virus programs running at the time of your
> tests? Either McAfee or Norton (I forget which one) is known to interfer
> with Indy sockets sometimes.
>
>
> Gambit
