Add toxic slicer #66
Add toxic slicer #66
Conversation
|
Great idea for a toxic! |
|
This is actually really cool. I found a bug in one of my apps about a week ago related to this exact problem. I'm not the biggest fan of adding the delay in this toxic, since it's semi-duplicated functionality and reduces the bandwidth the toxic can process. |
| type SlicerToxic struct { | ||
| Enabled bool `json:"enabled"` | ||
| // Average number of bytes to slice at | ||
| AverageSize int `json:"averageSize"` |
There was a problem hiding this comment.
The convention we've been using for json would be average_size.
|
I've adjusted it in response to the comments. As far as the delay goes: I agree it's not a beautiful solution, but often the OS and/or standard networking libraries buffer input until it's ready to be processed. Go sets TCP NoDelay to be true by default, so there should be no outgoing buffer, but the consumer's setup is unknown. This was the simplest way I saw around that; the other was to change the order so that the latency filter was run after the slicer, but requiring two toxics to be used in tandem to be effective in many cases seemed awkward. If there's a more graceful solution I'm all for it. |
|
|
||
| select { | ||
| case <-stub.interrupt: | ||
| return |
There was a problem hiding this comment.
If this toxic is interrupted at this point in the loop, the remainder of c will be dropped. In this case we would want to just send off the remainder like in the latency toxic.
Toxics can be interrupted without the stream closing, so we need to make sure it's in a usable state.
|
I think that's it for my comments. |
|
@connor4312 LGTM, nice job! can you add it to the CHANGELOG as well? |
|
Thanks! Changelog has been updated. |
|
Rebased off master due to conflict |
|
@connor4312 released as part of 1.2.0 |
When working on relative low-level network applications/clients, it's easy to assume that TCP data will always some in nice grouped "packets" that have all the data you need in them, rather than viewing the connection as a stream. When working locally that may even be its apparent behaviour, but over real-world network connections that's certainly not something that can be relied upon.
This PR adds a "slicer" filter which takes data and slices it up into nice little random chunks before sending them out. The slider also includes a simple delay option, to bypass buffering behaviour that could otherwise nullify the sliced bytes.