Trident Sign: Listener Adapter Future

In the past, I have a lot of plans for the agent. Listener component is one of the most important pieces. So I must pay special attention to it.

The very first revision exposes all events on Listener. It was the easiest way to test out the component. We can subscribe to different events in order to know what happens. I was satisfied with that revision.

Soon a new requirement comes that we need to make it easy to develop an SNMP v1 aware agent. It was then I think why not create version specific Listener component? After a while I wrote the adapters and it made me happy to start my research on SNMP agent. That's our second revision on Listener.

Well, time goes by so fast. Once I used the pipeline model to code the agent design, I saw the limitation of both our first and second revision. We must have a unified way to handle all incoming SNMP messages just like IIS does to HTTP messages, then it is useless to expose so many events or create so many adapters. Therefore, our current implementation makes agent side listener adapters obsolete.

But if we look back, we will see that manager side adapters are still necessary. As a result, we will keep them.

OK, that's all for this post. Later I will post about our SNMP pipeline. Stay tuned.

Trident Sign: SNMP Agent Approach I Chose and The News

When the first time someone asked me if #SNMP library can be used to develop a full feature SNMP agent, I was not sure. I know it must be a long way to go on agent side, because there are so many pieces we need to implement.

Interesting that finally I can work on the agent side extensively. Now the small TestAgent sample grows over the weekends, and today it becomes a small but usable SNMP v1 agent. It can now handle v1 GET, SET, GETNEXT messages. Besides, it can send out a test TRAP message. Though I only implemented six basic objects, it is really promising that we have an architecture ready.

I have to admit that I did not have a blue print in the beginning, though I have been thinking about the elements for almost a year. Refactoring is always my friend, so that I can feel free to code first, and refactor next. And I also borrow some ingredients from dear ASP.NET. The concept of HTTP processing pipeline is amazing and it makes a lot of extensions possible. I at last chose this approach and refactor the code base accordingly.

If you take a look at SnmpApplication, SnmpContext, IMembershipProvider, IMessageHandler, you will find them familiar (just like HttpApplication, HttpContext and so on). But they are still in early stage, and subject to heavy changes in the next few weeks.

Then how to shape this TestAgent (snmpd) to suit your need? You can write your own membership provider to authenticate requests, and write your own message handlers to handle SNMP messages. Also you can implement more objects and store them in the object store. The store is really rough at this moment, but we can make it better in the future.

That's all I can write up-to-now, because after the Oct 1st release of #SNMP Suite 3.1, we really come across a lot of new things. I did not yet have anything important to write about the compiler yet, and hope this agent project can attract your attention.

Please feel free to let me know how you think about the future of #SNMP, I did not yet have a detailed plan for 4.0 release finalized. We still have time to investigate in this field, so stay tuned.