UDP PACKET LOSS - TCP-IP

This is a discussion on UDP PACKET LOSS - TCP-IP ; Dear all..... I have problem in udp packet loss in the internetwork Scenario is that.... I am running two clients in the two different series means one client in the 10 series and second client in the 20 series and ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: UDP PACKET LOSS

  1. UDP PACKET LOSS

    Dear all.....

    I have problem in udp packet loss in the internetwork

    Scenario is that....
    I am running two clients in the two different series means one client
    in the 10 series and second client in the 20 series and one server
    will be in the 10 series.

    Here first client will start sending the udp packet while server is
    running and server will register the clients id's in the list while
    client sending the packet and then server will search clients id in
    the list and it will start sending udp packet to found client id in
    the list.

    I am sending 1024 bytes udp packet to the server.

    Result I am getting is that.

    I am sending 1024 packets of 1024 bytes udp packet size and receiving
    800 packets from sever

    My problem is that while sending the packets from client to server
    udp packet loss is occuring .so I am not understanding wat is reason
    for the udp packet loss in the internet.

    My email-id:sunny.of.sunilkumar@gmail.com

    plz help me....
    Advance thanks.....



  2. Re: UDP PACKET LOSS

    On Oct 14, 5:26*am, Sunny wrote:

    > Result I am getting is that.
    >
    > I am sending *1024 packets of 1024 bytes udp packet size and receiving
    > 800 packets from sever


    How fast are you sending them?

    > My problem is that while sending the packets *from client to server
    > udp packet loss is occuring .so I am not understanding wat is reason
    > for the udp packet loss in the internet.


    There are three possibilities:

    1) Through no fault of yours, the path is just lossy. Packet loss is
    how the Internet responds to congestion.

    2) Your code has problems. TCP implements a lot of things precisely to
    mitigate packet loss. These include slow start, exponential backoff,
    transmit pacing, and so on.

    3) Your packets are too large for the path. TCP also does path MTU
    detection. If your packets fragment in two, that can almost double the
    packet loss. (If either fragment gets lost, the entire datagram cannot
    be reconstructed.)

    UDP is not for amateurs. Are you sure you need to use it?

    DS

  3. Re: UDP PACKET LOSS

    Sunny wrote:
    > I am sending 1024 packets of 1024 bytes udp packet size and
    > receiving 800 packets from sever


    UDP has no flow control.

    That means there is a "race" between your receiver and your sender.
    If the sender is faster than the receiver, the receiver's SO_RCVBUF
    will fill and you will see UDP datagrams dropped there. (Check the
    statistics one can get from netstat).

    If all you ever send at any one time is 1024 datagrams, if you make
    sure that your SO_RCVBUF is larger than 1024 datagrams of 1024 bytes
    each, plus some extra then you can eliminate that as a source of drops.

    There is also a "race" between your sender and the NIC/network. If
    the sender is faster than the NIC then the datagrams you send will be
    queued to the NIC/Driver and that queue - like the receiver's
    SO_RCVBUF - is of finite size. If there is no "intra-stack" flow
    control you may fill that queue and have datagrams dropped. How one
    checks for that is platform specific - ethtool on linux, lanadmin on
    HP-UX etc etc...

    Also, anywhere on the network between the sender and the receiver
    where there is a queue (eg in switches etc) there is the prospect of
    datagrams being dropped.

    Also, if a datagram is corrupted for whatever reason it may be dropped
    almost anywhere along the way.

    Basically, anyone writing applications using UDP must accept that
    there are _no_ guarantees. Your datagrams may simply "vanish" from
    the network. If that is a problem, then you need to implement some
    sort of mechanism to detect that the datagrams were lost. That could
    be some form of ACKnowledgement by the receiving application, perhaps
    along with timeouts in your sender awaying said ACKs. In general,
    doing many, perhaps most if not all the same things that TCP, SCTP or
    some other "reliable" protocol (*) does for you in that regard.

    rick jones

    (*) it is a common misconception that TCP (for example) guarantees
    delivery of data. What TCP actually guanatees is notification of
    probable failure to _not_ deliver data. In other words, TCP will
    try to get the data there, and if it cannot know that the data got
    there after it has tried however long it will try, it will tell
    you that it probably failed.

    --
    oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
    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...

  4. Re: UDP PACKET LOSS

    On Oct 14, 8:26*am, Sunny wrote:

    > I am sending *1024 packets of 1024 bytes udp packet size and receiving
    > 800 packets from sever
    >
    > My problem is that while sending the packets *from client to server
    > udp packet loss is occuring .so I am not understanding wat is reason
    > for the udp packet loss in the internet.


    You got some good possible loss scenarios (scenarii?). Over the big,
    messy Internet, who knows what's causing the loss.

    Might be interesting to try different things. Reduce the UDP datagram
    size. Reduce the packet rate. See how these affect the results. UDP is
    not meant to be "reliable." It's perfectly fair game for routers in
    the Internet to drop packets, e.g. when congestion occurs, and there's
    no built-in mechanism in UDP to recover from that loss.

    Bert

  5. Re: UDP PACKET LOSS

    On Oct 14, 10:55*pm, Rick Jones wrote:
    > Sunny wrote:
    > > I am sending 1024 packets of 1024 bytesudppacketsize and
    > > receiving 800 packets from sever

    >
    > UDPhas no flow control. *
    >
    > That means there is a "race" between your receiver and your sender.
    > If the sender is faster than the receiver, the receiver's SO_RCVBUF
    > will fill and you will seeUDPdatagrams dropped there. *(Check the
    > statistics one can get from netstat).
    >
    > If all you ever send at any one time is 1024 datagrams, if you make
    > sure that your SO_RCVBUF is larger than 1024 datagrams of 1024 bytes
    > each, plus some extra then you can eliminate that as a source of drops.
    >
    > There is also a "race" between your sender and the NIC/network. *If
    > the sender is faster than the NIC then the datagrams you send will be
    > queued to the NIC/Driver and that queue - like the receiver's
    > SO_RCVBUF - is of finite size. *If there is no "intra-stack" flow
    > control you may fill that queue and have datagrams dropped. *How one
    > checks for that is platform specific - ethtool on linux, lanadmin on
    > HP-UX etc etc...
    >
    > Also, anywhere on the network between the sender and the receiver
    > where there is a queue (eg in switches etc) there is the prospect of
    > datagrams being dropped.
    >
    > Also, if a datagram is corrupted for whatever reason it may be dropped
    > almost anywhere along the way.
    >
    > Basically, anyone writing applications usingUDPmust accept that
    > there are _no_ guarantees. *Your datagrams may simply "vanish" from
    > the network. *If that is a problem, then you need to implement some
    > sort of mechanism to detect that the datagrams were lost. *That could
    > be some form of ACKnowledgement by the receiving application, perhaps
    > along with timeouts in your sender awaying said ACKs. *In general,
    > doing many, perhaps most if not all the same things that TCP, SCTP or
    > some other "reliable" protocol (*) does for you in that regard.
    >
    > rick jones
    >
    > (*) it is a common misconception that TCP (for example) guarantees
    > * * delivery of data. *What TCP actually guanatees is notification of
    > * * probable failure to _not_ deliver data. *In other words, TCP will
    > * * try to get the data there, and if it cannot know that the data got
    > * * there after it has tried however long it will try, it will tell
    > * * you that it probably failed.
    >
    > --
    > oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
    > 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...


    By Sunny At sunny.of.sunilkumar@gmail.com

    Exactly UDP has no flow control..

    As ur suggestion of the race between the sender and receiver speed.I
    make sure that sender speed will be less than receiver speed.

    Realted to NIC/network card race .Nic card is having 100Mbps speed.so
    I thinink that no problem with NIC card speed.

    And also make sure that SO_RECVBUF is grater than 1024 and any other
    reason for the UDP packet loss.

    Regards
    Sunil Kumar G




  6. Re: UDP PACKET LOSS

    On Oct 14, 5:53*pm, David Schwartz wrote:
    > On Oct 14, 5:26*am, Sunny wrote:
    >
    > > Result I am getting is that.

    >
    > > I am sending *1024 packets of 1024 bytesudppacketsize and receiving
    > > 800 packets from sever

    >
    > How fast are you sending them?



    > I am sending at 170Kbps client upload speed and i m checking client upload speed and down speed with site www.speedtest.net and setting client upload speed according to that value but still i m getting packet loss and one thing one broadband connection is shared with many systems.



    > > My problem is that while sending the packets *from client to server
    > >udppacketlossis occuring .so I am not understanding wat is reason
    > > for theudppacketlossin the internet.

    >
    > There are three possibilities:
    >
    > 1) Through no fault of yours, the path is just lossy.Packetlossis
    > how the Internet responds to congestion.


    path is lossy means wat???????????????????
    >
    > 2) Your code has problems. TCP implements a lot of things precisely to
    > mitigatepacketloss. These include slow start, exponential backoff,
    > transmit pacing, and so on.
    >
    > 3) Your packets are too large for the path. TCP also does path MTU
    > detection. If your packets fragment in two, that can almost double thepacketloss. (If either fragment gets lost, the entire datagram cannot
    > be reconstructed.)



    > I agree ur possibilities execpt code problem.. iam sure no prblem in my code..


    > UDPis not for amateurs. Are you sure you need to use it?


    > Exactly udp is not good but for realtime application like video conference we have to use udp only....


    > DS




  7. Re: UDP PACKET LOSS

    On Oct 15, 12:22*am, Albert Manfredi wrote:
    > On Oct 14, 8:26*am, Sunny wrote:
    >
    > > I am sending *1024 packets of 1024 bytesudppacketsize and receiving
    > > 800 packets from sever

    >
    > > My problem is that while sending the packets *from client to server
    > >udppacketlossis occuring .so I am not understanding wat is reason
    > > for theudppacketlossin the internet.

    >
    > You got some good possiblelossscenarios (scenarii?). Over the big,
    > messy Internet, who knows what's causing theloss.
    >
    > Might be interesting to try different things. Reduce theUDPdatagram
    > size. Reduce thepacketrate. See how these affect the results.UDPis
    > not meant to be "reliable." It's perfectly fair game for routers in
    > the Internet to drop packets, e.g. when congestion occurs, and there's
    > no built-in mechanism inUDPto recover from thatloss.
    >
    > Bert


    Exactly Bert

    I tried for the 512 bytes packet size and 256 bytes packet size ..for
    the 512 bytes i m getting too less packet loss and 256 bytes packet
    size i m getting no packet loss upto 170Kbps client upload speed but i
    increase the client upload speed i m getting the packet loss.So any
    solution is there for getting the zero packet

    Plz help me.
    Thanks in advance.....

    Regards
    Sunny at sunny.of.sunilkumar@gmail.com

  8. Re: UDP PACKET LOSS

    Sunny schrieb:

    > So any
    > solution is there for getting the zero packet


    Buy the whole network connection between the two computers and configure
    all routers to not drop UDP traffic.

    Seriously: You do not have a clue about what UDP is and what it does. It
    is *explicitly* allowed that packets arrive in different order than they
    were send or that packets do not arrive at all, at the mercy of the
    routers inbetween.

    Regards,
    Johannes

    --
    "Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
    verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
    -- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
    <48d8bf1d$0$7510$5402220f@news.sunrise.ch>

  9. Re: UDP PACKET LOSS

    On Wed, 15 Oct 2008 15:51:50 +0200, Johannes Bauer wrote:
    > Sunny schrieb:
    >
    >> So any
    >> solution is there for getting the zero packet

    >
    > Buy the whole network connection between the two computers and configure
    > all routers to not drop UDP traffic.


    He may own it already. He was talking about "the internetwork" and a
    "10 series" and "20 series" -- it's not clear that it's the Internet
    we're talking about.

    On the other hand, you cannot usually own the full bandwidth even in a
    small office network either ...

    /Jorgen

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

  10. Re: UDP PACKET LOSS

    Sunny wrote:
    > Exactly UDP has no flow control..


    > As ur suggestion of the race between the sender and receiver speed.I
    > make sure that sender speed will be less than receiver speed.


    > Realted to NIC/network card race .Nic card is having 100Mbps speed.so
    > I thinink that no problem with NIC card speed.


    You also have a race with your broadband connection and the queues in
    all those devices.

    When someone says that a link/path/network/whatever is "lossy" it
    means that it is normal for packets to be lost. About the only places
    you can expect little to no packet loss is on a local LAN or intranet
    and even then there are no guarantees. If you start sending UDP
    datagrams across the Internet there _will_ be packet losses, from
    causes and places over which you have _no_ control. No matter the rate to which you limit your sends.

    Your only recourse is to make your application(s) robust in the face
    of packet losses by giving them some method to recover from it.
    Typically that would be an application-level retransmission mechanism.

    rick jones
    --
    firebug n, the idiot who tosses a lit cigarette out his car window
    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...

  11. Re: UDP PACKET LOSS

    On Oct 15, 3:09*am, Sunny wrote:

    > > 1) Through no fault of yours, the path is just lossy.Packetlossis
    > > how the Internet responds to congestion.


    > * *path is lossy means wat???????????????????


    It means that more traffic is being sent over the link than the link
    can handle. As a result, the link drops packets.

    Most senders are smart enough to realize that the link is overloaded
    (again, on the Internet, overloading is signaled by packet loss) and
    back off. But some are not that smart. They fail to detect the packet
    loss and keep blasting away at the overloaded link. These programs are
    bad net citizens.

    Is yours one of them? How do you react to the packet loss?

    DS

  12. Re: UDP PACKET LOSS

    On Oct 15, 3:18*am, Sunny wrote:

    > Exactly Bert
    >
    > I tried for the 512 bytes packet size and 256 bytes packet size ..for
    > the 512 bytes i m getting too less packet loss and 256 bytes packet
    > size i m getting no packet loss upto 170Kbps client upload speed but i
    > increase the client upload speed i m getting the packet loss.So any
    > solution is there for getting the zero packet
    >
    > Plz help me.
    > Thanks in advance.....


    Bluntly, either learn how to use UDP or stop using it.

    I think you have fallen for the myth that UDP is "faster" than TCP. If
    it was, why would anyone ever use TCP?

    TCP provides a lot of functionality that UDP does not have. This
    functionality has a cost. If you don't need some of that
    functionality, UDP can be better, because you don't pay the costs of
    functionality you don't need.

    But if you do need that functionality, but you still choose to use
    UDP, you have three choices:

    1) You can fail to implement functionality you need, and then your
    application won't work.

    2) You can implement that functionality, but not do it as well as TCP
    does it. In which case, your choice of UDP will make your application
    suck. (This seems to be where you are.)

    3) You can implement that functionality even better than TCP, because
    your a brilliant coder who can develop network protocols better than
    the dummies that designed TCP. (This is where you may think you are,
    but it's honestly not very likely.)

    TCP is carefully designed to be robust in the face of packet loss and
    it's carefully designed not to cause or contribute to packet loss
    problems. If you need this kind of functionality, you either need to
    use TCP or implement it yourself.

    DS

  13. Re: UDP PACKET LOSS

    On Oct 15, 6:18*am, Sunny wrote:

    > I tried for the 512 bytes packet size and 256 bytes packet size ..for
    > the 512 bytes i m getting too less packet loss and 256 bytes packet
    > size i m getting no packet loss upto 170Kbps client upload speed but i
    > increase the client upload speed i m getting the packet loss.So any
    > solution is there for getting the zero packet
    >
    > Plz help me.
    > Thanks in advance.....


    UDP is a protocol that is not self-regulating, unless you make it so
    at the application layer. Which means, UDP will try to ram packets
    through the network at whatever rate the source decides. It will not
    throttle back when the network is showing signs of stress.

    One thing you might do, for example, is to have the source incorporate
    a sequence number into each UDP datagram it transmits. Then have the
    destination check to see if datagrams are being lost through the
    network, by checking that sequence number in consecutive received
    packets.

    If the destination notices loss, set up a UDP flow back from
    destination to source host, to make the source slow down.

    From what you describe, it looks like, for whatever reason, your
    network is being overwhelmed. So you either use TCP, or you can add a
    throttling mechanism on top of UDP.

    By the way, as an aside, heavy amounts of UDP traffic through a
    network will affect TCP disproportionally. What happens when UDP
    creates congestion is that the UDP sources keep firing away as fast as
    they can, while TCP dutifully backs off more and more, since it
    notices a badly congested network. So UDP will notice loss, but TCP
    will slow down to a trickle.

    Bert

  14. Re: UDP PACKET LOSS

    David Schwartz wrote:
    > On Oct 15, 3:09?am, Sunny wrote:


    > > > 1) Through no fault of yours, the path is just lossy.Packetlossis
    > > > how the Internet responds to congestion.


    > > ? ?path is lossy means wat???????????????????


    > It means that more traffic is being sent over the link than the link
    > can handle. As a result, the link drops packets.


    While they are ostensibly rare these days, a lossy path could also be
    one with a non-trivial bit-error rate and so drop packets even when it
    is not saturated. That has actually become an issue for TCP
    congestion control algorithms for extremely large bandwidthXdelay
    product links - they can get to the point now that the underlying
    ass-u-me-ption that packet loss signals congestion no longer holds.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    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...

  15. Re: UDP PACKET LOSS

    In article ,
    Rick Jones wrote:

    >> Realted to NIC/network card race .Nic card is having 100Mbps speed.so
    >> I thinink that no problem with NIC card speed.


    Without measurements to determine exactly where the packets are being
    lost, one cannot say where the packets are not being lost. How has
    congestion from other applications on the host or even other hosts
    connected to the same bridge/hub/router/whatever been ruled out?
    (I would not believe tcpdump or wireshark measurements on the host
    itself unless I was familiar with the IP and packet snooping code in
    the host and so knew the common problems of self-snooping and interface
    driver error reporting are absent. That expertise is clearly absent here.)


    >When someone says that a link/path/network/whatever is "lossy" it
    >means that it is normal for packets to be lost.


    I think that in ordinary conversation, "the path is lossy" usually means
    "this path loses even more packets than other paths" or even "this path
    is probably sick because it loses so many more packets than expected."
    All paths, all networks, all NIC/Network cards, and everything else
    loses some packets. As Rick Jones wrote recently, even TCP does not
    guarantee delivery but only notification of likely delivery failure.
    His "*likely* delivery failure" covers the common case when TCP says
    the data was lost when it was in fact delivered.

    > About the only places
    >you can expect little to no packet loss is on a local LAN or intranet
    >and even then there are no guarantees.


    Rick Jones knows about out of window collisions, bad 100/10 MHz
    negotiations, bad cables, flakey heartbeat detectors, missed
    interrupts in network card drivers, bad RAM, DMA engine hiccups,
    and many other things that make guarantees of packet losses on a
    LAN like life insurance for young people. If you are young, then
    your odds might be pretty good, but they are never perfect.


    > If you start sending UDP
    >datagrams across the Internet there _will_ be packet losses, from
    >causes and places over which you have _no_ control. No matter the rate
    >to which you limit your sends.
    >
    >Your only recourse is to make your application(s) robust in the face
    >of packet losses by giving them some method to recover from it.
    >Typically that would be an application-level retransmission mechanism.


    That advice makes me cringe. It is not that it is wrong, but that so
    many people have heard or reinvented it and then followed it naively.
    Any retransmission mechanism *MUST* be strictly limited. It should
    have some sort of exponential backoff (not necessarily binary) so that
    it does not cause even more packet losses by increasing congestion. It
    must not retransmit before it is reasonable to have received an
    acknowledgement through the path given the path's current delays, which
    means that it must either wait seconds (seconds!) before each retransmission
    or continuously measure the round trip time of the path. It must
    eventually give up and stop retransmitting. Too many people think
    "retransmit" means "send again if you don't get an ack after a reasonable
    time," and define "reasonable time" as something once seen on an
    uncongested short path.


    Vernon Schryver vjs@rhyolite.com

  16. Re: UDP PACKET LOSS

    Vernon Schryver wrote:
    > In article ,
    > Rick Jones wrote:


    > >Your only recourse is to make your application(s) robust in the
    > >face of packet losses by giving them some method to recover from
    > >it. Typically that would be an application-level retransmission
    > >mechanism.


    > That advice makes me cringe.


    I'm glad I left-out the "forward error correction" mumblings

    > It is not that it is wrong, but that so many people have heard or
    > reinvented it and then followed it naively. Any retransmission
    > mechanism *MUST* be strictly limited. It should have some sort of
    > exponential backoff (not necessarily binary) so that it does not
    > cause even more packet losses by increasing congestion. It must not
    > retransmit before it is reasonable to have received an
    > acknowledgement through the path given the path's current delays,
    > which means that it must either wait seconds (seconds!) before each
    > retransmission or continuously measure the round trip time of the
    > path. It must eventually give up and stop retransmitting. Too many
    > people think "retransmit" means "send again if you don't get an ack
    > after a reasonable time," and define "reasonable time" as something
    > once seen on an uncongested short path.


    That is a very good point. I'm getting lazy in my typing

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    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...

  17. Re: UDP PACKET LOSS

    In article ,
    Rick Jones wrote:

    >I'm glad I left-out the "forward error correction" mumblings


    Those mumblings might serve better than trying to teach ARQ, congestion
    avoidance and recovery, etc.. From what the other person has said, I
    wonder if FEC wouldn't be a better sort of solution for those lost
    packets. There ought to be some free source that uses UDP and forward
    error correction. Maybe there is something here:
    http://www.google.com/search?q=udp+forward+error
    http://www.google.com/search?q=udp+FEC

    That did find
    http://tools.ietf.org/html/draft-watson-tsvwg-fec-sf-00
    --


    Vernon Schryver vjs@rhyolite.com

  18. Re: UDP PACKET LOSS

    When I was still in school (college - '84 to '88) I didn't really know
    of the existence of usenet (netnews) or at least didn't know where I
    might go (groupwise) to look for help with my homework. Probably just
    as well

    Once I started working, I started making more and more use of it.
    Over the years I have learned a _great_ deal from my own questions
    asked in usenet (as well as corrections to my incorrect assertions
    so I guess I tend to gloss-over the possibility "it might be someone's
    homework assignment."

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

  19. Re: UDP PACKET LOSS

    On Oct 15, 2:04*pm, Rick Jones wrote:

    > While they are ostensibly rare these days, a lossy path could also be
    > one with a non-trivial bit-error rate and so drop packets even when it
    > is not saturated. *That has actually become an issue for TCP
    > congestion control algorithms for extremely large bandwidthXdelay
    > product links - they can get to the point now that the underlying
    > ass-u-me-ption that packet loss signals congestion no longer holds.


    I think (hope!) that most people understand that TCP responds to
    packet loss by assuming congestion and backing off. As a result, they
    (we hope) run error correcting protocols over links with non-trivial
    bit-error rates.

    If you have an LFN with a high bit error rate, you're kind of screwed
    though. Even if you do retransmit lost/corrupt data, it may still
    arrive after TCP considers it lost based on the RTT.

    Sadly, TCP does not perfectly handle every possible real-world
    'nothing you can do about it' situation.

    The assumption that packet loss equals congestion is fairly ingrained.

    DS

  20. Re: UDP PACKET LOSS

    On Oct 15, 6:51*pm, Johannes Bauer wrote:
    > Sunny schrieb:
    >
    > > So any
    > > solution is there for getting the zeropacket

    >
    > Buy the whole network connection between the two computers and configure
    > all routers to not dropUDPtraffic.
    >
    > Seriously: You do not have a clue about whatUDPis and what it does. It
    > is *explicitly* allowed that packets arrive in different order than they
    > were send or that packets do not arrive at all, at the mercy of the
    > routers inbetween.
    >
    > Regards,
    > Johannes
    >
    > --
    > "Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
    > verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
    > * * * * *-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
    > * * * * * * * * * * * * *<48d8bf1d$0$7510$54022....@news.sunrise.ch>


    HI
    Johannes

    I know that how udp works. and if u send grater size than the MTU
    value then packet will be fragmented at router into number of packets
    if we miss the one small fragmented packet at receiver side then
    recevier will consider whole packet will loss.
    but the thing is how we can improve udp packet loss in the
    internet????????????????
    you know G-TALK(GMAIL-TALK) they are using udp packet for video
    cal........
    How they are achieving the no packet loss in the internet?????????
    ok............

    Regards
    Sunny G

+ Reply to Thread
Page 1 of 2 1 2 LastLast