polling - Embedded

This is a discussion on polling - Embedded ; To put it briefly, can we use polling to find whether UDP packets are being dropped at the UDP socket buffer? If so how ?...

+ Reply to Thread
Results 1 to 11 of 11

Thread: polling

  1. polling


    To put it briefly,
    can we use polling to find whether UDP packets are being dropped at the
    UDP socket buffer? If so how ?


  2. Re: polling


    Guddu wrote:
    > To put it briefly,
    > can we use polling to find whether UDP packets are being dropped at the
    > UDP socket buffer? If so how ?


    You have UDP all wrong, it is really only useful for talking to a lot
    of clients at once. For example if you want to push the same file out
    to 20 machines, in theory UDP is 20 times faster than with "normal"
    TCP/IP communications. (Theory only because UDP drops packets like a
    dog).

    To make things work you need to find a way to let the receivers know
    what they should be expecting, and than have a way for the receivers to
    notify the sender that they missed a packet. So number and checksum
    each packet, and send a 'header' packet with the total packet count.
    Thain each client will keep track of what packets they received and
    after a fixed interval they will begin re-requesting the missing
    packets (requests can be done without UDP for reliability). Thain the
    server queues up requests and after a fixed interval UDP's the lost
    packets only to the receivers that lost the packets. Keep iterating
    until everyone has everything. Once you are down to a few clients and
    a few packets you can switch away from UDP and blast the remaining
    packets through more reliable methods if you want to truncate the long
    tail of errors. The first time out you will give 80% of the data to 80%
    of the clients and it will degrade quickly form there...

    Also you are probably doing to much with your packets at receive time.
    Just retrieve them from the UDP listener and move them to a queue.
    Your machine is way faster than the measly 100MBit/sec UDP can can
    achieve so you should be able to keep up with it just fine. Spawn
    another thread to handle the data, or deal with it later if it is not
    to large.

    If that does not work, by a better router/switch. Some of the cheaper
    ones have a hard time with UDP in general.

    David Tucker


  3. Re: polling


    wrote in message
    news:1163172565.412885.214860@b28g2000cwb.googlegr oups.com...
    >
    > Guddu wrote:
    >> To put it briefly,
    >> can we use polling to find whether UDP packets are being dropped at the
    >> UDP socket buffer? If so how ?

    >
    > You have UDP all wrong, it is really only useful for talking to a lot
    > of clients at once. For example if you want to push the same file out
    > to 20 machines, in theory UDP is 20 times faster than with "normal"
    > TCP/IP communications. (Theory only because UDP drops packets like a
    > dog).
    >

    You're talking about UDP broadcasts here? I think UDP is useful in many
    other applications where the overhead of TCP is problematic.

    [snip]
    >
    > Also you are probably doing to much with your packets at receive time.
    > Just retrieve them from the UDP listener and move them to a queue.
    > Your machine is way faster than the measly 100MBit/sec UDP can can
    > achieve so you should be able to keep up with it just fine. Spawn
    > another thread to handle the data, or deal with it later if it is not
    > to large.
    >

    Totally agree about the queue thing but how do you know his machine is that
    fast? This is .embedded so it's possible he has a pretty wimpy processor. I
    know I do.

    Andrew



  4. Re: polling

    david.tucker@goliathindustries.com wrote:

    > You have UDP all wrong, it is really only useful for talking to a lot
    > of clients at once. For example if you want to push the same file out
    > to 20 machines, in theory UDP is 20 times faster than with "normal"
    > TCP/IP communications. (Theory only because UDP drops packets like a
    > dog).


    This is very misleading. UDP doesn't inherently drop packets, that
    depends on the underlying transport. On a good network with sufficiently
    powerful machines there will be zero packet loss. On a lossy network,
    even TCP/IP performance will suffer due to the retransmits. You can't
    get something for nothing.

    The correct way to put it is that UDP provides no delivery guarantees.

    > If that does not work, by a better router/switch. Some of the cheaper
    > ones have a hard time with UDP in general.


    Weird suggestion, there. A switch certainly does not care about anything
    above the ethernet layer so why would it care about UDP ? Even routers
    are mostly concerned with the IP layer only.

  5. Re: polling

    rTrenado wrote:

    > There is however one way (that I am familiar with) to know if packets
    > are being lost on a specific UDP port.
    >


    Which way is that?

  6. Re: polling

    VJ wrote:
    > rTrenado wrote:
    >
    >> There is however one way (that I am familiar with) to know if packets
    >> are being lost on a specific UDP port.
    >>

    >
    > Which way is that?


    Monitor UDP stats via SNMP.


    Dave

  7. Re: polling


    rTrenado wrote:
    > UDP stands for User Datagram Protocol, its main goal is to send
    > messaged with a minimum of protocol mechanism, and the delivery and
    > duplicate protection are not guaranteed. So, if packets are being lost
    > or "dropped" it is because something is happening on the transpport,
    > network or phy layers of the local client (or remote host for that
    > matter). Transport is where UDP is located, and if the receiver is not
    > getting UDP messages from a remote host it is possibly that the client
    > did not bind correctly to the UDP port to listen. If the problem is at
    > the network layer it could be because the remote host cannot reach the
    > UDP client. On the physical, well... maybe ARP is not working on the
    > client side (if it is ethernet of course)... I am just guessing...
    >
    > So the answer is, if the UDP data is on the socket buffer it means that
    > the UDP packet made it to the receiver end and it was not dropped. If
    > it is in fact dropped you dont get anything out of the socket buffer
    > for that packet.
    >
    > There is however one way (that I am familiar with) to know if packets
    > are being lost on a specific UDP port.
    >


    Hi ,
    Please tell me what is the way to know if packets are being lost on a
    specific UDP Port. netstat can tell about all UDP packets dropped at
    all the ports.
    If I can find if packets are being dropped at the specific port, my
    purpose would be solved.

    Regards,
    Vishal

    > Rene
    >
    >



  8. Re: polling

    > If I can find if packets are being dropped at the specific port, my
    > purpose would be solved.


    What do you mean by "packets being dropped at the specific port" ? If a
    packet gets lost in the transport, the receiving port/machine sees
    nothing of it and the sending port/machine never knows that it did not
    reach the destination. So there is _no_ way to detect the loss. (Unless
    a higher protocol is established that performs a handshake. But this is
    not "UDP" but something that _uses_ UDP).

    -Michael

  9. Re: polling

    rTrenado wrote:
    > To find out if packet are being dropped the easiest way is to create a
    > script and poll netstat.


    How should netstat know about lost packets ? A UDP packet is delivered
    without any acknowledgment by the receiver. So the loss of a packet
    can't be detected at all, unless some higher level protocol is k known
    to the detector.

    -Michael

  10. Re: polling

    rTrenado wrote:
    > netstat will tell you what UDP ports are in listening mode, plus it
    > will tell you how many packets were lost at the time you call it.


    Of course it does tell you how many packets arrived at this port, but as
    it does not know how many were sent to that port (possibly from multiple
    other computes), it can't tell you how many were lost.

    -Michael

  11. Re: polling

    > I was referring to
    > dropped packets.


    OK. I suppose dropped packets are those received by the IP stack from
    the wire that were not digested by the software that requested opening
    the port. I don't know what this number is useful or other than for
    debugging the local software.

    -Michael

+ Reply to Thread