Protocols¶
Four backends, one operation surface. Each page below covers what a protocol amounts to on these devices, what the library does with it, and the quirks worth weighing when you pick one.
Shape of the code¶
Each protocol is split the same way, which is worth knowing before you read the source:
Layer |
Responsibility |
|---|---|
|
Pure protocol knowledge: OIDs, packet formats, page URLs, command strings, and parsers. No I/O, no sockets — which is why almost all of it can be tested against captured bytes. |
Getting bytes to and from a device: |
|
|
The model-driven operations, mapping a facade call to this protocol’s mechanism for this model. |
The other side of the same wire: a mock switch answering the protocol for real. See The virtual switch. |
The facades in src/netgear_switch/sync_api.py and
src/netgear_switch/aio_api.py sit on top and choose exactly one backend per
operation — see Concepts.
Choosing a backend¶
Backend |
Best for |
Watch out for |
|---|---|---|
SNMP |
Bulk reads, monitoring, anything scripted. The richest data source on managed switches. |
Write access is often restricted, and an unauthorised request is silently dropped rather than refused. |
NSDP |
Plus switches, where it is one of only two options. Also discovery. |
Broadcast-based, so the sending interface matters. No PoE, MAC table, LLDP or sensors. |
HTTP |
Reaching a switch through a firewall that only allows the web port, and PoE control on Plus switches. |
Sessions expire; page sets vary widely between models. 7 distinct page dialects across this fleet. |
CLI |
FASTPATH switches when you want the switch’s own view, and the only
route for |
One TCP round trip per command; per-port statistics need one command per port. |