Newsgroups : Borland : borland.public.delphi.internet.winsock : 2007 Dec : Re: Receiving SNMP-Traps

www.cryer.info
Managed Newsgroup Archive

Re: Receiving SNMP-Traps

Subject:Re: Receiving SNMP-Traps
Posted by:"Stefan Paege" (pae..@notforme.el-carls.de)
Date:Thu, 27 Dec 2007 15:03:00

Francois,

thank you for your quick answer. So you suggest a ICS WSocket (or is a
WSocketServer?) component listening on UDP Port 162?

Is there any further support in ICS to do the SNMP decoding?

Thx
  Stefan

>> I need to receive SNMP-Traps in one of my apps. While I have
>> successfully used Synapse to send SNMP-Traps I'm not sure I understand
>> how to receive Traps without missing data.
>> As Synapse uses blocking sockets I guess I should put the calls to
>> RecvTrap() into a thread of its own. So far so good. What puzzles me is
>> that inside the classless RecvTrap() function a TSNMPSend object is
>> created and as soon as it has received a trap data packet this object is
>> destroyed again. The classless function returns the trap data.
>> So while I handle the trap data in my app any incoming SNMP traps are
>> not handled because noone is listening on UDP port 162. Even if I do a
>> new call to RecvTrap() as soon as possible there is still a small
>> timeframe where a SNMP packet could arrive without being handled.
>>
>> Is it just me who doesn't see the forest for the trees or is this a
>> faulty design in Synapse? Any comments are welcome. Thanks.
>
> Maybe this is the place where asynchronous socket would help, such as ICS
> http://www.overbyte.be.
> Even using async socket, you have to be very careful about the design of
> your application because UDP is a connectionless protocol, you are likely to
> easily loose packets ! You should have a thread with highest possible
> priority to accept incomming UDP datagrams (SNMP traps in your case) and put
> those datagram into a queue for processing by another thread with lower
> priority. Pay attention to DOS attack: always check you queue size and do
> not accept datagram if the queue ever became too large. It is either that
> the computer you are using is too slow for the load, or there is a DOS
> attack occuring, flooding your application with tons of datagrams.
>


--


Elektronik-Labor Carls GmbH & Co. KG

  Stefan Paege

Fon: +49 5973 9497-23
Fax: +49 5973 9497-19

----

Elektronik-Labor Carls GmbH & Co. KG
Kommanditgesellschaft:Sitz Neuenkirchen, Registergericht Steinfurt HRA 3310

Persönlich haftende Gesellschafterin: Elektronik-Labor Carls,
Beteiligungsgesellschaft mbH, Sitz Neuenkirchen, Registergericht
Steinfurt HRB 4175

Geschäftsführer: Irmgard Carls, Joachim Schulte

Replies:

none

In response to:

www.cryer.info
Managed Newsgroup Archive