Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UDP fragmentation

I can't think of a reason other than the "do not fragment" option.

But was it your goal to find the MTU? I think I read that in this thread. In which case UDP is not really the best choice.... You would want to use the TCP method; using ICMP to determine the max segment size, it does MTU discovery.

Despite that, what you are trying to do should work I believe. If you allow fragmentation within the IP layer, you should be able to send up to your buffer size into the UDP layer. Although having worked on hardware and software TCP/IP stacks, we usually turned off IP fragmentation, unless a firewall shutdown our ability to do MTU discovery; which some do. Your choices at that point are IP fragments of TCP segments (UGLY), assume that you can pass 1500 bytes, or go small. (In our case, actually, we were doing jumbo frames on GigE so our max transfer was 9K packets.)

Good luck,
Chris Inacio


Robert G Palmer Jr wrote:

No, UDP packet != atomic request if, by "atomic" you mean less than one MTU. See Stevens chapter 2 the description of figure 2.11. describes fragmentation - this is the process whereby a packet larger than the path MTU is broken into multiple IP packets, by the socket layer. This is done automatically. The programmer _should_ be able to pass a UDP packet to sendto() as long as that packet is less than the SO_SNDBUF size (which can be up to roughly 65000 bytes - specifically 65535-ethernet header size-IP header size) This is a perfectly acceptable process that can make programming simple in certain situations (the programmer had best understand the implications). This does work on some systems, but does not appear to work on OS X (Darwin) - I have figured out a work around, but am simply trying to understand why darwin does not work as some other linux systems and as the texts describe.

I fully understand that UDP is not normally appropriate for situations that need a reliable connection.


On Apr 29, 2004, at 9:07 PM, Henry B. Hotz wrote:

The maximum frame size on Ethernet is 1500 so 1472 sounds reasonable.

Unless your network path does not go over Ethernet for any hop then you won't do much better than that.

UDP is not an appropriate protocol to use unless your application is structured in a way that makes error recovery efficient that way, i.e. UDP packet == atomic request, and nothing bad happens if requests are repeated (because the response got lost).

On Apr 29, 2004, at 5:18 PM, email@hidden wrote:

To: email@hidden
From: Robert G Palmer Jr <email@hidden>
Subject: UDP fragmentation
Date: Thu, 29 Apr 2004 08:47:08 -0400

I'm trying to send data (actually, small files) via UDP. I initially
followed some sample Linux code and just did a sendto() using a packet
that contained the whole file (roughly 20k). I was expecting the
socket to automatically fragment the packet. In the linux code the
maximum packet size was set to roughly 57k. My sendto() consistently
failed with "message too large".

I checked the SO_SNDBUF size, it was 9216 by default. I set it to 50K,
I still got the message too large error. I verified that my SO_SNDBUF
size change had taken affect (did a getsockopt()).

I finally, by trial and error, figured out that the largest buffer I
could specify to sendto() was 1472 bytes. I have my code working now,
with my code doing the fragmenting.

The only clue I could find in documentation was this excerpt from the
sendto() man page:

[EMSGSIZE] The socket requires that message be sent
atomically,
and the size of the message to be sent made this
impossible.

The clue being the word "atomically". My guess is that darwin has the
don't fragment flag set by default.

I'm trying to understand WHY OS X (Darwin) is acting differently, by
default, from all of the other documented implementations I have seen
(certainly not an exhaustive list). Even the Steven's book indicates
that normally, the stack will perform UDP packet fragmentation. Does
anyone have any documentation/explanation or can point to any
documentation that describes this issue?

How is one supposed to dynamically (programatically) figure out the max
packet size since SO_SNDBUF seems NOT to be the correct answer? The
correct answer seems to be related to the MTU.

As I said, I have my code working now, by doing the fragmentation
myself. This has just piqued my curiosity and I'd like to understand
what is going on.

Thanks,
Robert Palmer, Jr

----------------------------------------------------------------------- -----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
email@hidden, or email@hidden

_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.