From: "Rich" 

This is a multi-part message in MIME format.

------=_NextPart_000_021D_01C55D24.22F6E9A0
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

   UDP does not have ACKs but you can get an ICMP response if sending to =
a port that is not listening and that response can affect throughput.  = In
my test I ran my listener app on one machine and my sender on = another.

Rich

  "Gregg N"  wrote in message =
news:428e11fe$1{at}w3.nls.net...
  Geo wrote:
  > "Gregg N"  wrote in message
  > news:Xns965BF11E63FA4gregginvalidinvalid{at}216.144.1.254...
  >
  >> The IP protocol allows for up to 64k datagrams, but the RFC only
  >> requires hosts to handle up to 576 octets, and says not to use
  >> larger datagrams unless you know that all the intermediate systems
  >> support it. If you control all the hops between the source and
  >> destiniation, then this is not an issue. I don't think this
  >> limitation occurs too much in practice even when you don't control
  >> the intermediate systems.
  >
  > Ok so I take it you can be pretty sure this isn't what's causing the
  > slowness being discussed?

  Yes, because I don't care whether the receiver accepts my packets or =
not. I=20
  am just measuring how fast I can send them. The sender isn't even =
aware of=20
  what happens to the packets once they leave the computer. UDP does not =
have=20
  ACKs.

  > Maybe fragmentation requires some sort of a response from the other
  > end that smaller non fragged UDP packets don't require (a function =
of
  > routers or something)?

  IP fragmentation does not require a response. The sender just splits =
the=20
  packet up into multiple ethernet frames with a fragmentation flag and =
offset=20
  set in each fragment. The recipient reassembles the fragments. If a =
fragment=20
  gets corrupted or lost in transit, the sender is none the wiser.

  Gregg

------=_NextPart_000_021D_01C55D24.22F6E9A0
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








   UDP does
not have ACKs but =
you can get=20
an ICMP response if sending to a port that is not listening and that = response=20
can affect throughput.  In my test I ran my listener app on one =
machine and=20
my sender on another.
 
Rich
 

  "Gregg N" <invalid{at}invalid.invalid>">mailto:invalid{at}invalid.invalid">invalid{at}invalid.invalid>
= wrote in=20
  message news:428e11fe$1{at}w3.nls.net...Geo=20
  wrote:> "Gregg N" <gregg{at}invalid.invalid>">mailto:gregg{at}invalid.invalid">gregg{at}invalid.invalid>
=
wrote in=20
  message> news:Xns9=
65BF11E63FA4gregginvalidinvalid{at}216.144.1.254...>>>
=

  The IP protocol allows for up to 64k datagrams, but the RFC =
only>>=20
  requires hosts to handle up to 576 octets, and says not to =
use>>=20
  larger datagrams unless you know that all the intermediate =
systems>>=20
  support it. If you control all the hops between the source =
and>>=20
  destiniation, then this is not an issue. I don't think =
this>>=20
  limitation occurs too much in practice even when you don't =
control>>=20
  the intermediate systems.>> Ok so I
take it you can be =
pretty=20
  sure this isn't what's causing the> slowness being=20
  discussed?Yes, because I don't care whether the receiver =
accepts my=20
  packets or not. I am just measuring how fast I can send them. The =
sender=20
  isn't even aware of what happens to the packets once they leave =
the=20
  computer. UDP does not have ACKs.>
Maybe fragmentation =
requires=20
  some sort of a response from the other> end that smaller non =
fragged=20
  UDP packets don't require (a function of> routers or=20
  something)?IP fragmentation does not require a response. The =
sender=20
  just splits the packet up into multiple ethernet frames with a=20
  fragmentation flag and offset set in each fragment. The recipient=20
  reassembles the fragments. If a fragment gets corrupted or lost in =

  transit, the sender is none the=20
wiser.Gregg

------=_NextPart_000_021D_01C55D24.22F6E9A0--

--- BBBS/NT v4.01 Flag-5