"Silvia" <silvia@correo.com> wrote in message
news:44990a8e$1@newsgroups.borland.com...
>
> I would rather not use threads if I can avoid it.
>
> Is there any other way to do it? Couldn't I increase the UDP
> buffer?
If you use some protocol for UDP flow-control, increasing the Wincock buffer
size with a setSockOpt() call *may* improve your performance.
As others have said, however, you should try and get the buffers out of
Winsock as soon as they are available and queue them up. No IP
flow-control, (eg. like TCP), and slow buffer removal means that Winsock
will just dump the datagrams. To try and avoid this, use a seperate thread
to queue up the UDP datagrams in user-space, (or use overlapped I/O to queue
up a lot of user-space buffers to Winsock/kernel, but I'm guessing that, if
you are not happy with threads, you will be very unhappy with that plan).
Once you have the datagrams queued up, you then have options to improve
overall performance, eg. processing the datagrams in batches to improve DB
bandwidth and/or using a multiProcessor box to enable the DB updates to
proceed in parallel with the datagram receipt.
Without multiThreading, complex 'real-time' apps are err.. 'very difficult'
to get working reliably and with good performance.
Rgds,
Martin
