Re: Losing UDP packets with MFC Sockets

Thank you very much for your response. I'll try to apply some of your
suggestions.

Vicent

"um" wrote:

> "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 ... use a seperate ring-buffer or FIFO queue of your own for the input ... ie. use critical sections or a fast locking ...
    (microsoft.public.vc.mfc)
  • Re: epoll and multiple UDP multicast streams
    ... If the queue is full, normally new packets will be dropped ... If you use multiple sockets, they each have their own receive queue. ...
    (comp.unix.programmer)
  • Re: [patch 4/10] s390: network driver.
    ... > be better to not block sockets by queueing up packets when there is ... I'd prefer either to get ENOBUFS or to have kernel drop the packet - ... we're privileged apps writing to raw sockets and/or with IP_HDRINCL, ... if the kernel is going to queue these packets without notifying ...
    (Linux-Kernel)
  • Re: Consistent performance issues at high bandwidths, UDP.
    ... all createing multiple sockets should do is use more non-paged memory ... The only difference is the number of sockets and how many packets ... and every 3.1 seconds a frame took 3.8 seconds to send. ... inconsistent frame rates caused by a periodic delay in the call ...
    (microsoft.public.win32.programmer.networks)
  • Re: Consistent performance issues at high bandwidths, UDP.
    ... The only difference is the number of sockets and how many packets I'm ... In that test each frame took 40ms to send, ... explain this massive delay, but it is at extremely regular intervals. ...
    (microsoft.public.win32.programmer.networks)