Can this UDP transmission block? - TCP-IP

This is a discussion on Can this UDP transmission block? - TCP-IP ; Hello I have a small send_udp_packet() routine. My question is: Can it block/hang? On a TCP connection I guess that the connect() and send() calls can block, and therefore timeouts are needed to prevent this. But what about UDP? bool ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Can this UDP transmission block?

  1. Can this UDP transmission block?

    Hello

    I have a small send_udp_packet() routine.
    My question is: Can it block/hang?

    On a TCP connection I guess that the connect() and send() calls can
    block,
    and therefore timeouts are needed to prevent this. But what about UDP?




    bool send_udp_packet ( struct sockaddr_in srv_addr, unsigned char
    *buff, int len )
    {
    SOCKET skt;

    if ( (skt = socket(PF_INET, SOCK_DGRAM, 0)) == INVALID_SOCKET)
    return false;
    else
    {
    if ( connect(skt, (const struct sockaddr FAR*)&srv_addr,
    sizeof(srv_addr) ) == SOCKET_ERROR )
    return false;
    else
    send( skt, buff, len, 0 );
    }

    close(skt);

    return true;
    }


    Regards
    /Peter/

  2. Re: Can this UDP transmission block?


    Peter.Jolas...@gmail.com wrote:

    > Hello
    >
    > I have a small send_udp_packet() routine.
    > My question is: Can it block/hang?
    >
    > On a TCP connection I guess that the connect() and send() calls can
    > block,
    > and therefore timeouts are needed to prevent this. But what about UDP?


    I have never known an implementation where a single packet being sent
    on a new socket would block. However, it's possible some
    implementation might block on the 'connect' if there were no route to
    the destination. Why not avoid the problem by simply setting the
    socket non-blocking?

    If the overhead is an issue (it would be an extra system call), why
    not skip the connect, use sendmsg, and re-use the socket?

    DS

  3. Re: Can this UDP transmission block?

    In article
    <99a807cb-0306-4831-98b1-24aa47e5f4d1@l64g2000hse.googlegroups.com>,
    Peter.Jolasson@gmail.com wrote:

    > Hello
    >
    > I have a small send_udp_packet() routine.
    > My question is: Can it block/hang?
    >
    > On a TCP connection I guess that the connect() and send() calls can
    > block,
    > and therefore timeouts are needed to prevent this. But what about UDP?


    As the other poster said, it's unlikely that the first packet on a new
    socket would block. But just in case, why don't you set the socket
    non-blocking? Then it should be guaranteed not to block.

    >
    >
    >
    >
    > bool send_udp_packet ( struct sockaddr_in srv_addr, unsigned char
    > *buff, int len )
    > {
    > SOCKET skt;
    >
    > if ( (skt = socket(PF_INET, SOCK_DGRAM, 0)) == INVALID_SOCKET)
    > return false;
    > else
    > {
    > if ( connect(skt, (const struct sockaddr FAR*)&srv_addr,
    > sizeof(srv_addr) ) == SOCKET_ERROR )
    > return false;
    > else
    > send( skt, buff, len, 0 );
    > }
    >
    > close(skt);
    >
    > return true;
    > }
    >
    >
    > Regards
    > /Peter/


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

  4. Re: Can this UDP transmission block?

    In article ,
    Barry Margolin wrote:
    >In article
    ><99a807cb-0306-4831-98b1-24aa47e5f4d1@l64g2000hse.googlegroups.com>,
    > Peter.Jolasson@gmail.com wrote:
    >
    >> Hello
    >>
    >> I have a small send_udp_packet() routine.
    >> My question is: Can it block/hang?
    >>
    >> On a TCP connection I guess that the connect() and send() calls can
    >> block,
    >> and therefore timeouts are needed to prevent this. But what about UDP?

    >
    >As the other poster said, it's unlikely that the first packet on a new
    >socket would block. But just in case, why don't you set the socket
    >non-blocking? Then it should be guaranteed not to block.


    Pure conjecture, but I suppose the first packet could block while the
    stack does the ARP? And if the peer isn't out there, the ARP would
    take a while to fail. It all depends on how the stack is implemented.

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ================================================== ==========================

  5. Re: Can this UDP transmission block?

    David Schwartz writes:

    >If the overhead is an issue (it would be an extra system call), why
    >not skip the connect, use sendmsg, and re-use the socket?


    Random point -- it used to be that calling sendmsg was more expensive
    than connect() followed by send() provided that you called send() more
    than once.

    That's because to do a sendmsg() you have to do all the sanity checks
    that connect() does -- and, indeed, most implementations simply made sendmsg()
    into an internal connect(), send(), disconnect() sequence.

    Craig

  6. Re: Can this UDP transmission block?

    On Thu, 12 Jun 2008 13:53:30 +0000 (UTC), Craig Partridge wrote:
    > David Schwartz writes:
    >
    >>If the overhead is an issue (it would be an extra system call), why
    >>not skip the connect, use sendmsg, and re-use the socket?

    >
    > Random point -- it used to be that calling sendmsg was more expensive
    > than connect() followed by send() provided that you called send() more
    > than once.
    >
    > That's because to do a sendmsg() you have to do all the sanity checks
    > that connect() does -- and, indeed, most implementations simply made sendmsg()
    > into an internal connect(), send(), disconnect() sequence.


    Do you use past tense because you know it isn't true in in current UDP
    implementations, or because you do not know the status today?

    I still assume sending on connect()ed UDP sockets is faster. And if I
    recall correctly, I think I've read the Linux UDP code and seen how it
    caches routing information if you connect.

    /Jorgen

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

  7. Re: Can this UDP transmission block?

    Jorgen Grahn writes:

    >On Thu, 12 Jun 2008 13:53:30 +0000 (UTC), Craig Partridge wrote:
    >> David Schwartz writes:
    >>
    >>>If the overhead is an issue (it would be an extra system call), why
    >>>not skip the connect, use sendmsg, and re-use the socket?

    >>
    >> Random point -- it used to be that calling sendmsg was more expensive
    >> than connect() followed by send() provided that you called send() more
    >> than once.
    >>
    >> That's because to do a sendmsg() you have to do all the sanity checks
    >> that connect() does -- and, indeed, most implementations simply made sendmsg()
    >> into an internal connect(), send(), disconnect() sequence.


    >Do you use past tense because you know it isn't true in in current UDP
    >implementations, or because you do not know the status today?


    Past tense because I don't know the current implementations in enough
    detail to know if the claim is still true.

    Thanks!

    Craig

  8. Re: Can this UDP transmission block?

    In article ,
    pklos@osmium.mv.net (Patrick Klos) wrote:

    > In article ,
    > Barry Margolin wrote:
    > >In article
    > ><99a807cb-0306-4831-98b1-24aa47e5f4d1@l64g2000hse.googlegroups.com>,
    > > Peter.Jolasson@gmail.com wrote:
    > >
    > >> Hello
    > >>
    > >> I have a small send_udp_packet() routine.
    > >> My question is: Can it block/hang?
    > >>
    > >> On a TCP connection I guess that the connect() and send() calls can
    > >> block,
    > >> and therefore timeouts are needed to prevent this. But what about UDP?

    > >
    > >As the other poster said, it's unlikely that the first packet on a new
    > >socket would block. But just in case, why don't you set the socket
    > >non-blocking? Then it should be guaranteed not to block.

    >
    > Pure conjecture, but I suppose the first packet could block while the
    > stack does the ARP? And if the peer isn't out there, the ARP would
    > take a while to fail. It all depends on how the stack is implemented.


    Anything's possible, but this seems unlikely. Any reasonable stack
    would buffer the packet and return immediately, and THEN start arping.
    Blocking should only ever be necessary to wait for buffer space, not for
    the network.

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

  9. Re: Can this UDP transmission block?

    On Jun 12, 8:24*pm, Barry Margolin wrote:

    > Anything's possible, but this seems unlikely. *Any reasonable stack
    > would buffer the packet and return immediately, and THEN start arping. *
    > Blocking should only ever be necessary to wait for buffer space, not for
    > the network.


    For UDP, the tradition has been to never block on send. But if you
    block for buffer space, then a UDP send could block because the buffer
    for the network device the datagram is going to be sent on is full.
    Every stack I know of simply drops the datagram in this case.

    I think with enough effort I could imagine situations where a
    reasonable stack might choose to block. But again, no actual stack in
    existence that I know of does this. Still, I think there's a consensus
    that you should simply set the socket non-blocking just to be safe.

    I think I have a good argument that the 'connect' can never block. If
    the 'connect' could block, that would mean a non-blocking UDP
    'connect' could return EWOULDBLOCK. But what could you conceivably do
    in this case? You cannot call 'select' for either reading or writing
    because both of those operations have different semantics already
    defined.

    DS

  10. Re: Can this UDP transmission block?

    Hi,

    From what you all say I've come to the conclusing that I should make
    the socket non-blocking. There is no reasone for not doing so.

    I've got appr. 200 embedded linux unit running and once every 3-4
    months someone of these will hang one if it's threads. The thread is
    very small so I cannot think of anything else but this UDP
    transmission that would hang it.

    I will make the socket non-blocking and hopefully my problems
    disaperes. [at least for 3-4 months ]

    Thankyou for all replies

    /Peter/

  11. Re: Can this UDP transmission block?


    I am not familiar with all the preconditions (connected vs not, send
    vs sendmsg) but have noticed while running netperf UDP_STREAM tests
    (which does not enable non-blocking) with systems where the CPU was
    much faster than the network that at least two stacks have
    "intra-stack" flow control - Linux and Solaris. This shows-up as
    netperf UDP_STREAM not going any faster than the link from the sending
    side statistics without there being any failed sends indicated.

    --
    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