UDP packets receiving techniques! - TCP-IP

This is a discussion on UDP packets receiving techniques! - TCP-IP ; In my app i am triying to capture udp packets, but i realized that to be able to capture a a udp pack, u must know its size before u call recvfrom... or u must give a number as the ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: UDP packets receiving techniques!

  1. UDP packets receiving techniques!

    In my app i am triying to capture udp packets,
    but i realized that to be able to capture a a udp pack,
    u must know its size before u call recvfrom... or u must give a number
    as the size
    which is bigger than pcks size...

    so how a strategy can be followed to transfer variable lenght of
    packages via udp?
    ?always send a fixed size pck? i hate it....
    ?use a large number as size? worse....

    ?


  2. Re: UDP packets receiving techniques!

    "xenonysf" writes:
    > In my app i am triying to capture udp packets,
    > but i realized that to be able to capture a a udp pack,
    > u must know its size before u call recvfrom... or u must give a number
    > as the size
    > which is bigger than pcks size...
    >
    > so how a strategy can be followed to transfer variable lenght of
    > packages via udp?
    > ?always send a fixed size pck? i hate it....
    > ?use a large number as size? worse....


    Using a large number as the size is the common answer to this problem.
    The bound used is often some feature of the protocol being
    implemented. (Since we don't really know what you're doing, I doubt
    anyone can guess a size less than 65535 right now.)

    Why do you feel this answer is "worse?" Worse in what way?

    If it makes sense for your application, you might read the local
    interface list with SIOCGIFCONF and the MTUs with SIOCGIFMTU, but
    that's usually not necessary.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: UDP packets receiving techniques!


    xenonysf wrote:
    > In my app i am triying to capture udp packets,
    > but i realized that to be able to capture a a udp pack,
    > u must know its size before u call recvfrom... or u must give a number
    > as the size
    > which is bigger than pcks size...
    >
    > so how a strategy can be followed to transfer variable lenght of
    > packages via udp?
    > ?always send a fixed size pck? i hate it....
    > ?use a large number as size? worse....


    If you are keeping the data around for a long time, copy it into a
    buffer of the right size after you receive it. If you are getting rid
    of the data pretty soon, keep it in a 65,536 byte buffer, which is big
    enough for any UDP datagram.

    DS


  4. Re: UDP packets receiving techniques!


    James Carlson wrote:

    > > so how a strategy can be followed to transfer variable lenght of
    > > packages via udp?
    > > ?always send a fixed size pck? i hate it....
    > > ?use a large number as size? worse....


    > If it makes sense for your application, you might read the local
    > interface list with SIOCGIFCONF and the MTUs with SIOCGIFMTU, but
    > that's usually not necessary.


    That won't help him. UDP datagrams can exceed the MTU.

    DS


  5. Re: UDP packets receiving techniques!

    Actually, many stack implementations limit the size of UDP datagram
    that can be received and transmitted to values significantly below the
    official 0xffff size limit. The transmitter of a UDP datagram would be
    wise to limit the size of a datagram to something 8k or less if they
    want to be sure there data won't be truncated. Transmitting anything
    larger is usually unwise anyway since the UDP datagram is not
    guaranteed to be delivered.

    Why would someone try to transmit a UDP datagram that exceeds the max
    datagram size, as defined in the RFC? Who would design such a beast,
    and expect it to be received by a reasonable client?

    I think his problem lies with a misunderstanding of the API function
    call. The length passed to the recvfrom specifies the size of the
    buffer the user is passing in, so that the socket API can check to make
    sure that a memcpy of the received packet into the user supplied
    buffer won't result in overrun. Check the socket options and recv
    flags available on your system. You might be able to specify a small
    len, but chain multiple recv calls together to receive the whole
    packet.


    David Schwartz wrote:
    > James Carlson wrote:
    >
    > > > so how a strategy can be followed to transfer variable lenght of
    > > > packages via udp?
    > > > ?always send a fixed size pck? i hate it....
    > > > ?use a large number as size? worse....

    >
    > > If it makes sense for your application, you might read the local
    > > interface list with SIOCGIFCONF and the MTUs with SIOCGIFMTU, but
    > > that's usually not necessary.

    >
    > That won't help him. UDP datagrams can exceed the MTU.
    >
    > DS



  6. Re: UDP packets receiving techniques!


    James Carlson wrote:

    >
    > Why do you feel this answer is "worse?" Worse in what way?


    Actually after some surf i uderstand that this is the easiest (maybe
    best) way.
    Since my app wont send udp pcks with the size more than 2k (i plan like
    this; but the usual size is 1k) i defined a buffer with the size 4k and
    give that buffer with the size 4k to
    recvfrom.. i think it will work...
    (i am still implementing my class, i havent tried this yet...)

    > If it makes sense for your application, you might read the local
    > interface list with SIOCGIFCONF and the MTUs with SIOCGIFMTU, but
    > that's usually not necessary.


    I am not that good at sockets .. but maybe u can offer me a network
    programming book ? i have just started program network apps and i am a
    newbei about it yet... Also
    i welcome your offers about it...

    > James Carlson, KISS Network
    > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677



  7. Re: UDP packets receiving techniques!


    baringforge@gmail.com wrote:

    > Why would someone try to transmit a UDP datagram that exceeds the max
    > datagram size, as defined in the RFC? Who would design such a beast,
    > and expect it to be received by a reasonable client?


    No one tries stg like that

    > Check the socket options and recv
    > flags available on your system. You might be able to specify a small
    > len, but chain multiple recv calls together to receive the whole
    > packet.


    Instead of this solution, giving a large len seemed to me better....


  8. Re: UDP packets receiving techniques!

    "David Schwartz" writes:

    > James Carlson wrote:
    >
    > > > so how a strategy can be followed to transfer variable lenght of
    > > > packages via udp?
    > > > ?always send a fixed size pck? i hate it....
    > > > ?use a large number as size? worse....

    >
    > > If it makes sense for your application, you might read the local
    > > interface list with SIOCGIFCONF and the MTUs with SIOCGIFMTU, but
    > > that's usually not necessary.

    >
    > That won't help him. UDP datagrams can exceed the MTU.


    "If it makes sense for your application."

    It's completely unclear to me what his application might be or what
    his needs might be. It's something only the original poster can
    figure out.

    Note that my _first_ answer, which you trimmed from your follow-up,
    was a simple and clear 65535.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  9. Re: UDP packets receiving techniques!

    "xenonysf" writes:
    > James Carlson wrote:
    >
    > >
    > > Why do you feel this answer is "worse?" Worse in what way?

    >
    > Actually after some surf i uderstand that this is the easiest (maybe
    > best) way.
    > Since my app wont send udp pcks with the size more than 2k (i plan like
    > this; but the usual size is 1k) i defined a buffer with the size 4k and
    > give that buffer with the size 4k to
    > recvfrom.. i think it will work...
    > (i am still implementing my class, i havent tried this yet...)


    I don't quite understand why you'd need a 4K buffer to receive a 2K
    message.

    UDP will deliver you just one packet at a time. You don't have to
    plan for more than that.

    For what it's worth, there is some common practice here:

    - If the maximum packet defined by the protocol you're using is
    (say) 2000 bytes, then allocate a buffer that's actually 2001
    bytes and use that. If the return size is 2001, then you know
    that the input datagram was larger than the maximum packet you
    were expecting, and you can treat this as an error.

    - You can use MSG_PEEK to read in the first few octets of the
    message. If your protocol places an indication of the length
    early in the message, then you can allocate the buffer on the fly
    and then read the full message. (Very wasteful in terms of CPU
    cycles, but might be appropriate in some cases.)

    - If you really do have variable-length messages with arbitrary
    bounds, and you can't deal with a large receive buffer, then
    perhaps UDP is the wrong answer for this application. (UDP isn't
    the right answer for _every_ design.)

    > > If it makes sense for your application, you might read the local
    > > interface list with SIOCGIFCONF and the MTUs with SIOCGIFMTU, but
    > > that's usually not necessary.

    >
    > I am not that good at sockets .. but maybe u can offer me a network
    > programming book ? i have just started program network apps and i am a
    > newbei about it yet... Also
    > i welcome your offers about it...


    The W. Richard Stevens books are very good. I recommend them.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  10. Re: UDP packets receiving techniques!


    James Carlson wrote:
    > "David Schwartz" writes:
    >
    > > James Carlson wrote:
    > >
    > > > > so how a strategy can be followed to transfer variable lenght of
    > > > > packages via udp?
    > > > > ?always send a fixed size pck? i hate it....
    > > > > ?use a large number as size? worse....

    > >
    > > > If it makes sense for your application, you might read the local
    > > > interface list with SIOCGIFCONF and the MTUs with SIOCGIFMTU, but
    > > > that's usually not necessary.

    > >
    > > That won't help him. UDP datagrams can exceed the MTU.

    >
    > "If it makes sense for your application."
    >
    > It's completely unclear to me what his application might be or what
    > his needs might be. It's something only the original poster can
    > figure out.
    >
    > Note that my _first_ answer, which you trimmed from your follow-up,
    > was a simple and clear 65535.
    >


    ok; although i have overcomed ny problem via using a large number for
    size
    (which is not bad like i have guessed) , my app does following:

    i want to trasfer large files via UDP. but i put my own packet
    structure into
    udp data section and i have my own error correction mechanism.... so
    what i have
    wanted to learn was how to grab variable sized Udp packets....


  11. Re: UDP packets receiving techniques!

    "xenonysf" writes:
    > i want to trasfer large files via UDP. but i put my own packet
    > structure into
    > udp data section and i have my own error correction mechanism.... so
    > what i have
    > wanted to learn was how to grab variable sized Udp packets....


    Why would you do this?

    TFTP already exists and works as well as such an application is bound
    to work, and TCP (ftp, http, rcp, sftp, and scp all come to mind)
    works much better.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  12. Re: UDP packets receiving techniques!

    > (Since we don't really know what you're doing, I doubt anyone can
    > guess a size less than 65535 right now.)


    I'd probably morph that to being unable to guess a size any less than
    min(SO_RCVBUF,65535) since any arriving UDP datagram larger than
    SO_RCVBUF will be discarded anyway.

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  13. Re: UDP packets receiving techniques!

    In article <1156318628.873272.94840@b28g2000cwb.googlegroups.c om>,
    "baringforge@gmail.com" wrote:

    > Why would someone try to transmit a UDP datagram that exceeds the max
    > datagram size, as defined in the RFC? Who would design such a beast,
    > and expect it to be received by a reasonable client?


    Sun. The default size of NFS read and write requests is 8KB, so NFS
    over UDP almost always has to be fragmented because the Ethernet MTU is
    1500.

    About 15 years ago I had to deal with an NFS client implementation on a
    system whose NICs couldn't buffer more than 3 or 4 back-to-back packets.
    The Sun servers would send 6 packets in rapid fire in response to a read
    request, and the client would almost always drop several of them because
    it couldn't keep up. I had to configure these clients to use a smaller
    rsize setting to avoid the problem.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  14. Re: UDP packets receiving techniques!


    James Carlson wrote:

    > Why would you do this?
    >
    > TFTP already exists and works as well as such an application is bound
    > to work, and TCP (ftp, http, rcp, sftp, and scp all come to mind)
    > works much better.


    Actually i didn't know TFTP works via using UDP... But my
    implementation shold be
    much more flexible; i mean not only files but also raw data even in one
    byte... also
    since UDP is connectionless i had to implement my own session
    is there sthg like this already?


  15. Re: UDP packets receiving techniques!


    James Carlson wrote:

    > I don't quite understand why you'd need a 4K buffer to receive a 2K
    > message.

    For future changes... I set the buffer 4K but so far we only need 2K
    pcks.
    But we can adjust pacet size later... Ok u are right we can also adjust
    buffer size
    according to packet size.... But i wanted to make it a lot bigger than
    pck size
    since when a long pck comes with the lenght more than buffer, an error
    accurs...
    But actually these are really exceptional cases, i dont think so we ll
    even use 2K pcks,
    i prefer 512b or 1K ... i dont know we ll see...

    > The W. Richard Stevens books are very good. I recommend them.

    Thanx a lot...


  16. Re: UDP packets receiving techniques!

    James Carlson wrote:

    > Note that my _first_ answer, which you trimmed from your follow-up,
    > was a simple and clear 65535.


    65509 actually: 65535 less 20 bytes for IP and 8 for UDP

  17. Re: UDP packets receiving techniques!


    Rick Jones wrote:

    > I'd probably morph that to being unable to guess a size any less than
    > min(SO_RCVBUF,65535) since any arriving UDP datagram larger than
    > SO_RCVBUF will be discarded anyway.


    I was under the impression that it was not guaranteed that SO_RCVBUF
    was measured in units of bytes of *payload* data. For example, an
    implementation could put the first 64 bytes of data in some special
    structure containing the header and only put a pointer and the rest of
    the data in the receive buffer. (Perhaps as an optimization for short
    packets.)

    I know there exist implementations where the receive buffer is not
    measured in bytes of payload data, and I was under the impression that
    the standards lawyers felt they were compliant. All that was required
    was that the receive buffer be the specified size, not that there be a
    one-to-one correspondence between received payload data and bytes in
    the receive buffer.

    DS


+ Reply to Thread