UDP reads/writes - TCP-IP

This is a discussion on UDP reads/writes - TCP-IP ; Suppose I have an app that does a single 3000 bytes write to a descriptor representing an UDP socket. Now I know UDP is unreliable. My question is: if there is another process that is doing a read() at the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: UDP reads/writes

  1. UDP reads/writes

    Suppose I have an app that does a single 3000 bytes write to a descriptor
    representing an UDP socket.
    Now I know UDP is unreliable. My question is: if there is another process
    that is doing a read() at the other end of the connection, reading the data
    into a 3000 bytes buffer, how many bytes of the 3000 sent by the sender
    might that process have read when its read() returns? only either 0 or
    3000, or also any number in between? (I guess the answer is the latter, but
    I want to confirm that).

    Thanks


  2. Re: UDP reads/writes

    pk wrote:
    > Suppose I have an app that does a single 3000 bytes write to a
    > descriptor representing an UDP socket.
    > Now I know UDP is unreliable. My question is: if there is another
    > process that is doing a read() at the other end of the connection,
    > reading the data into a 3000 bytes buffer, how many bytes of the 3000
    > sent by the sender might that process have read when its read()
    > returns? only either 0 or 3000, or also any number in between? (I
    > guess the answer is the latter, but I want to confirm that).


    If the read buffer is 3000 bytes or larger and the read is not interrupted,
    then a non-blocking read should return either 3000 or a negative number,
    indicating an error (such as EAGAIN on Unix systems.) I believe the read
    might also return 0 under certain circumstances (other than due to an
    interrupt.) For example, if another thread on the same process closes the
    socket.

    You shouldn't see any return value "in between" when using a large enough
    buffer.

    A 3000 byte UDP datagram will, on most networks, get fragmented but that
    fragmentation should never appear at the application layer.

  3. Re: UDP reads/writes

    On Thursday 4 September 2008 22:54, Jim Logajan wrote:

    > pk wrote:
    >> Suppose I have an app that does a single 3000 bytes write to a
    >> descriptor representing an UDP socket.
    >> Now I know UDP is unreliable. My question is: if there is another
    >> process that is doing a read() at the other end of the connection,
    >> reading the data into a 3000 bytes buffer, how many bytes of the 3000
    >> sent by the sender might that process have read when its read()
    >> returns? only either 0 or 3000, or also any number in between? (I
    >> guess the answer is the latter, but I want to confirm that).

    >
    > If the read buffer is 3000 bytes or larger and the read is not
    > interrupted, then a non-blocking read should return either 3000 or a
    > negative number, indicating an error (such as EAGAIN on Unix systems.) I
    > believe the read might also return 0 under certain circumstances (other
    > than due to an interrupt.) For example, if another thread on the same
    > process closes the socket.
    >
    > You shouldn't see any return value "in between" when using a large enough
    > buffer.
    >
    > A 3000 byte UDP datagram will, on most networks, get fragmented but that
    > fragmentation should never appear at the application layer.


    Thanks. It's true that a single UDP datagram is carried in a single IP
    packet (which might be fragmented though), so yes, "3000 or nothing" makes
    sense.

    My question comes from an experiment that I'm doing using Linux tun/tap
    interfaces connected between two hosts using UDP. I have my userland
    program that reads data from the local tun interface (1 IP packet or 1
    ethernet frame at a time) and sends it to the other end of the tunnel using
    UDP. At the other end, there is a similar program that reads the data and
    sends it to its local tun interface, where the OS will send it to the
    appropriate application.
    In essence, each UDP datagram that I send over the tunnel contains one IP
    packet or one ethernet frame (depending on whether I use tun or tap). So I
    want to make certain that the other end either gets the whole UDP datagram
    (with the included IP packet or frame) *in a single read*, or it gets
    nothing.

    What you say seems to configrm that it can indeed be done.

    Thanks


  4. Re: UDP reads/writes

    pk wrote:
    > My question comes from an experiment that I'm doing using Linux
    > tun/tap interfaces connected between two hosts using UDP. I have my
    > userland program that reads data from the local tun interface (1 IP
    > packet or 1 ethernet frame at a time) and sends it to the other end of
    > the tunnel using UDP. At the other end, there is a similar program
    > that reads the data and sends it to its local tun interface, where the
    > OS will send it to the appropriate application.
    > In essence, each UDP datagram that I send over the tunnel contains one
    > IP packet or one ethernet frame (depending on whether I use tun or
    > tap). So I want to make certain that the other end either gets the
    > whole UDP datagram (with the included IP packet or frame) *in a single
    > read*, or it gets nothing.


    I would suggest you read the man pages for the recv()/recvfrom()/recvmsg()
    calls since one of those may be more appropriate than using read() for your
    intended application. Plus, the man page info on those excludes non-
    relevant info that appears in read() that may add needless confusion when
    figuring out their behavior. Also, to make sure you see the Posix and Linux
    man pages for those system calls I recommend using the "-a" option; e.g.:

    man -a recv
    man -a recvfrom

  5. Re: UDP reads/writes

    On Thursday 4 September 2008 23:53, Jim Logajan wrote:

    > I would suggest you read the man pages for the recv()/recvfrom()/recvmsg()
    > calls since one of those may be more appropriate than using read() for
    > your intended application.


    Yes, sorry. I'm already using sendto() and recvfrom(). When I said "read" I
    meant it in a generic sense, although re-reading the messages I realize
    that in the first one I erroneously used read(), giving the impression that
    I was talking about the actual function.

    Thanks again.


  6. Re: UDP reads/writes

    On Thu, 04 Sep 2008 15:54:24 -0500, Jim Logajan wrote:
    ....
    > If the read buffer is 3000 bytes or larger and the read is not interrupted,
    > then a non-blocking read should return either 3000 or a negative number,
    > indicating an error (such as EAGAIN on Unix systems.) I believe the read
    > might also return 0 under certain circumstances (other than due to an
    > interrupt.) For example, if another thread on the same process closes the
    > socket.
    >
    > You shouldn't see any return value "in between" when using a large enough
    > buffer.


    And using the right system call, you can be told "tough luck, you
    should have been a bigger buffer" (MSGTRUNC or something). If you
    don't explicitly ask for this and the buffer is too small, you may get
    a truncated datagram, which is often worse than nothing. Been there,
    done that ...

    /Jorgen

    --
    // Jorgen Grahn \X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!

+ Reply to Thread