Public TFTP server
michel...@yahoo.fr
I need to test transfer throughput over UDP.
Is there any public TFTP server which permit such test?
Michel
Walter Roberson
TFTP is not at all good at testing throughput over UDP.
TFTP requires an acknowledgement before the next packet is sent,
so even if no packets have been dropped, TFTP response is
largely constrained by latency instead of by bandwidth.
michel...@yahoo.fr
> TFTP is not at all good at testing throughput over UDP.
> TFTP requires an acknowledgement before the next packet is sent,
> so even if no packets have been dropped, TFTP response is
> largely constrained by latency instead of by bandwidth.
So is there any easy means to test UDP throughput on a public server?
Vernon Schryver
<michel...@yahoo.fr> wrote:
What is a "public server" and how is it that you don't already have one?
If it is the code, then look for free source called "tftpd," perhaps at
http://www.google.com/search?q=tftpd.c
If it is a computer that answers port 69, then why don't you ask friends
at distant points on the Internet to open their firewalls for UPD port 69
to the IP address of your TFTP client and do whatever testing you want
to do?
Never mind other obvious questions including:
- Why insist on UDP instead of TCP?
- Why insist on TFTP instead of other protocols using UDP?
http://www.google.com/search?q=udp+file+transfer
- Why not do some local testing first? If the issue is how TFTP
reacts to either latency or packet loss, why not use any of the
many tactics to introduce either into a local network?
- Why not read a basic networking textbook or two?
- Why do some people always assume that everyone who came before is
stupid and ignorant? The mania for using UDP for reliable stream
transport is like the mania it replaced. Both are based on the
assumption that everyone who has thought about network file
transport before was too stupid to realize that TCP is unnecessarily
slow and complicated for moving byte streams. 20+ years ago the
equivalent mania was for using raw Ethernet frames instead of TCP
or UDP. It was so common that I had a screed about how easy it
is to insert a canned UDP/IP header after the Ethernet header
(zero IP ID and UDP checksum off) and before the data and so
instantly get an application that works on more than a simple
Ethernet broadcast domain. After leading them by the nose to the
wonders of IP routing and proving that the DDN Protocol Suite
need not be significantly slower than raw Ethernet, it was often
not too hard to convince them to use TCP instead of UDP.
Such people rarely consider the possibility of complications such
as the need for error recovery for lost packets, not to mention
congestion control or avoidance, quality of service, etc.
Vernon Schryver v...@rhyolite.com
michel...@yahoo.fr
> - Why insist on UDP instead of TCP?
>
something to compare the troughput between UDP and TCP over a mobile
phone as a modem.
(If you can suggest a good server to test UDP traffic, maybe I could
request the IT people to install it on this IP address but could lats
a while)
I need a public address because I use a mobile. So the client is my PC
but the remote (server) need to be on the public network because the
mobile network gateway is linked to the www.
But it is true that I have no real idea how to do it for UDP so I
suggested TFTP. From the previous answer I learnt that TFTP uses an
acknoledge before sending the next packet, so it will be to slow.
I just need to know if the EOF have been received by the remote to
calculate the transmission time. (so the last packet need to be
received).
I need to test the mobile throughput. Mobile as a modem so I send the
file from my PC under the cmd window. But I need to discard the
problem due to TCP retransmission. (I am close to a mobile access
point and the network is quite good so sometime a do not lose any
packet).
(In fact, we have device to simulate the network but to use them I
need to go to an other office quite far away)
All suggestions are wellcome.
I will try netperf too.
Many thanks
Michel
Skybuck Flying
and then try sending or receiving packets from it and such.
http://www.myjavaserver.com/~skybuck/
Might work for you.
Bye,
Skybuck.
Jorgen Grahn
>>
>> - Why insist on UDP instead of TCP?
>>
> Because I have already access to a ftp public server so I need
> something to compare the troughput between UDP and TCP over a mobile
> phone as a modem.
In my opinion, that task is either meaningless, or answered simply as
"same as the IP throughput". See below.
> (If you can suggest a good server to test UDP traffic, maybe I could
> request the IT people to install it on this IP address but could lats
> a while)
Also consider the UDP echo and discard services (udp ports 7 and 9).
They can be easily enabled on most Unix servers, and they exist
precisely for IP testing.
> I need a public address because I use a mobile. So the client is my PC
> but the remote (server) need to be on the public network because the
> mobile network gateway is linked to the www.
...
> I need to test the mobile throughput. Mobile as a modem so I send the
> file from my PC under the cmd window. But I need to discard the
> problem due to TCP retransmission. (I am close to a mobile access
> point and the network is quite good so sometime a do not lose any
> packet).
It sounds to me as if the system you test (or rather, try to find the
characteristics for) is IP-only. The UDP and TCP implementations you
involve belong to Microsoft (deduced from the phrase "cmd window"
above).
So I guess you're measuring the characteristics of an IP route which
happens to go over an USB cable, through a cellphone, through a 3G
network and onto a public IP network. Latency and bandwidth at
different packet sizes and so on. Effects of fragmentation.
Whether a Windows UDP implementation works well across such a network
is beside the point, right? Same for a protocol like TFTP on top of
it.
In fact, plain old ICMP ping might be better for testing than UDP. The
only problem I can see is that routers might give it lower priority
than UDP traffic.
> (In fact, we have device to simulate the network but to use them I
> need to go to an other office quite far away)
The people in that lab are really the ones who should do this job.
You have no control over the 3G network or the public Internet, so you
cannot tell where packet loss or latency comes from.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!