Found some bugs in the socketfiles code #16
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When, I started up an allcat tcp listener with:
allcat tcp://:8080
I got a log message:redirected: //[::]:8080
. Looking at the code, I missed aScheme: "tcp"
in the tcpreader.go code.When I went to fix that, I found a few other issues:
dial
misspellings asdail
.Open("tcp://:8080")
will not properly cancel listening on a context cancelsetForWriter
andsetForReader
were poorly designed.url.URL
s for filenames was kind of wonky.packet_size
as a parameter accepted fortcp:
but unused, removes a special case for UDPsetInt
was not a useful helper function. It is a one-line function-call to a one-line function.getInt
andgetSize
do not need to return abool
, none of them accept 0 as a valid value.ipSocket
instead, make it a named field. (There are weird receiver method exposure with these)net.ResolveProtoAddr("proto", net.JoinHostPort(…))
rather than a flimsy self-implementationtime.Ticker
in throttling code, which also requires better channel draining hygiene.updateDelay
when updating bitrate on throttler, rather than requiring the caller to call it themselves (it was always being called anyways)UDPConn
inudpReader
, we don’t do anything but redirect the calls, so they could just be done directly with embedding. It’s not our type, and we already leak receiver method implementations for local files, so this fits well.