Newsgroups : Borland : borland.public.delphi.internet.winsock : 2007 Dec : 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
none