Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trap receiver #4

Merged
merged 9 commits into from
Feb 11, 2016
Merged

Trap receiver #4

merged 9 commits into from
Feb 11, 2016

Conversation

k-sone
Copy link
Owner

@k-sone k-sone commented Feb 10, 2016

resolve #2

For the following reasons, I changed some API from #2

  • Support for both IPv4 and IPv6
  • Support for community validation
  • Future expansion
    • Support for TCP transport
    • Support for trap of version 3

mgenov and others added 7 commits February 6, 2016 12:33
This change adds trap server which is responsible for receiving of trap
events. When server receives trap package it will be decoded and
dispatched to concrete listener using separate goroutine.

Fixes #3
@k-sone k-sone mentioned this pull request Feb 10, 2016
@k-sone
Copy link
Owner Author

k-sone commented Feb 10, 2016

@mgenov I would like to get your feedback.

}
}()

l := s.Listener
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Listener shouldn't be checked for each connection I suppose. Moving one level up will remove the number of checks.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Listener can be changed at any time, because it is public member.
Fixed ed35def

@mgenov
Copy link
Contributor

mgenov commented Feb 10, 2016

Overall: I think that things are looking really good. +2 about this change.

The only think that bothers me is that there are several places where packet versioning is checked. For example, when TrapServer is initialised, it has

mp:        newMessageProcessing(V2c), // server explicitly says that it uses messages V2c 

but latter in the handle func there is:

if v := msg.Version(); v == V2c {
}

so even server has decided what message processing to be used, it makes another versioning check.

@k-sone
Copy link
Owner Author

k-sone commented Feb 10, 2016

The only think that bothers me is that there are several places where packet versioning is checked

That's true.

These is temporarily implementation. When support the other SNMP version, there is a need to be modified.
To be exact, it is necessary to be able to select the message-processing for the received message.

@mgenov
Copy link
Contributor

mgenov commented Feb 10, 2016

LGTM !

k-sone added a commit that referenced this pull request Feb 11, 2016
@k-sone k-sone merged commit 7ea03f4 into v2.0.0-dev Feb 11, 2016
@k-sone k-sone deleted the trap_receiver branch February 11, 2016 04:31
@mgenov mgenov mentioned this pull request Feb 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants