UDP receiver queue? - Embedded

This is a discussion on UDP receiver queue? - Embedded ; Hi. I have implemented a UDP based embedded system that receives JAUS (Joint Autonomous Unmanned Systems protocol) messages in a robot. My question is: Does the Linux IP stack queue incoming UDP messages or must I read the message to ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: UDP receiver queue?

  1. UDP receiver queue?

    Hi.

    I have implemented a UDP based embedded system that receives JAUS (Joint
    Autonomous Unmanned Systems protocol) messages in a robot. My question is:

    Does the Linux IP stack queue incoming UDP messages or must I read the
    message to clear the buffer before another message is sent to keep from
    losing messages? If some number of datagrams are queued then what is the
    default queue size/limit? Is there a way to change it?

    tanks!



  2. Re: UDP receiver queue?

    noone wrote:

    > Does the Linux IP stack queue incoming UDP messages


    yes.

    > or must I read the message to clear the buffer before another
    > message is sent to keep from losing messages?


    Depends on the message size relative to the socket buffer.

    > If some number of datagrams are queued then what is the default
    > queue size/limit?


    make a getsockopt() call with the SO_RCVBUF option against a UDP
    socket. the default/limit could differ based on distro and what the
    admin may have done via sysctl.

    > Is there a way to change it?


    setsockopt() calls up to the configured "sysctl" limits which you can
    then alter.

    just because setsockopt() returned a success status does not mean you
    got the socket buffer limit you requested, you should follow a
    setsockopt() with a getsockopt() call.

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    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...

+ Reply to Thread