bcoe
Simulate packet loss
I've given this some thought and I don't think that dropping bytes is a useful feature, as it does not simulate real world poor network conditions. If a packet is not received, another attempt to send it occurs, since TCP is supposed to be a guaranteed reliable delivery, with all bytes sent and in the correct order.
What really should happen is that there is a chance that a entire packet may be lost. It has to pretend to send a packet and then retransmit with the actual payload.
At the very least, dropping bytes should be a deprecated or removed feature. It seems to be highly problematic, especially if for example I am downloading a JS file and there are bytes missing, code won't execute or fuck up in unpredictable ways.
Perhaps I can attempt a PR on this.
I agree 100%, I felt that dropping bytes was a little bit of a hack. I wonder if we could use something like Comcast, and simulate packet loss at a lower level.
Comcast works but also comes with the downside of bogging down your entire connection, and requires specifying which network interface to use. It has to be done at an application level, rather than messing with your entire network interface.
@groundwater any advice, regarding simulating packet loss on a Node.js socket?
I was thinking that it should implement the _write method of the TCP Duplex stream, and somehow mess it up by doing nothing every once in a while for some random interval or some other means. Or pausing and resuming the socket. The problem with this method is that it is just a latency spike and won't be acknowledged as packet loss, but that is what packet loss feels like to an end user.
@daliwali what if we deprecate drop-frequency, and use this for starters, for simulating packet-loss:
https://github.com/wearefractal/net-sim
It just calls out to ipfw, I'd rather try to find out a way to do things natively, or at least perform OS detection and try to get net-sim working on Windows too. thoughts?
Hmm, I looked at the source code and all that net-sim does is add a fixed amount of latency, something that this module already does. What I was hinting at in the previous comment is that somehow it should force a retransmission by intentionally fumbling up a previous transmission, or refusing acknowledgement from a client. Will probably need to dig into Node.js internals to get a handle on how to implement.
Hmm... I'm not sure, I kind of take TCP for granted. I don't really know the application layer failure modes that will occur when a significant packet loss happens.
Node pcap is a good project that you can use to get ideas for this kind of thing
