Board index » delphi » TIdUdpServer and TIdAntiFreeze

TIdUdpServer and TIdAntiFreeze

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

 

Re:TIdUdpServer and TIdAntiFreeze


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.
Quote
Stefan Paege wrote:

> 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

Re:TIdUdpServer and TIdAntiFreeze


Hi Al,

comments below...

Quote
> 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.

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

Quote
> If it is mandatory to catch all data, you probably want to use TCP, not

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

Re:TIdUdpServer and TIdAntiFreeze


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

Quote
> 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?

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"

Re:TIdUdpServer and TIdAntiFreeze


Chad,

Quote
> AntiFreeze has no effect on UDP server. The UDP server does not "block"

the main thread so it

Quote
> would be of no use.

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???

Quote

> Only you can block your main thread depending on what you do in the

events. Note that you can

Quote
> configure UDP server to fire your events in the thread as well.

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...

Quote
> "Stefan Paege" <pa...@el-carls.de> wrote in news:3be956d0_2@dnews:
> > 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?

> AntiFreeze has no effect on UDP server. The UDP server does not "block"

the main thread so it
Quote
> would be of no use.

> Only you can block your main thread depending on what you do in the

events. Note that you can
Quote
> 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"

Other Threads