search

davedufresne / modern_snmp

A pure-Rust library for SNMPv3
Apache License 2.0
22 stars 5 forks source link

Combining projects to support for v1/v2c #4

Open clarkmcc opened 3 weeks ago

clarkmcc commented 3 weeks ago

Hi @davedufresne, nice work on this project! I've just finished a first pass at implementing an SNMP v1/v2c library and I was starting on SNMPv3 when I found your implementation. I was wondering if there was any appetite on your side to unify our libraries so that there would be a one-stop solution for SNMP in the Rust ecosystem?

In addition, after reviewing your implementation here, I wonder if it could benefit from some of the functionality I built into the v1/v2c library, specifically support for out-of-order messages. I noticed that your client implementation drops mismatched packets, which likely means that it can't be used concurrently from multiple threads. That may have been an intentional design decision but I figured I'd throw it out as at least one possible benefit from unifying the libraries.

Anyways, no pressure, but the Rust ecosystem is in desperate need of a all-encompassing SNMP solution 😄.

davedufresne commented 3 weeks ago

Hi Clark, good idea. How would you like to proceed?

clarkmcc commented 3 weeks ago

@davedufresne I took a look through your project in more detail and there are a couple things differences between the projects that I think need to be consistent. I think the projects could merge if the design goals could be aligned.

Your project My project
Encoding/Decoding yasna rasn-snmp
Runtime None (blocking) Tokio (async)

I don't have a strong preference on the encoding/decoding. I went with rasn_snmp so that I could spend more time on the client, and less on the wire format. The library does provide some nice traits so that I could abstract over the messages from the different SNMP versions. But I also see plenty of good things about rolling our own message types so they can be more purpose-built for the lib. Open to your thoughts on this.

Having the library be async compatible is a more important priority to me because I do want to support concurrent requests and out-of-order responses. Without this, you could never safely make an SNMP request without first receiving a response to a prior request without running the risk of dropping a response. I'm open to other solutions to this problem though, a runtime just happened to be the first thing that came to mind.

Do you think we can find some common ground between these design goal differences?

davedufresne commented 2 weeks ago

Good idea to use rasn-snmp and Tokio. I have no problem using them.