Property.port at pong.proto:40 and Peer.port at pong.proto:71 are declared as uint32, which accepts any value from 0 to 4,294,967,295. TCP port numbers are 16-bit: the valid range is 0–65535. A Hub that stores a port number incorrectly, or a developer who writes a port value larger than 65535 into either field, produces a serialised message that passes proto validation and deserialization cleanly but causes the client TCP dial to fail immediately with a platform-specific "invalid port" error rather than a structured protocol error.
uint32 is the correct protobuf type for a 16-bit-range integer (proto3 has no uint16), but the missing upper-bound documentation makes the constraint invisible to implementors. Neither the Hub nor the Node has a spec-level signal to reject out-of-range values before they cause a failed connection.
Add a comment on both Property.port and Peer.port stating the enforced range (1–65535) and the rejection behaviour expected of the Hub and Node when a value falls outside that range.
Property.port at pong.proto:40 and Peer.port at pong.proto:71 are declared as uint32, which accepts any value from 0 to 4,294,967,295. TCP port numbers are 16-bit: the valid range is 0–65535. A Hub that stores a port number incorrectly, or a developer who writes a port value larger than 65535 into either field, produces a serialised message that passes proto validation and deserialization cleanly but causes the client TCP dial to fail immediately with a platform-specific "invalid port" error rather than a structured protocol error.
uint32 is the correct protobuf type for a 16-bit-range integer (proto3 has no uint16), but the missing upper-bound documentation makes the constraint invisible to implementors. Neither the Hub nor the Node has a spec-level signal to reject out-of-range values before they cause a failed connection.
Add a comment on both Property.port and Peer.port stating the enforced range (1–65535) and the rejection behaviour expected of the Hub and Node when a value falls outside that range.