Re: UDP network problem
kwrohrer@enteract.com
Mon, 18 Aug 1997 07:42:16 -0500 (CDT)
And lo, Richard B. Johnson saith unto me:
> On Sun, 17 Aug 1997 kwrohrer@enteract.com wrote:
> > And lo, mshar@vax.ipm.ac.ir saith unto me:
> > > Thanks for the recommendation to use TCP. Actually I want to use UDP in
> > > a system called DIPC (Distributed Inter-Process Communication.) It already
> > >has TCP support. The main attraction of UDP is its speed in sending smaller
> > > and independent packets.
> > >
> > > My real problem, however, is that I could not send more than 3250 bytes
> > > ever! Not a single time. It is hard to attribute such a consistent error
> > > with transient reasons. I've had very little difficulty with 3250 and
> > > less amounts of data (a 57600 bps point-to-point connection is not very
> > > noisy, or very speedy for a 486 to handle).
> > >
> > > Could there be an inherent limitation in the kernel or other user-space
> > > networking code?
> > I've had no problems sending UDP packets as large as 8k (payload) over
> > loopback and (ne2000) ethernet, on kernel 2.1.29. My only problem was
> > that sometimes some data would never arrive at the receiver, even using
> > TCP, even when no sends returned errors...I chalked it up to a bug in
> > my code, though the losses did coincide with "socket destroy delayed"
> > messages. I figure it's been fixed by now, but have been too wary of
> > the new "kernels" to actually try one.
> >
> > Anyway, try running the "far end" on the same machine, and see if that
> > changes anything...
> Isn't there a maximum allowed packet length of 1500 bytes on Ethenet??
> Doesn't this confine the maximum data area to about 1480 bytes to leave
> room or the header?? You can't fragment UDP so, as I understand it, you
> should never be able to send more than 1480 bytes on UDP. Or am I missing
> something?? Have the Specs changed? Can you now blast through anything??
AFAIK there is a maximum UDP packet size in the vicinity of 8-9k payload.
However, like TCP, it leaves fragmentation (or the lack thereof) to the IP
and lower layers. The hardware MTU is largely irrelevant.
> If so, most Ethernet drivers won't handle it because the shared RAM is
> usually cut up into buffers that assume 1500 bytes max (actually 2048 on
> some that can only a set "pages").
I'm sure once you get far enough down the protocol layers to reach the
parts which know devices with a finite MTU are being used, you get frag-
mentation to conform to that MTU.
> If you can now blast through anything, something is broken. I sure would
> not like to see 8k packet lenghts on my LAN. This would monopolize the
> LAN and prevent complient packets from getting their fair share on the
> wire.
As someone pointed out, 4k (and 8k!) UDP packets for NFS are commonplace,
if not Linux's nfs client's default.
Keith