Communication problem in UDP

Discussion in 'Cisco' started by Rahan, Aug 3, 2006.

  1. Rahan

    Rahan Guest

    Hi all,

    I have client/server application.
    The client is windows xp.
    The server is solaris 10.
    The switche used for client and server is catalyst 2950.

    The server send very a lot of data to the client by using UDP protocol (in
    multicast mode).

    UDP use asynchronous communication. So, the client don't send ACK to the
    server to confirm reception of packet.

    I suspect that the client ignore (too busy ?) or don't receive some packet
    (packet is lost).

    By sniffing the port of the client, How can i be sure that all UDP packets
    are received by the client. So i need to know if client lost some packet or
    no.

    With TCP, each packet is identified by sequence number. Is it possible to do
    something with UDP ?

    ThankYou very much for your help

    Best Regards
    Rahan
     
    Rahan, Aug 3, 2006
    #1
    1. Advertising

  2. In article <44d21139$0$7458$>,
    Rahan <Rahan@Rahan_badmail.com> wrote:

    >By sniffing the port of the client, How can i be sure that all UDP packets
    >are received by the client. So i need to know if client lost some packet or
    >no.


    That is difficult, as your sniffer might also lose packets unless
    the line speed is fairly slow (in which case the client should not
    lose packets either), or unless the sniffer is well designed for sniffing.

    There was a rant on this topic earlier this year,
    http://groups.google.ca/group/comp...._frm/thread/14e20fa4c87d6602/ef31aa9b43cf2f4f


    >With TCP, each packet is identified by sequence number. Is it possible to do
    >something with UDP ?


    Only with the cooperation of both sides to change the application protocol.

    If you have control over the sending machine but cannot change the
    receiver, then you could put information into the IP Options portion of
    the IP header, such as option 68 "Time Stamp" or option 136 "Stream ID".
    "Time Stamp" would seem to be a relatively good fit: for your
    purposes, increment it by 1 for each packet instead of trying to use
    some kind of real time measurement.
     
    Walter Roberson, Aug 3, 2006
    #2
    1. Advertising

  3. Rahan

    Guest

    Walter Roberson wrote:
    > In article <44d21139$0$7458$>,
    > Rahan <Rahan@Rahan_badmail.com> wrote:
    >
    > >By sniffing the port of the client, How can i be sure that all UDP packets
    > >are received by the client. So i need to know if client lost some packet or
    > >no.

    >
    > That is difficult, as your sniffer might also lose packets unless
    > the line speed is fairly slow (in which case the client should not
    > lose packets either), or unless the sniffer is well designed for sniffing.
    >
    > There was a rant on this topic earlier this year,
    > http://groups.google.ca/group/comp...._frm/thread/14e20fa4c87d6602/ef31aa9b43cf2f4f
    >
    >
    > >With TCP, each packet is identified by sequence number. Is it possible to do
    > >something with UDP ?

    >
    > Only with the cooperation of both sides to change the application protocol.
    >
    > If you have control over the sending machine but cannot change the
    > receiver, then you could put information into the IP Options portion of
    > the IP header, such as option 68 "Time Stamp" or option 136 "Stream ID".
    > "Time Stamp" would seem to be a relatively good fit: for your
    > purposes, increment it by 1 for each packet instead of trying to use
    > some kind of real time measurement.


    Sound advice.

    If you suspect lost packets he very first thing to do is to
    eliminate a duplex missmatch or other physical layer
    errors from the investigation.

    Do a show int and check for input and outpur errors.

    If you wish post the output here.

    I seem to recall that IP packets have a 16 bit
    datagram number (I have just called it).
    "Identification ( 16-bit number which together with the source address
    uniquely identifies this packet - used during reassembly of
    fragmented datagrams)

    If you are lucky your system will be incrementing it
    for each packet.
     
    , Aug 4, 2006
    #3
  4. Rahan

    Rahan Guest

    Hi all,

    Thanks a lot Walter for your answer. You are every time present to help and
    to give answer to the questions. Many thanks for this great help.

    Ok for the possibility to the sniffer to lost packet. I am using EtherReal,
    i will try to use others and compare. Well.

    I cannot change the communication btw client and server, so i cannot insert
    TAG to the packet transmited by the server.

    But, "anybody43" sended an answer which seem to be well for me. I will
    answer in fiew minutes to the same post... check the message please !! :)

    Thanks a lot

    Best Regards
    Rahan


    "Walter Roberson" <> a écrit dans le message de
    news:OApAg.314824$IK3.7384@pd7tw1no...
    > In article <44d21139$0$7458$>,
    > Rahan <Rahan@Rahan_badmail.com> wrote:
    >
    > >By sniffing the port of the client, How can i be sure that all UDP

    packets
    > >are received by the client. So i need to know if client lost some packet

    or
    > >no.

    >
    > That is difficult, as your sniffer might also lose packets unless
    > the line speed is fairly slow (in which case the client should not
    > lose packets either), or unless the sniffer is well designed for sniffing.
    >
    > There was a rant on this topic earlier this year,
    >

    http://groups.google.ca/group/comp...._frm/thread/14e20fa4c87d6602/ef31aa9b43cf2f4f
    >
    >
    > >With TCP, each packet is identified by sequence number. Is it possible to

    do
    > >something with UDP ?

    >
    > Only with the cooperation of both sides to change the application

    protocol.
    >
    > If you have control over the sending machine but cannot change the
    > receiver, then you could put information into the IP Options portion of
    > the IP header, such as option 68 "Time Stamp" or option 136 "Stream ID".
    > "Time Stamp" would seem to be a relatively good fit: for your
    > purposes, increment it by 1 for each packet instead of trying to use
    > some kind of real time measurement.
     
    Rahan, Aug 4, 2006
    #4
  5. Rahan

    Rahan Guest

    ThankYou very much anybody43 for your answer !!

    I confirm that i don't have any errors on the interface of my Cisco switch
    (sh int | include errors).

    I confirm that the "identification" of the UDP packet is incrementing. For
    exemple :

    .... > 0xe002 > 0xe003 > 0xe004 > 0xe005 > 0xe006 > 0xe007 > 0xe008 > 0xe009
    > 0xe00a > 0xe00b > 0xe00c > 0xe00d > 0xe00e > 0xe00f > 0xe010 > 0xe011 >

    0xe012 > 0xe013 > 0xe014 > 0xe015 > 0xe016 > 0xe017 > 0xe018 > 0xe019 >
    0xe01a > 0xe01b > 0xe01c > ...

    Can you confirm please that this "identification" is unique and i can check
    it to be sure if some UDP packet are lost ?


    In the same time, under client Windows (XP sp2), when i run "netstat -es" i
    have a lot of "Received Address Errors". This counter is incrementing and i
    don't know why !! By analizing my sniffer, i don't have any problem around
    Address of the sender or receiver !!

    In the same client, i stopped "flow control", i stopped "checksum offload"
    and i disabled QOS on the NIC and the counter of "Received Address Errors"
    is always incrementing !! I changed the cable and the network card (broadcom
    to 3com) and i experimented the same problem.

    I reminder you that data sended by the server to the client is in multicast
    (udp) and i am sure that the client is always in the multicast group and
    never leave this group and the client always recevive the data to the
    multicast group.

    Any idea about this question please ?

    Thank You very much

    Best Regards
    Rahan


    <> a écrit dans le message de
    news:...
    >
    > Sound advice.
    >
    > If you suspect lost packets he very first thing to do is to
    > eliminate a duplex missmatch or other physical layer
    > errors from the investigation.
    >
    > Do a show int and check for input and outpur errors.
    >
    > If you wish post the output here.
    >
    > I seem to recall that IP packets have a 16 bit
    > datagram number (I have just called it).
    > "Identification ( 16-bit number which together with the source address
    > uniquely identifies this packet - used during reassembly of
    > fragmented datagrams)
    >
    > If you are lucky your system will be incrementing it
    > for each packet.
    >
     
    Rahan, Aug 4, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom
    Replies:
    2
    Views:
    5,366
  2. Replies:
    0
    Views:
    1,556
  3. Hannie

    PCI Communication device problem

    Hannie, Apr 11, 2005, in forum: Computer Support
    Replies:
    2
    Views:
    6,836
    Guest
    Apr 11, 2005
  4. Michael Petereit

    UDp communication over 836

    Michael Petereit, Sep 26, 2006, in forum: Cisco
    Replies:
    0
    Views:
    342
    Michael Petereit
    Sep 26, 2006
  5. jacsim

    Communication problem

    jacsim, Oct 21, 2006, in forum: General Computer Support
    Replies:
    1
    Views:
    663
    JimmyD
    Oct 21, 2006
Loading...

Share This Page