Messages in this thread | | | Subject | Re: UDP network problem | Date | Mon, 18 Aug 1997 07:42:16 -0500 (CDT) | From | kwrohrer@enteract ... |
| |
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
| |