Hi,

I just wanted to get some clues whether the following is a good design.

Consider a UDP connection with lots of incoming datagrams. About 20-30
datagrams per second on average, maximum around 100 per second. Each of
these datagrams contains around 200 byte of data. The data has to be
filtered and then logged to a database. It's mandatory to catch all
datagrams without  loss. And the GUI has to be responsive, too.

Is it a good approach to copy the design of Indy's UDPServer demo and simply
have a TIdUdpServer and a TIdAntiFreeze component on the app's main form? Or
should I run the TIdUdpServer within it's own thread? If yes, what would be
the best way to transfer the filtered data from that thread to the main
thread?

TIA

--

elektronik-labor Carls GmbH & Co. KG
Stefan Paege

Kontakt: +49 (0)5973 9497-23   Fax: +49 (0)5973 9497-16

And the GUI is doing what.....
Sounds to me like you need to receive the data, filter it, log it to db. - no GUI
Another app to read the data, and possibly modify the filters.
If it is mandatory to catch all data, you probably want to use TCP, not UDP.

Hi Al,

comments below...

Yes you are correct, it sounds like a background process, no GUI needed. But
there are many statistics that have to be updated in realtime (using a
second app working with the database has shown performance issues) and many
parameters that constantly have to be changed during runtime.  Another
reason for this "All in one" approach is the one all developers like the
best: The customer wants it that way. I know, I know, I'm the coward of the
county...

In summary the GUI is not the most important part of the app, but it has to
work. And it must not have any measurable impact on the functionality of the
UDP receiver

UDP.

No chance, I have to connect to an existing system that uses UDP. All
subsystems are connected over one LAN, no WAN, routers, switches. We, our
company are not the developer of that system, we are only a third party
putting another piece to the puzzle. The manufacturer of the original system
(a global player in telecommunications) has chosen UDP because of it's speed
(less overhead than TCP) and is telling us that in such an (only one
physical network segment) environment UDP is actually as save as TCP.

Thanks

Stefan Paege

"Stefan Paege" <pa...@el-carls.de> wrote in news:3be956d0_2@dnews:

AntiFreeze has no effect on UDP server. The UDP server does not "block" the main thread so it
would be of no use.

Only you can block your main thread depending on what you do in the events. Note that you can
configure UDP server to fire your events in the thread as well.

--
Chad Z. Hower (Kudzu) - http://www.pbe.com/Kudzu/
Current Location: St. Petersburg, Russia
      "Programming is an art form that fights back"

Chad,

the main thread so it

Hmm, I just checked the example project UDPServer.DPR from the demo package.
Both components, a TIdUdpServer and a TIdAntiFreeze are used together, no
other Indy components involved. Bad example???

events. Note that you can

I think you are talking about the ThreadedEvent property. I'm trying to
understand it's effect, but have failed so far. Can you (or someone else) to
elaborate on this, please?

--

elektronik-labor Carls GmbH & Co. KG
Stefan Paege

Kontakt: +49 (0)5973 9497-23   Fax: +49 (0)5973 9497-16

"Kudzu - Team Indy" <chad...@pbe.com> schrieb im Newsbeitrag
news:Xns91535CAAD78C0chadngpbecom@207.105.83.65...

the main thread so it
events. Note that you can