Re: Losing UDP packets with MFC Sockets

"Vicent Soler" <VicentSoler@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote
>
> We are developing a tool which uses UDP packets to receive data from a UDP
> Server. The problem we have found is that some UDP packets are being lost
> when the PC's CPU is near 100% and we think that this problem is related to
> the Window's input buffer.
>
> Any suggestion to solve this problem!! Is there any way to change the input
> buffer size of the socket and store the received packet while the PC is
> processing other data? Should we use threads to extract data from sockets?
>
> We are really worried about this problem because we can not lose so much
> packets as we do.
>
> Using more than one port, cuould solve the problem?

Depending on the requirements I would recommend the following

1) Increase each sockets internal buffer from the default 8 K to something larger
(I used 32 K)

2) use a seperate ring-buffer or FIFO queue of your own for the input
and/or output. (should handle complete "records", ie. not single characters)

3) one or more threads doing the reception and putting the rcvd data into
the input queue

4) one or more threads which processes the input queue (ie. processing the
rcvd data)

5) add your data to be sent out into the output queue (should be possible from
anywhere / any thread)

6) one or more threads which processes the output queue (ie. sending out to
socket(s))

7) use raw sockets, not the MFC wrappers, since they are in my experience not
reliable.

You need thread-safe routines, ie. use critical sections or a fast locking
mechanism, because data is shared among multiple threads.

I have used this successfully in one of my projects where realtime finance
data needs to be sent out to subscribing clients (ie. this is the server part).
Because the timing was ok, ie. no packet losses, I later even added a
data encryption, and it still is very fast and no packet loss is happening.

The key ingredients are a well defined design and "protocol", fast algorithms,
data buffering, multiple threads, and recource sharing (ie. fast locking).
And of course a compiled language; not such esoteric things like interpreted
or "managed code" stuff for such hi-speed tasks; I had used C++ (VS6).

Since you are doing "only" the client part it should suffice to perform
this just for the receiver side.



.

Relevant Pages

  • Re: Losing UDP packets with MFC Sockets
    ... >> We are developing a tool which uses UDP packets to receive data from a UDP ... Should we use threads to extract data from sockets? ... > 2) use a seperate ring-buffer or FIFO queue of your own for the input ... > data buffering, multiple threads, and recource sharing (ie. fast locking). ...
    (microsoft.public.vc.mfc)
  • Re: Possible bug in .Net 2.0 udp sockets?
    ... You won't miss any UDP packets with a buffer that large! ... R> I called BeginReceiveFrom() several times on purpose, ... If you don't do that, indeed, UDP stack can drop packets. ... it stores it in the queue. ...
    (microsoft.public.dotnet.framework)
  • Re: Performance Intel Pro 1000 MT (PWLA8490MT)
    ... driver changed to not use the braindamaged sk interrupt moderation. ... with small 50-60 byte UDP packets. ... when the tx queue fills up, the application should stop sending, at ... For transmission, with non-broken hardware and software, ...
    (freebsd-performance)
  • Re: [PATCH] 3/3 maple: update bus driver to support Dreamcast VMU
    ... Removes unneeded locking of queue of processed packets while properly ... Under what conditions will this lock be ...
    (Linux-Kernel)
  • Re: packet filter : official documentation not enought, questions remain
    ... First queue set up. ... qint is for internal traffic, qext is ... queue qint bandwidth 99% priority 2 cbq ... You have NO control over inbound packets. ...
    (comp.unix.bsd.openbsd.misc)
Loading