You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This package limits the size of responses over TCP to MaxMsgSize (64KB), which is causing issues when large result sets are involved.
A specific manifestation of this problem occurs in a system using Consul for service discovery through the DNS interface when a large number of service instances are registered. A more detailed bug report is filed here: hashicorp/consul#3850
After looking through various DNS RFCs, I couldn't find a reference to a required limit to the size of a response over TCP (I could have missed it tho), clients should be able to consume the entire TCP stream in response to their query.
Because this constant is hard coded there is no opportunity for users of this package to work around it.
Would you be open to making the limit configurable so users of the package can choose what upper limit they can tolerate for their setup?
The text was updated successfully, but these errors were encountered:
TCP messages are denoted by a two byte length prefix. From RFC 1035: "The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field."
This package limits the size of responses over TCP to
MaxMsgSize
(64KB), which is causing issues when large result sets are involved.A specific manifestation of this problem occurs in a system using Consul for service discovery through the DNS interface when a large number of service instances are registered. A more detailed bug report is filed here: hashicorp/consul#3850
After looking through various DNS RFCs, I couldn't find a reference to a required limit to the size of a response over TCP (I could have missed it tho), clients should be able to consume the entire TCP stream in response to their query.
Because this constant is hard coded there is no opportunity for users of this package to work around it.
Would you be open to making the limit configurable so users of the package can choose what upper limit they can tolerate for their setup?
The text was updated successfully, but these errors were encountered: