Re: Losing UDP packets with MFC Sockets

AliR,

Are you saying that in the input buffer I read from ReceiveFrom could exist
more than one packet?? I've always thoght that after receiven one
notificication I'm nly processing one packet....

Vicent

"AliR" wrote:

> You still didn't answer the question. Is this senerio being handled
> correctly?
>
> Say the sending process sends out 3 packets of 20 bytes each, while your
> receiving process is busy doing other things.
> Your receiving process does a Receive with a buffer of 100 bytes the next
> time it gets a OnReceive notificaiton. Which will receive all 60 bytes worth
> of data.
> Is the data parsed out so that all three packets gets processed?
>
> AliR.
>
> "Vicent Soler" <VicentSoler@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:E82253A2-68DE-4A12-A438-5F099772D37F@xxxxxxxxxxxxxxxx
> > Hi AliR,
> >
> > This is the process to retrieving data from socket's buffer:
> >
> > 1.- After OnReceive method, a call to ReceiveFrom method is done.
> >
> > 2.- A CByteArray object is creating with 'new' with data received from
> buffer.
> >
> > 3.- The CByteArray is passed to an internal list of the socket class which
> > is later accesed by other classes.
> >
> > 4.- The process ends after sending a Windows' message to the respective
> > class to indicate the packet arrival.
> >
> > As you can see, we always try to avoid being excesive time in the
> OnReceive
> > method. We will try to introduce threads in the process in order to solve
> the
> > problem.
> >
> > Thanks
> >
> > Vicent
> >
> > "AliR" wrote:
> >
> > > This might have to do with the way you are handeling your message
> retrieval
> > > from the receive buffer, are you handeling receiving multiple message in
> a
> > > single read?
> > >
> > > AliR.
> > >
> > > "Vicent Soler" <VicentSoler@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> > > news:3AAE5247-76AB-43A3-912A-61177FAA3A49@xxxxxxxxxxxxxxxx
> > > > Responses below....
> > > >
> > > > "Michael K. O'Neill" wrote:
> > > >
> > > > > Please give us some more information about your UDP usage (e.g.,
> packet
> > > > > size, frequency etc). IIRC, CPU load is not the main culprit in UDP
> > > packet
> > > > > loss; rather, it's network load.
> > > >
> > > >
> > > > The UDP packet size is variable but usually it can be around 50-300
> bytes.
> > > > The frequency is also difficult to calculate because the UDP Server
> send
> > > > messages using event triggers. As far as we could understand, the
> main
> > > > problem is when the UDP Client is using lot of CPT time. Then it seems
> > > that
> > > > the input buffer is being overload and packets are being discarded.
> > > >
> > > >
> > > > > The usual way to reduce UDP packet loss is to favor smaller and more
> > > > > frequent packets over larger and infrequent packets. It is often
> said
> > > that
> > > > > packets around the size of the MTU are best. Also, reduce the send
> > > buffer
> > > > > size and increase the receive buffer size.
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > "Vicent Soler" <VicentSoler@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message
> > > > > news:9758AB39-50C0-4750-8F48-2F5399232EEA@xxxxxxxxxxxxxxxx
> > > > > > Hi all,
> > > > > >
> > > > > > 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?
> > > > > >
> > > > > > Thanks in advance,
> > > > > >
> > > > > > Vicent
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
.

Relevant Pages

  • Re: Fundamentals question, is this how it works?
    ... Note the packet may be partially received when you get ... That is what i thought i was saying that it receives it all in a stream ... receving the buffer size each time. ... receiving that many bytes i then break and wait for the next set of data ...
    (microsoft.public.win32.programmer.networks)
  • Re: Fundamentals question, is this how it works?
    ... Microsoft MVP, MCSD ... Knowin when that second packet started is my problem. ... stream receving the buffer size each time. ... then the receiving side might ...
    (microsoft.public.win32.programmer.networks)
  • Re: Fundamentals question, is this how it works?
    ... You maintain a buffer for the last incomplete packet. ... receiving that many bytes i then break and wait for the next set of data ... With a tcp stream socket what happens when it is reading say 4000bytes ...
    (microsoft.public.win32.programmer.networks)
  • Re: xPC Serial Communication Problems
    ... Everything about the packet looks just fine, ... reasonable facsimile) so the hardware buffer should be 16 bytes. ... Is the receiving machine executing at the 'same' 50 ms rate? ... does it wait until there are at least 15 characters in the receive ...
    (comp.soft-sys.matlab)
  • Re: Actius MM10 modem
    ... telling me that "pppd exited with return value ... call retry delay timer expires) without waiting for an outbound packet. ... Shut down the link when idle-time seconds pass without receiving or ... The environment variable PPPHOME, if present, specifies the directory in ...
    (comp.os.linux.portable)