 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Stefan Paege
Guest
|
 Posted: Fri Feb 24, 2006 5:03 pm Post subject: TidTrivialFTPServer problems |
 |
|
Hi,
I'm using TFTP to transmit some data. All tests have worked fine but
there are problems at the customer's site when transmitting a file to
the TFTP server. They often see that the connection is created, then
transmission starts and is terminated immediately afterwards. They end
up with a 0 Byte file at the server.
After some debugging I found the reason. They have some machines that
are connected to the company network via a radio based infrastructure.
Not a WLAN or a GPRS based service but a (much slower) TETRA radio
network. We are talking of ping times between 500ms and 1000ms.
Bandwidth for data is around 2400 Baud net as they are prioritizing
voice communication! Transmissions fail because of timeouts. I've set
the ReceiveTimeout property to a higher value but that does not help at
all. The culprit is Indy's TidTrivialFTPServer. After the connection is
established the component spawns a process that takes care of the file
transfer. And this thread has a hardcoded timeout of 1500ms. Not enough
time to transmit a data block (BlockSize is usually 1500 bytes).
I know we're mostly using fast networks today. But I still think it is a
design flaw.
Code in IdTrivialFTPServer.pas in TIdTFTPServerThread.Create()
begin
inherited Create(True);
FStream := AStream;
FUDPClient := TIdUDPClient.Create(nil);
with FUDPClient do
begin
ReceiveTimeout := 1500; // <- Hardcoded
Can this be adjusted in the next incarnation of Indy?
Regards
Stefan
PS: I'm using Indy 9 but the same code exists in Indy 10. |
|
| Back to top |
|
 |
Guillem
Guest
|
| Posted: Wed Mar 01, 2006 12:03 pm Post subject: Re: TidTrivialFTPServer problems |
|
|
Stefan Paege wrote:
| Quote: | Hi,
I'm using TFTP to transmit some data.
|
my suggestion in your case: try moving over to TCP/IP. Skip FTP as it
would need 2 connections every time. See below.
| Quote: | All tests have worked fine but
there are problems at the customer's site when transmitting a file to
the TFTP server. They often see that the connection is created, then
transmission starts and is terminated immediately afterwards. They
end up with a 0 Byte file at the server.
|
what exception is raised at the server?
| Quote: |
After some debugging I found the reason. They have some machines that
are connected to the company network via a radio based
infrastructure. Not a WLAN or a GPRS based service but a (much
slower) TETRA radio network. We are talking of ping times between
500ms and 1000ms. Bandwidth for data is around 2400 Baud net as they
are prioritizing voice communication!
|
it's been a loooong time since I last saw such a speed... :)
| Quote: | Transmissions fail because of
timeouts. I've set the ReceiveTimeout property to a higher value but
that does not help at all. The culprit is Indy's TidTrivialFTPServer.
After the connection is established the component spawns a process
that takes care of the file transfer. And this thread has a hardcoded
timeout of 1500ms. Not enough time to transmit a data block
(BlockSize is usually 1500 bytes).
|
you could do 2 things here. Either set the BlockSize to a lower value
if using such a bandwidth or create a descendant and override it to
make the timeout longer (or configurable)
| Quote: |
I know we're mostly using fast networks today. But I still think it
is a design flaw.
|
it depends on how you see it. I agree hardcoding a timeout would not be
my option, but TFTP is created on top of UDP, which by design is an
unreliable protocol, very good for broadcasting if you do not mind that
some packages get lost. Don't get me wrong, TFTP ensures that all
packages arrive or else it terminates the connection but it still
depends on the underlying UDP client/server.
IMO this is a way to ensure that no thread just waits forever.
<snip code>
| Quote: | Can this be adjusted in the next incarnation of Indy?
|
I am not from the coding team but I doubt it. TFTP is not a priority as
almost all people that need file transfering use TCP/IP, FTP ot HTTP.
Just my opinion.
--
Best regards :)
Guillem Vicens Meier
Dep. Informática Green Service S.A.
www.clubgreenoasis.com
--
Contribute to the Indy Docs project: http://docs.indyproject.org
--
In order to contact me remove the -nospam |
|
| Back to top |
|
|
Stefan Paege
Guest
|
| Posted: Wed Mar 01, 2006 2:03 pm Post subject: Re: TidTrivialFTPServer problems |
|
|
Hi Guillem,
thanks for your answer. Comments inline...
| Quote: | I'm using TFTP to transmit some data.
my suggestion in your case: try moving over to TCP/IP. Skip FTP as it
would need 2 connections every time. See below.
|
The customer forces us to use TFTP _because_ it uses UDP which has less
overhead compared to TCP. Reason is the digital radio network with its
huge latency and tiny bandwidth.
| Quote: | Transmissions fail because of
timeouts. I've set the ReceiveTimeout property to a higher value but
that does not help at all. The culprit is Indy's TidTrivialFTPServer.
After the connection is established the component spawns a process
that takes care of the file transfer. And this thread has a hardcoded
timeout of 1500ms. Not enough time to transmit a data block
(BlockSize is usually 1500 bytes).
you could do 2 things here. Either set the BlockSize to a lower value
if using such a bandwidth or create a descendant and override it to
make the timeout longer (or configurable)
|
Reducing blocksize would further reduce throughput because of additional
protocol overhead (more ACK messages) combined with high latency.
| Quote: |
I know we're mostly using fast networks today. But I still think it
is a design flaw.
it depends on how you see it. I agree hardcoding a timeout would not be
my option, but TFTP is created on top of UDP, which by design is an
unreliable protocol, very good for broadcasting if you do not mind that
some packages get lost. Don't get me wrong, TFTP ensures that all
packages arrive or else it terminates the connection but it still
depends on the underlying UDP client/server.
|
It is perfectly fine to use a UDP based protocol like TFTP for this
task. Vendors of TETRA radio networks like Motorola and Nokia recommend
the use of UDP instead of TCP.
The problem is neither a UDP flaw nor a flaw in the Indy implementation
of UDP. It is the implementation of TFTP.
| Quote: | I am not from the coding team but I doubt it. TFTP is not a priority as
almost all people that need file transfering use TCP/IP, FTP ot HTTP.
Just my opinion.
|
Well, I can of course do the necessary changes myself. But that means I
have to do it again and again with every new version of Indy.
Is there a place where I can send the changes made so that the Indy team
can review them and add them to the Indy codebase?
Regards
--
Elektronik-Labor Carls GmbH & Co. KG
Stefan Paege
Fon: +49 5973 9497-23
Fax: +49 5973 9497-19 |
|
| Back to top |
|
|
Guillem
Guest
|
| Posted: Thu Mar 02, 2006 12:03 pm Post subject: Re: TidTrivialFTPServer problems |
|
|
Stefan Paege wrote:
| Quote: | Hi Guillem,
thanks for your answer. Comments inline...
|
you're welcome :)
| Quote: |
The customer forces us to use TFTP because it uses UDP which has less
overhead compared to TCP. Reason is the digital radio network with
its huge latency and tiny bandwidth.
|
users...
| Quote: |
Reducing blocksize would further reduce throughput because of
additional protocol overhead (more ACK messages) combined with high
latency.
|
right. Reducing the blocksize causes the number of packets to grow,
ergo incrementing overhead. I just wanted to say there were 2
possibilities
| Quote: |
It is perfectly fine to use a UDP based protocol like TFTP for this
task. Vendors of TETRA radio networks like Motorola and Nokia
recommend the use of UDP instead of TCP.
|
that is IMO the design flaw, but I guess TETRA radio networks can't
have better bandwidths due to whatever reason that I am not aware of...
| Quote: | The problem is neither a
UDP flaw nor a flaw in the Indy implementation of UDP. It is the
implementation of TFTP.
|
although you are right that it should not be hardcoded, IMHO the basic
flaw lies in using UDP for a file transfer protocol. TFTP is very
lightweight but you pay that by a less secure (considering errors)
transfer. Keep in mind that TFTP, unlike its equivalent TCP-based FTP,
terminates a transfer if any package is lost or malformed.
Still, if you need to use it, well, good luck...
| Quote: |
Well, I can of course do the necessary changes myself. But that means
I have to do it again and again with every new version of Indy.
Is there a place where I can send the changes made so that the Indy
team can review them and add them to the Indy codebase?
|
not directly but see
http://www.indyproject.org/Sockets/Teams/Dev/index.en.iwp
--
Best regards :)
Guillem Vicens Meier
Dep. Informática Green Service S.A.
www.clubgreenoasis.com
--
Contribute to the Indy Docs project: http://docs.indyproject.org
--
In order to contact me remove the -nospam |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
