"Silvia" <silvia@correo.com> wrote in message
news:449901ed$1@newsgroups.borland.com...
> Processing for me means that I am inserting information in a
> database and I am looking for some information in some tables.
My guess, then, would be that your processing is a time consuming operation,
and that the UDP data is being lost because you are not reading it fast
enough. Have you considered moving your operations into another thread so
that you can remove data from the socket faster? You could copy the UDP
data into a queue for the operations thread to process at its leisure.
> Then I see how the information is saved and I see that
> I have saved correctly the first 228 frames but after that a
> lot of datagrams have been lost from 2000 frames I have
> only saved 284.
How large are your packets to begin with? If you don't read the socket fast
enough, you are likely filling up the socket's internal buffers, so it
rejects new packets until more space is freed up.
> Today I have not been processing this information and have
> inserted an sleep instruction and I see that exiting after that
> sleep instruction when I look for the counter it is 636, without
> that sleep instruction the number of frames received was 2000.
All the more indication that you need to read the socket faster then you
actually are.
> Is there any way to modify the size of the UDP buffer in Windows?
Look at the SO_RCVBUF option of get/setsockopt().
Gambit
