RE: Losing UDP packets with MFC Sockets

UDP is connectionless, as such it does not assure reliable delivery. If you
need reliably delivery of packets you need to use TCP -PERIOD-.

If your TCP/IP stack is full (for example if the cpu is bogged and your task
isn't able to keep it empty), incoming UDP packets will be discarded. The
originating end does not get notified. That is how UDP is supposed. If you
were using TCP, a negotiation would take place, the sender would get
squelched and would keep resending the packets until your end could receive
it, at which point everything would move forward again.

Frankly, I have a hell of a time hitting 100% on my CPU, even downloading,
RAR unpacking, MP3s playing and 2 virtual PCs going at the same time, so I
gotta ask what sort of system abusing tasks you've found!

Oh, incidently, changing some numbers in the TPC stack can actually make
things MUCH MUCH worse ( changing your window size for example can actually
make it impossible for the packets to get past some routers/gateways as they
don't handle larger packet windows)

Increasing the size of your buffer would merely delay the inevitable. If
your task is seriously CPU starved, you might find that you just end up with
a larger filled buffer instead of a solution.

If delivery is required, ALWAYS use TCP. If you can't use TCP for other
reasons, you might have to simulate a connection by having your sender resend
every packet until it receives an ACK in return (but you run the possibility
of the sender missing an ACK and resending a packet too)

- Clinton R. Johnson

.

Relevant Pages

  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: Old SUN NFS performance papers.
    ... > also just generally a good idea, since UDP frags act as a fixed ... > you may be copying all your packets over again ), ... With TCP, you ... >> FreeBSD NFS servers, and therefore always looking for tweaks and nobs ...
    (freebsd-performance)
  • Re: UDP vs TCP
    ... I understand that UDP doesn't guarantee proper delivery of the message, that's why we have to add the CRC to the message to check if the message received is correct. ... TCP for instance will break up a large packet into smaller ... > into the packets and then the receiving app would have to read ...
    (microsoft.public.vb.enterprise)
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)